[39113] in Kerberos
Re: Using an alternate principal for ssh
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue May 31 16:10:52 2022
From: Russ Allbery <eagle@eyrie.org>
To: Dan Mahoney <danm@prime.gushi.org>
In-Reply-To: <1559B81F-2C3B-4445-AF14-D28B9F328A78@prime.gushi.org> (Dan
Mahoney's message of "Tue, 31 May 2022 15:51:39 -0400")
Date: Tue, 31 May 2022 13:04:46 -0700
Message-ID: <8735gph3j5.fsf@hope.eyrie.org>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Dan Mahoney <danm@prime.gushi.org> writes:
> Our userbase is pretty small and systems are overall managed with
> puppet, so that's not a problem for us. We'd need to either disallow
> GSSAPI entirely, or accept that we need to manipulate a dir of k5login
> files outside the users' homedirs.
If you're already willing to manage .k5login files, the search_k5login
option to my PAM module may also work and the whole reason why I started
contributing to that module instead of using Red Hat's (to solve an old
issue that Stanford had).
alt_auth_map is the more precise solution, but it only allows a single
mapping, whereas with search_k5login you can do whatever you want as long
as you populate .k5login accordingly.
> I'll take a directory of k5login files. As an organization we don't
> like pubkey auth because there's no easy central control over users.
> (i.e. pubkey completely sidesteps kerberos. If you have something like
> ldap deployed, that can help, but we don't like the idea of every system
> call like ls -al phoning an LDAP server.)
Yes, at Stanford we disabled public key and required GSS-API for most
things.
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
