SSH mediated Kerberos authenticated sudo.

g.w@hurderos.org g.w at hurderos.org
Tue Jan 11 10:26:49 EST 2011


On Jan 7,  8:57am, Frank Cusack wrote:
} Subject: Re: SSH mediated Kerberos authenticated sudo.

Hi Frank, thanks for the note, hope your week is going well.

> 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.

That was where I was it until I needed a couple of weekend project.  I
had originally thought we would need to worry about opening an
additional channel but it was more straight forward then what I had
anticipated.

> 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.

Interesting concept and one that I had not thought about.

Actually the Hurdo patches from the SSH perceptive are not terribly
sudo specific and could be leveraged by other applications which
require the concept of interactive authentication in a Kerberos
friendly fashion.  There would need to be application support which
would be a common denominator in either case.

All the SSH plumbing does is to create a framework for conveying a
AP-REQ packet into the context of the interactive session so it is
available to the application via a reference through an environment
variable.  There would be nothing to stop any other application from
using a conveyed credential other then the need to access the host key
to authenticate the packet.

>From that perspective sudo is an easy candidate since it runs with
root privileges.  I've been thinking of adding a suid utility which an
unprivileged application could use to simply authenticate the conveyed
AP-REQ packet.  The application would return a 0/1 status to indicate
whether or not the authentication failed.

This model, of course, still requires, the user to initiate an an
authentication with the ~s command so it would not be as transparent
as what you propose.  On the other hand figuring out how to prompt a
user has been somewhat of a consistent problem if we take PAM as an
example.

I will think a bit about what you are proposing, it may not be all
that hard to do with the exception of the prompting mechanism.

> Still, this patch is awesome.

I'm glad you found it interesting.  I'm hoping to get some feedback
from others before I spin the next version which will have better
support for non-interactive sudo authentication.  That should help
people who want to do distributed cluster maintenance and the like.

Thanks again for the comments.

Have a good week.

}-- End of excerpt from Frank Cusack

As always,
Greg Wettstein

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management

"More people are killed every year by pigs than by sharks, which shows
 you how good we are at evaluating risk."
                                -- Bruce Schneier
                                   Beyond Fear



More information about the krbdev mailing list