SSH mediated Kerberos authenticated sudo.

Frank Cusack frank+krb at linetwo.net
Fri Jan 7 11:57:35 EST 2011


On 12/22/10 12:31 PM -0600 g.w at hurderos.org wrote:
> ftp://ftp.hurderos.org/pub/Hurdo/Hurdo-0.1.0.tar.gz
...
> The patches implement a ~s escape sequence in the ssh client which
> prompts the user for a password to authenticate the creation of an
> AP-REQ packet for the remote client.  Upon successful authentication
> the packet is conveyed to the server via an SSH local packet type.

Very interesting, and something I've thought about for years but
never got past the "what if" stage.

This is too directly tied to sudo though.  What I want is the opposite
of Simon Wilkinson's Cascading Keys support.  What Cascading Keys does
is that when the client obtains a new GSSAPI credential (i.e., he
runs kinit -R), that new credential is forwarded to the server if
the original one was forwarded (delegated).  The ssh connection is
also rekeyed if the original ssh connection was GSSAPI-keyed.

The opposite is a way for the ssh SERVER to request a new credential
from the client.  Every application would have to be aware of this
request mechanism being available, but I don't see a way around that.

Someone was working on a general file descriptor forwarding mechanism
for ssh, which may also help in this case although I haven't thought
too much about it.

Now imagine if something like Network Information Manager existed
on unix, including the mechanism to initiate a password prompt
when applications need a new ticket.

When an action on the server, like sudo, requires a fresh TGT,
it would see that a remote prompt mechanism was available (say,
via the existence of a magic environment variable), and make the
proper call.  This could be as simple as an attempted read of
a file descriptor.  The ssh magic would happen, the NIM magic
would happen, and the user gets a local prompt for password.

That's where I'd like to be in a year.

Still, this patch is awesome.



More information about the krbdev mailing list