Andrew Morgan <[EMAIL PROTECTED]> writes:
> OK, I was a little sloppy. This was my sketchy(poor) recollection from
> ssh-1.2.x which was what Andrey and I wrote our patch for.
It's a long time since I read the ssh-1.x spec. But ssh2 is quite
different, in many respects. The userauth draft can be found at
ftp://ftp.lysator.liu.se/pub/security/lsh/docs/userauth.ps.
> PAM is a little more sophisticated than this. You can build logic into
> the authentication sequence that PAM will use. For example, the admin
> might adopt the following policy: if the applicant is attempting to
> become root, then lets ask him for a retinal scan; lesser users can
> simply get by with a one time password the guest user need only submit
> an email address (which may or may not be be verified before the user is
> permitted access). PAM provides a rich syntax for the local system
> administrator to dynamically reconfigure the local authentication
> policy. Something that once the server has support for it, can be
> changed as often as desired without recompiling the server (lshd).
I have read the PAM docs, so I'm reasonably aware of what it is
designed to do. Even if I don't have any experience with using or
configuring PAM.
> By design, the PAM modules are intended to be independent of the
> application they are used with. PAM is, in principle, capable of
> dynamically reproducing the whole gamut of currently supported (by ssh)
> authentication schemes plus others yet to be implemented.
>
> > 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.
>
> Since all methods can be supported by PAM, its not actually clear why
> the application needs to care which one was used: just let the admin
> configure his specified selection and let PAM deal with it.
I think this illustrates quite clearly the different approach to user
authentication in PAM and in the ssh2 protocol. With PAM, the sysadm
controls the authentication process completely. In ssh2, the *client*
decides which authentication method to try, and in which order. To
guide these decisions, the client can ask the server which methods are
likely to be useful; it would be a little stupid if the client asked
the user to type in one or more long passwords or passphrases even if
the administrator or user at the server have disabled password
authentication.
You're very right in that the information about supported methods is
not really needed by the ssh server. But it is needed by the ssh
*client*. And the only way the client can get the information is from
the server, which in turn must be able to get it from PAM.
> > 1. A mechanism to get a listing of supported authentication
> > methods.
>
> I guess I'm so close to PAM, that I cannot see why this would be
> necessary. Since the sysadmin owns the server, it seems as if he's the
> one to specify exactly what combination/order of authentications will
> get individual users into his system. Other than supporting the PAM API,
> what more does the client/server need to agree on?
I hope I have explained that clearly above.
> > 2. A mechanism to attempt authentication using a method chosen _by the
> > application_.
>
> Again, getting a binary compiled every time one (re)makes this decision
> is the problem PAM was invented to address. PAM liberates the
> application writer from caring about which authentication method is to
> be used and puts it squarely in the hands of the sysadmin.
Again, with ssh2, the *client* decides which authentication method it
wants to try. The server simply has to obey. I'm asking for some
mechanism in PAM that lets the server do that.
> > 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>.
>
> Given what PAM is supposed to do, is this still of concern? If so
> perhaps you could elaborate?
As a simple example, let's look at simple password authentication. The
clients sends a message "I want to log in as user 'nisse', using
password authentication. The password is 'gazonk'". Now the server
will invoke PAM (and preferable it will somehow tell PAM not to
attempt anything but password authentication). PAM may call the
conversation function for at least two reasons:
1. To read the password.
In this case, the server should supply the password 'gazonk' already
provided by the client.
2. The password is old, and PAM will want to read the old password,
and a new password (twice).
In this case, the server should send a "password change requested"
message to the client. If the clients agrees to change the password,
it responds with a password change request, which contains both the
old and a new password.
The server must be able to distinguish between these two cases. The
extra field I ask for provides a reasonable clean way to do that.
This example also highlights the different abstraction levels: PAM
will try to speak with the user directly, and therefore asks for the
new password to be typed twice. But in the ssh2 protocol, that is a
client issue only; the protocol message to change the password
contains the user name, the old password and the new password, and
nothing else.
With the current (lack of) abstraction in the PAM conversation
mechanism, the ssh server will have to *reconstruct* abstracted
messages that represent the actions that PAM really wants.
I'm afraid that ssh2 user authenticaion is a very atypical PAM
application. But perhaps a redesigned conversation mechanism could
satisfy both applications like ssh that needs to handle *particular*
authentication methods and messages, and more traditional PAM
applications which want to let PAM do all the work, just like it was
designed to do.
One other difference, that may cause some problems, is that a user
should be able to configure the authorization for his or her account.
For instance, there may be some ACL somewhare under ~/.lsh that says
that anybody with a key certified by a certain other key (most likely
owned by the user in question) is allowed to login, or to execute some
particular command as that user.
Regards,
/Niels
