Re: Using PAM an the SSH Protocol

[Frank Cusack <fcusack%fcusack.com@localhost>]

Perhaps this has been addressed in some other way, but I'll add my
much delayed 0.02 anyway.  I've quoted a lot more of the discussion
than I would normally since it's so old.

On Wed, Apr 11, 2001 at 02:51:33PM -0700, Darren Moffat wrote:
> Some of you may have noticed that SSH Communications Security has
> announced support for PAM (Pluggable Authentication Modules) in its
> latest Windows platform clients and support for PAM first appeared in
> their 2.4.0 product.  OpenSSH also has support for PAM in the portable
> release.
> 
> PAM was originally developed by Sun Microsystems Inc (details at:
> http://sun.com/solaris/pam) as a means of abstracting out of programs
> like login and telnetd the user interaction required to authenticate
> the user, decide (based on access control policies) if they should
> access the system at this time and then setup their local credentials.
> 
> At the present time there are (at least) two different methods of using
> PAM in the currently available SSH protocol implementations.
> 
> In the SSH Communications Security implementation the client and server
> must agree to use the authentication method "pam-1%ssh.com@localhost" otherwise
> no PAM code is run.
> 
> In the OpenSSH implementation PAM is used to authenticate the user if
> Keyboard Interactive is used (I'm talking about v2 protocol support, I
> know it is slightly different in v1).  Regardless of wither or not
> Keyboard Interactive authentiation is run the PAM functions that deal
> with account management (pam_acct_mgmt) and setting of credentials
> (pam_setcred) are always run.

It is worth noting that regular password auth uses PAM now also.

> What does this mean ?
> 
> If I have a client connecting to an SSH Communications Security server
> that does not understand (or chooses not to send) "pam-1%ssh.com@localhost" as
> an authentication mechanism then the PAM functionality for pam_acct_mgmt
> will not get run.  pam_acct_mgmt is responsible for makeing decisions on
> wither this user (who is authenticated, either by pam_authenticate or
> by other means) is actually allowed to access the system via this service
> at this time.
> 
> Compare this with the OpenSSH implmentation where pam_acct_mgmt will always
> be run so the access restrictions will be correctly enforced.
> 
> 
> So isn't this an implmenation issue ?

Yes.

> Tatu and I had a short discussion on this today and decided that at the
> present time we are not sure, there may be protocol issues, it might
> be that keyboard interactive can't solves them all, it might be limitations
> in PAM, or something else.
> 
> One thing I am positive about is that if a particular server for
> the SSH protocol wants PAM to be used there should be no means for the
> client to by pass the access controls regardless of which SSH protocol
> authentication is used.  Put another way PAM as a framework should not
> be visible to clients; it was only ever intended to be a server side
> implementation framework not a network protocol or an authentication
> mechanism in its own right (pam-1%ssh.com@localhost make it an auth mech).
> 
> 
> Why am I bringing this up on ietf-ssh ?
> 
> I want to gather people who are interesting in helping solve this problem
> possible out comes are that there are defiencies in the core SSH protocol,
> Keyboard Interactive isn't enough to solve all PAM issues, PAM doesn't
> fit well with protocols like SSH (if it is the later then my goal would
> be to come up with some best practices on how it can be used and what
> limitations there are), or may be it is an implmenation issue - but it is
> important because at the moment there are interop problems that have
> potential security vulnerabilities in the view of system admins.

keyboard-interactive is capable of fully interacting with PAM.  It was,
in fact, designed based on an sshd using PAM.  Is "pam-1%ssh.com@localhost" still
in use?  That would be most unfortunate, it breaks one of the things
kbdint was meant to solve: client knowledge of the authentication
mechanism.

/fc