Re: kerberos support in ssh/lsh

[Ken Raeburn <raeburn@MIT.EDU>]

nisse@lysator.liu.se (Niels Mvller) writes:
> People have been asking me to add kerberos support to lsh, my
> implementation of the ssh-2 protocol. Kerberos support can mean many
> things, but the primary feature asked for is to let people use their
> kerberos passwords when logging in to the server.
> 
> That's quite un-kerberish, but the idea is that the client sends the
> password to the server (encrypted by the ssh transport protocol), the
> server tries to get a kerberos ticket on the client's behalf, and if
> that succeeds, the client is considered authorized. It's an extra plus
> if the server stores the ticket in the user's credential cache just as
> if the user had run kinit.

"Un-kerberish", yes, but not entirely unreasonable.  Some of us tend
to take the view that sending passwords over the net should be avoided
whenever possible, even if they're encrypted.  (E.g., if the server
has been compromised, the attacker can potentially do serious but
time-limited damage with your forwarded Kerberos tickets; if you send
your password over, there's no time limit.)  But it all depends on
your threat model, I guess.

> An implementation problem is that lshd is a single server; it doesn't
> fork until it spaws a shell for a successfully logged in user. So it
> can't use calls like krb5_get_kdc_cred that ultimately blocks when
> waiting for a reply from the kdc. I can see at least three different
> approaches:

Okay, I've missed something ... why is it bad to block, as long as the
timeout isn't infinite?  (Would it help if the timeout could be
controlled by the application?)  The delay should be very short (under
a second) if all the KDCs are available.


> Suggestions on how to support kerberos the Right Way (i.e. have the
> client transmit a kerbetros ticket rather than a password) would also
> be nice, although it seems less urgent to implement.

It's a lot more interesting for those of us in Kerberos environments
already. :-)

Tatu was working on a design for this as well, though his first
proposal presented at the last IETF meeting had some problems, and I
haven't seen anything else since.  I don't follow ssh lists other than
the IETF SecSh WG list though.

One big benefit of this would be, if you've already got a Kerberos
infrastructure deployed and are adding ssh, you can do mutual
authentication with Kerberos and should be able to do away with the
"add this host key" question that many people simply answer "yes" to
without verifying the data through independent and secure means.

(It'd also be non-blocking on the server side, if that's really
important.)

If you want to work on this, there are other possible features to keep
in mind:
 - forwarding new tickets across an already-established connection
   after the first set expires (perhaps automatically, perhaps not),
   or if the user forgot to specify forwarding on the command line or
   in the config file
 - letting the server end request new service tickets from the client
   (e.g., if we implement an IPC-based ticket store; this way the
   server has only restricted access to certain services)

I'd be interested in looking at this, but I'm not that familiar with
the SSH protocol, and I don't have much time to work on it.

Ken