Re: kerberos support in ssh/lsh

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

eichin@thok.org (Mark W. Eichin) writes:

> > 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
> 
> You've fallen into the standard "screensaver" trap, also known as the
> "Zanarotti Attack".  This design-flaw-exploit goes back to the early
> (1985 or so) versions of ksu.

Thanks for the explanation.

> The fix is straightforward: actually *perform* an authentication step
> (krbtgt fetching isn't one.)  Usually this means turning around and
> getting a ticket for host/(local host name), *and validating it*
> against the keytab/srvtab.  You should find code in login to take care
> of all of these details, in fact it should be abstracted out into an
> API of its own (see Marc Horowitz' work in Cygnus V5 Kerbnet, years
> ago.)

Björn Grönvall told me that the krb5_verify_user() function should do
most of the work for me.

> > 3. fork() and exec() the real kinit program. To do this, the interface
> 
> Perhaps you instead need to fork/exec a real *login* program, and pass
> the decision (and the rest of the login process) off to it...

That won't work well with the ssh userauth protocol. It's not
impossible to bypass that, but it doesn't seem right.

> > Suggestions on how to support kerberos the Right Way (i.e. have the
> > client transmit a kerbetros ticket rather than a password) would also
> 
> Yes, both using *and optionally forwarding* a ticket is what people
> expect from krb5 ssh (at least that's what the version used at MIT
> Athena already supports.)

Yes, that would be nice.

> You might also get the documentation tree from MIT Kerberos, which
> doesn't have export restrictions itself... comp.protocols.kerberos has
> a useful FAQ, or at least used to, with pointers to list archives and
> tutorials.

Thanks, I'l start with the FAQ.

/Niels