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