openssh unix dev - Feb 2006 - Kerberos and authorizied_keys

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.

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?

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.

I'm certainly willing to consider alternate solutions... especially if 
they don't involve a custom change to openssh.  But at the present time 
the best alternative I've come up with is forcing all the users to have a 
custom login shell and that's not really going to work.

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

I'm attempting to add authorized_keys functionality to gssapi/kerberos 
authorized connections, mainly to support forced command capability, but 
would like to confirm the best way to determine the gssapi/kerberos 
principal and the best place to check authorized_keys.

To determine the principal, currently I'm indirectly accessing 
gss-serv.c:gssapi_client.displayname.value (more detail below).  This 
seems to work, but I'd just like to know if there's a better/more 
appropriate way to determine the principal?

I'm also not 100% sure WHERE I should be testing for the existence of the 
user in authorized_keys.  Currently the check is done in 
auth2-gss.c:input_gssapi_token() (more detail below).  This seems to work, 
but again is this the best/most appropriate place to check?


MORE DETAIL

To determine the current principal, I created a one-line function in 
gss-serv.c:

   char *ssh_gssapi_displayname(void)

which simply returns (char *)gssapi_client.displayname.value.

This is called from auth2-gss.c:input_gssapi_token() and assigned to a 
"Key" pointer which is passed into auth2-pubkey.c:user_key_allowed().


In auth2-gss.c:input_gssapi_token(), I check for the existence of the user 
in authorized_keys.  I first tried to mimic the pubkey behavior and check 
in userauth_gssapi(), but found out gss-serv.c:gssapi_client wasn't 
defined until AFTER userauth_gssapi() had been called.

The new code is inside the "else" clause, just after "if
(send_tok.length
!= 0)", but before "if (maj_status == GSS_S_COMPLETE)".  My check
may
fail, and if it does, I "goto done", which is just before 
"gss_release_buffer()" at the end of the function.  I can give more 
details if necessary and I will supply a complete patch for review, I just 
hoped to get as close to correct as possible before submitting the patch.

PS. One other note... as I mentioned earlier, I'm calling 
auth2-pubkey.c:user_key_allowed() to parse authorized_keys and search for 
the appropriate key.  I had to make one small change to 
user_key_allowed2() so the new "ssh-gss" type wouldn't try to
call key_fingerprint() with the principal, but other then that, the 
function is the same.

This all works, but auth2-pubkey.c no longer seems like the most 
appropriate place for user_key_allowed() and user_key_allowed2(), since 
they're used for more then just "pubkey".  Would it be better to
move
these to a separate file (eg. authorized_keys.c) or maybe move then to 
auth2.c?

Assuming a NEW file (authorized_keys.c) would be best... would it also be 
a good idea to move the other authorized_keys related functions to the 
same file... so in other words, the following 4 functions would be moved 
to authorized_keys.c:

   auth.c:authorized_keys_file()
   auth.c:authorized_keys_file2()
   auth2-pubkey.c:user_key_allowed()
   auth2-pubkey.c:user_key_allowed2()