Using ksu/sudo with Kerberos
Guillaume Rousse
Guillaume.Rousse at inria.fr
Tue Oct 5 04:07:05 EDT 2010
Le 04/10/2010 23:56, Russ Allbery a écrit :
> Ken Dreyer <ktdreyer at ktdreyer.com> writes:
>> On Mon, Oct 4, 2010 at 3:38 PM, Russ Allbery <rra at stanford.edu> wrote:
>
>>> Yup. You may want to also disable public key authentication.
>
>> We're enabling kerberos for several services at my organization, and
>> we were just having this same discussion. Can you elaborate on why you
>> would disable pubkey?
>
> It's totally up to you, of course, and we do leave it enabled on some
> systems because in some cases it's easier than using GSSAPI authentication
> with ssh. But once you have Kerberos, public keys constitute a second
> parallel authentication system which isn't tied in with Kerberos, which is
> a potential vulnerability. You may disable a Kerberos account but not
> forget to remove their authorized_keys entries, for example. ssh keys are
> also difficult to centrally manage, which is usually one of the whole
> points of a Kerberos infrastructure.
If you disable the account at the authorisation layer, using shadow
account for instance, and configure OpenSSH to use PAM, you don't really
care about the exact authentication method used.
And they are methods to manage public keys centraly, such as storing
them in a LDAP directory or in a version control system, regulary synced
on machines through some kind of configuration management engine.
> There unfortunately isn't any way that I know of to allow GSSAPI and
> public key authentication via ssh for regular users but require GSSAPI
> alone for root authentication, so we usually just turn public key off
> entirely. (I suppose you could enforce an empty authorized_keys file, but
> that requires some sort of configuration management infrastructure running
> on each system to ensure that.)
What about this (untested) ?
Match User root
PubkeyAuthentication no
--
BOFH excuse #394:
Jupiter is aligned with Mars.
More information about the Kerberos
mailing list