Andrew Morgan <[EMAIL PROTECTED]> writes: > 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) 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: Hmm, ssh2 user authentication does not work quite like that. The client tries one authentication method at a time. The server responds with either "success", "failure", "partial success, but more authentiction is needed", or some method specific message like "please choose a new password". In the failure and partial success cases, the server also sends the client a list of methods which are likely (although in no way guaranteed) to provide some progress in authentication. The client can attempt the authentication "none" (which will usually fail), if it wants to get the server's list of methods before proceeding. Typically, the client will first make attempts to log in using each of its keys (these attempts may be performed in parallell). If none of the keys are accepted, it will ask the user for her password and try password authentication (unless the server indicates that password authentication is pointless). So the server really needs to be able to query the backend, be it PAM or something else, for its supported methods. And it must be able to try specific methods, one at a time. > 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. I'm afraid I don't have the time to look closely at PAM in the immediate future, but if the practical problems (2 and 3 below) are solved, that would make it possible to use PAM for simple password authentication. > 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.] It seems somewhat against the spirit of PAM to have specialized application-specific PAM-modules. With PAM, you really want to use the same, say, passwd-module or .authorized_keys-module for all applications where you want to allow that authentication method. I considered this approach very briefly. But as lsh must have support for all sorts of PAM-less platforms anyway, it seems like a lot a work for little gain. But perhaps it is worth I try when the PAM-less version works and things like the format for the .lsh/authorized_keys file is stable. > > 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. I guess I have to read the code to understand how it solves this problem. I would suspect that it requires some bending of the "standard" PAM conversation function conventions. > 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. This sounds great. If PAM moves in this direction, I think I want to reconsider using it. Which PAM implementation are you referring to here (Linux, Solaris, something else)? To get a redesigned conversation mechanism into the PAM "standard" would be a real improvement. It is now some time since I looked at PAM, so I don't remember exactly how I thought about it. Anyway, my wish-list, to make PAM more useable, includes: 1. A mechanism to get a listing of supported authentication methods. 2. A mechanism to attempt authentication using a method chosen _by the application_. A redesigned conversation mechanism that improves two things: 3. Support for event-driven (or non-blocking) operation. 4. An extra message field saying what the authentication module really wants. The interpretation if this field will naturally depend on the actual authentication method used. So it is probably pretty meaningless for applications that does not use (2). This field would actually be a pair, <authentication method, message>. Regards, /Niels
