I'm new to this list, so please forgive me if this has been discussed before. It appears that one of the (commendable) design goals of OpenSSH is to re-use existing open-source libraries wherever possible in order to simplify the OpenSSH code and hopefully improve security in the process. As exhibited by the current, non-open SSH, supporting all of the nuances of authentication and logins on multiple platforms creates a lot of cases to be handled by the code. 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? It is true that PAM is not present on many platforms, but I presume that PAM could be ported to any system that supports dynamic linking and, if necessary, could even be statically linked if necessary. Again, it may not be the quickest path, but it might be more productive in the long run. ====================================================================Mike Fisk | (505)667-5119 | MS B255 Network Engineering (CIC-5) | | Los Alamos National Lab mfisk at lanl.gov | FAX: 665-7793 | Los Alamos, NM 87545
Despite the fact that i have written pam modules, i am not sure about how it really works, and how it would work in this case. ;) I like the idea of modularizing the authentication, though. But... what happens in the special case where you have to pass some strange data, like a login context? Example: DCE on AIX logging in algorithm: 1) authenticate, certify and validate. This gives you a login context 2) from the login context apprehended in 1), extract group information and set groups 3) throw away the login context apprehended in 1) 3) set uid 4) authenticate with new uid to get a login context. Attach this login context to the process to get network credentials. 5) set up the environment (kerberos ticket data access is in the environment) 6) exec() the shell And even worse, doing an RSA authentication: 1) Somehow transfer your local credentials to the server to enable accessing the public key (can be done with ugly hack at least, i haven't investigated further yet -- i know one thing, machine root usually doesn't (and shouldn't!) automatically have access to user's files) 2) Try RSA authentication 3) set uid while retaining credentials 4) exec() the shell Unless I suffer from total misconception conception, i think we (at least I) would end up with plowing down work in a number of pam modules of virtually no use to the community. Just my $0.02. Regards, Tor-?ke Fransson CAE Systems, Scania CV>From: Mike Fisk <mfisk at lanl.gov> >To: openssh-unix-dev at mindrot.org >Subject: Food for thought regarding PAM >Date: Mon, 29 Nov 1999 17:45:49 +0000 (GMT) > > >I'm new to this list, so please forgive me if this has been discussed >before. > >It appears that one of the (commendable) design goals of OpenSSH is to >re-use existing open-source libraries wherever possible in order to >simplify the OpenSSH code and hopefully improve security in the process. > >As exhibited by the current, non-open SSH, supporting all of the nuances >of authentication and logins on multiple platforms creates a lot of cases >to be handled by the code. > >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? > >It is true that PAM is not present on many platforms, but I presume >that PAM could be ported to any system that supports dynamic >linking and, if necessary, could even be statically linked if >necessary. > >Again, it may not be the quickest path, but it might be more productive in >the long run. > >====================================================================>Mike Fisk | (505)667-5119 | MS B255 >Network Engineering (CIC-5) | | Los Alamos National Lab >mfisk at lanl.gov | FAX: 665-7793 | Los Alamos, NM 87545 > >______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
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.