Niels M�ller writes:
> The existing ssh userauth mechanisms lets the client side "drive" the
> authentication process; the user decides, for instance, whether to
> attempt login using a password or using some smartcard.
No. The current userauth mechanisms allows either side "drive" the
authentication. If the server wants to drive the authentication it
only offers one authentication method at time to the clinet, and
client has to do that or fail. If the server wants to allow client to
drive the it can just give the full list.
> PAM, in its current incarnations, is not well suited for ssh2 style
> user authentication. For instance it is more or less impossible for a
> PAM-aware ssh server to find out the correct list of methods for the
> "authentications that can continue" field of the USERAUTH_FAILURE
> message.
If it is text-base keyboard-query-response then it willmost likely to
be password. The following conversation is quite possible in the ssh2
protocol:
C: SSH_MSG_USERAUTH_REQUEST, "kivinen", "service", "none"
S: SSH_MSG_USERAUTH_BANNER, "Enter normal password for kivinen", en_EN
S: SSH_MSG_USERAUTH_FAILURE, "password", FALSE
C: SSH_MSG_USERAUTH_REQUEST, "kivinen", "service", "password", FALSE, "foobar"
S: SSH_MSG_USERAUTH_BANNER, "Enter one time password 23 for kivinen", en_EN
S: SSH_MSG_USERAUTH_FAILURE, "password", TRUE
C: SSH_MSG_USERAUTH_REQUEST, "kivinen", "service", "password", FALSE, "01201"
S: SSH_MSG_USERAUTH_SUCCESS
Only thing here missing is the ability to ask password that are
allowed to be echoed to screen. Also using banner to send text
messages is not really the intendend use for it...
> The point of the proposal, as I understand it, is to create a more
> PAM-friendly mechanism, where the server tells the client what it has
> to do at each step. I.e., the authentication process is driven by
> the PAM-framework, which speaks more or less directly with the client
> side. And where the level of abstraction in these message is similar
> to PAM's.
I don't really know anything about the PAM, so I cannot say if it can
be implemented using userauth or not.
> (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.
This can be kludged around using the BANNER and "password"
authentication method.
--
[EMAIL PROTECTED] Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
