On Jan 26, 2005, at 5:55 AM, Greg Troxel wrote:

> An sshd can accept a username and password, and try to get tickets,
> and then a service ticket for host/f.q.d.n@REALM, and if that ticket
> works, allow the user to log in, provide the tickets to the user,
> and clean them up afterwards.  I don't know any reason this should be
> different from how login behaves.

Right.  In other words, the "regular password" auth mode for the SSH 
protocol can itself use PAM as the back-end.  This would allow for e.g. 
Unix passwords, RADIUS, or even S/Key.

> An ssh client can, rather than sending a username/password to the
> sshd, send a username and a GSSAPI authenticator (or raw krb5, but krb
> culture views that as icky).  The remote sshd checks the authenticator
> against host credentials.  On should also be able to send forwarded
> tickets, and have those be cleaned up on exit.

Right.  In the SSHv1 protocol, raw krb5 was used (I wrote an 
implementation of this some years ago).  For SSHv2, there is a draft 
(sorry, I haven't kept up with this for a while, so I don't know the 
current status of this draft, or if it has progressed to RFC status 
yet) for using GSSAPI.  I seem to recall that in SSHv2, the GSSAPI 
credentials are used for more than just authentication; they're also 
used to re-key the SSH transport (this has the surprising-for-some 
side-effect of killing your entire SSH session once your ticket 
expires).

For *both* the SSHv1 and SSHv2 native Kerberos / GSSAPI modes, PAM 
cannot be used.

-- thorpej