Hi, I've been asked to comment on the 'no PAM support' comments in the NOTES section of the lsh tar ball. So here are some thoughts. lsh-snapshot-1999-01-28/doc/NOTES says: > 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. The show stoppers: > (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 At first glimpse, it does appear to be a problem. The way ssh works, the server and client deduce a mutually supported list of authentication methods and then the server picks the one that it feels is strongest. There are two approaches to getting PAM into this picture: 1. do as Red Hat have done (see replay) and take some small fraction of the power of PAM and patch sshd to use PAM for things like simple password authentication. This gives the benefit of providing limited hooks to make available some of the access-control possibilities of PAM, but stops short of being a real PAM patch. You can get this half-PAMified ssh on replay. 2. apply the technique used in the following patch for ssh-1.2.x: ftp://linux.kernel.org/pub/linux/libs/pam/pre/applications/ssh-PAM-patch.2.tar.gz this patch attempts to fully support PAM, by adding a 'new' PAM authentication mode to both the client and the server. [In the last week or so there has been some discussion on the ssh mailing list regarding this kind of approach, and someone has indicated that they will be working on creating a generic authentication exchange protocol so clients are ready for almost any kind of authentication.. His motivation is to be able to hack his server to do some home-brew authentication and have 'all' the clients out there able to support it instantly. I believe PAM will find a place as a convenient server backend for this need.] > (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. 2. above addresses most of this. In point of fact PAM (as embodied in libpam) does not really know what is going on either. It is simply a framework for individual modules to drive the authentication process. Its the module (as selected by the local sysadmin) that drives the authentication scheme using the application's transport protocol. the lsh implementation issue: > (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. This is a real misfeature of PAM as invisaged by its original designers. It causes the trouble you discuss here (in single thread applications) and also in graphics applications that tend to have an event driven programming model. To address this problem, in the last few releases, I have been adding event-driven support to PAM. This basically comes down to the fact that the application's conversation function can legitimately return 'data not ready yet' which is acknowledged by the PAM module and control is returned to the application until such time as the conversation data has been obtained. I believe this feature addresses the programming model adopted in lsh. I hope this addresses the concerns listed in NOTES. I'd be happy to discuss PAM further on or off this list (to which I have recently subscribed). Cheers Andrew
