Re: kerberos support in ssh/lsh

[nisse@lysator.liu.se (Niels Möller)]

Ken Raeburn <raeburn@mit.edu> writes:

> nisse@lysator.liu.se (Niels Mvller) writes:
>
> > 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.

Then all other connection handled by the server will stall while the
server is waiting for the kdc:s. It seems a lot nicer and more robust
to (i) allow kdc:s a reasonable time to respond (at least several
seconds), and (ii) continue doing other useful things while waiting.

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

I haven't yet seen any internet-draft for this. I believe it is wise
not to try to hack it into lsh until Tatu or somebody else that is
knows both kerberos and ssh writes up a spec. Unfortunately I couldn't
attend that IETF meeting.

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

Yes, I imagine that some kerberos operations whould replace the normal
ssh key exchange and user authentication (actually, I have hacked srp
support in a similar way: When use of srp is negotiated, it provides
all of key exchange, host and user authentication, replacing the
normal ssh mechanisms).

/Niels