Well, I regard the draft as only a half-step forward as this
functionality might be embraced by more generic authentication method,
providing for interaction between server and client authentication
*modules*. Interactive authentication being just one - or several - of the
unlimited set of modules.
The lack of stable pam specification for client side does not prevent us
from implementing "built-in" modules.
[Ssh in fact went this way - but without providing for modular
extendability. The result was separate "ssh*config" files to administer,
providing partially for the same functionality as pam.conf]
On Wed, 24 Feb 1999, Frank Cusack wrote:
> > multiple methods availbale (for example both SecurID and CryptoCard).
> > This list should be normally be provided by the user. The server should
> > also be able to ignore this field if it knows from some other context
> > which method(s) are avilable for the user.
>
> This requires client knowledge of the auth device; and a new client
> would be required for each auth device. One of the goals was to
> not require new client code to support new authentications that
> /could/ be handled by existing methods.
>From my point of view the main reason for defining the new
authentication type is a possibility to plug-in authentication modules on
both servers and clients. PAM (needing extention, of course) provides por
pluggability and ssh provides for communication.
As I'd like to see it (in the ideal world), *all* authentication methods,
including all sorts of public key authentication, should reside out of ssh
code, ssh being responsible for the rest (encrypted connection and traffic
forwarding).
> As many noticed, this draft really is meant for PAM, which is indeed
> a generic keyboard-interactive authentication. I added the non-keyboard
> types to attempt to deal with PAM_BINARY, but I do agree that it is
> too limiting to add that into this draft. Also, PAM_BINARY is really
> a kludge to make PAM do things that the original design didn't
> account for.
I think Andrew Morgan talked about client-side PAM module specification
that is not yet finished. Isn't it the time to discuss it in more
details?
Looks like both ssh and pam specifications are missing important parts to
be able to adequately support wide range of connectivity/authentication
needs. They should become aware of each others concepts. The sooner the
better.
Regards,
--
Ivan Popov <[EMAIL PROTECTED]>
Systemman, Driftavdelningen, Matematiska institutionen, Chalmers TH
