Food for thought regarding PAM

[Markus Friedl]

On Mon, Nov 29, 1999 at 05:45:49PM +0000, Mike Fisk wrote:
> Would it not be more productive in the long run to create PAM modules that
> support all the various forms of authentication and logins?  Then you can
> keep the SSH code simple, re-use existing vendor and open-source modules,
> and contribute to the set of open-source modules?

fyi, there are different opinions on PAM.
this is from the lsh-distribution:
-------------------------------------------------------------------------

NO PAM SUPPORT

I spent a day reading the PAM documentation. My conclusion was that
PAM is not at all suited for handling ssh user authentication. There
are three main problems, the first two of which would be show-stoppers
for any SSH server, while the last is a problem that affects servers
like lshd which doesn't fork() for each connection.

(i) The design of PAM is to hide all details about the actual
authentication methods used, and that the application should never
know anything about that. However, ssh user authentication is about
particular authentication methods. When the client asks which
authentication methods can be used, the server should be able to tell
it, for example, whether or not password authentication is acceptable.
When the client tries the password authentication method, no other
method should be invoked. But PAM won't let the server know or control
such details. This problem excludes using PAM for anything but simple
password authentication.

(ii) PAM wants to talk directly to the user, to ask for passwords,
request password changes, etc. These messages are not abstracted *at*
*all*, PAM gives the application a string and some display hints, and
expects a string back as the users response. This mode of operation
doesn't fit with the ssh user-authentication protocol. 

If PAM would tell the ssh server that it wanted the user to chose a
new password, for instance, the server could the appropriate message,
SSH_SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, to the client, and pass any
response back to PAM. But PAM refuses to tell the application what it
really wants the user to do, and therefore there's no way the server
can map PAM's messages to the appropriate SSH packets. This problem
excludes using PAM for password authentication.

(iii) The PAM conversation function expects the server to ask the user
some question, block until a response is received, and then return the
result to PAM. That is very unfriendly to a server using a select()
loop to manage many simultaneous tasks. This problem by itself does
not exclude using PAM for a traditional accept(); fork()-style server,
but it is completely unacceptable for lshd.