Kerberos and authorizied_keys
Damien Miller
djm at mindrot.org
Wed Feb 22 13:01:05 EST 2006
On Tue, 21 Feb 2006, Dan Peterson wrote:
> How reasonable, acceptable and difficult would it be to "enhance" openssh
> so authorizations using kerberos (specifically kerberos tickets) consulted
> the authorized_keys file? And to be a bit more precise... consulted
> authorized_keys so it could utilize any "options" (eg. from=, command=,
> environment=, etc) that may be present?
>
> I'm willing to make custom changes, but would prefer if this was standard
> behavior, so I thought I'd check to see how likely a change like this
> would have of getting put in the standard source.
>
> My plan (and I haven't really looked at the source) would be to add a new
> "key type"... say "ssh-krb" where the "key" would be the kerberos
> principal.
There was some discussion of this a couple of years back when the GSSAPI
code landed IIRC and there may have even been a patch. I didn't want to
look at it until the dust had settled (which I think it has).
If you want to pursue this, then please try to keep your changes as
minimal and non-intrusive to non-GSSAPI/Kerberos related code as
possible. It would be fair to say that we greatly favour stability of
OpenSSH over new features at this point.
> Would having this new key-type break anything for openssh clients that
> don't recognize it? Or is the code smart enough just to ignore unknown
> key-types?
If the key type only existed in the authorized_keys file, then no - sshd
ignores lines in that file that it doesn't understand.
> The main purpose for this so we can use ssh as a tunnel for CVS and
> Subversion clients. We need to use kerberos for authentication and we
> need to restrict the commands the user can execute. The authorized_keys
> "command=" facility seems to be the perfect solution except it doesn't
> work with kerberos.
One alternative is to create accounts with a login shell that forces
them to use your chosen command, and to allocate principles to these
accounts.
-d
More information about the openssh-unix-dev
mailing list