[32774] in Kerberos
Re: Using ksu/sudo with Kerberos
daemon@ATHENA.MIT.EDU (Guillaume Rousse)
Tue Oct 5 04:07:10 2010
Message-ID: <4CAADCA9.1030109@inria.fr>
Date: Tue, 05 Oct 2010 10:07:05 +0200
From: Guillaume Rousse <Guillaume.Rousse@inria.fr>
MIME-Version: 1.0
To: kerberos@mit.edu
In-Reply-To: <1360978647.4448758.1286229366970.JavaMail.root@zmbs4.inria.fr>
Content-Type: multipart/mixed; boundary="===============0773454073=="
Errors-To: kerberos-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============0773454073==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="------------ms090506010004000600030809"
This is a cryptographically signed message in MIME format.
--------------ms090506010004000600030809
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le 04/10/2010 23:56, Russ Allbery a =E9crit :
> Ken Dreyer <ktdreyer@ktdreyer.com> writes:
>> On Mon, Oct 4, 2010 at 3:38 PM, Russ Allbery <rra@stanford.edu> wrote:=
>=20
>>> Yup. You may want to also disable public key authentication.
>=20
>> 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?
>=20
> 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 authenticat=
ion
> 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 runn=
ing
> on each system to ensure that.)
What about this (untested) ?
Match User root
PubkeyAuthentication no
--=20
BOFH excuse #394:
Jupiter is aligned with Mars.
--------------ms090506010004000600030809--
--===============0773454073==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============0773454073==--
