Andrew Morgan writes:
> The non-tty input methods we implemented were via a single 'BINARY'
> message type.
What authentication methods there are that use those BINARY messages?
I am not talking about what might be, I am talking about what
currently exists?
> Each binary message contained some indication of how the message was to
> be used. The typical approach was for the server to send a binary
> message ('binary-prompt') requesting that a given flavor of
> authentication was initialized, the client would do this if it possessed
> the corresponding PAM-agent and subsequent binary-prompts would be
> directed to the agent for client side processing and the return of a
> corresponding binray-prompt with the processed authentication
> information. Not possessing the PAM-agent, the client would so state and
> the server would be given the chance to offer some other method. This
> approach could be configured from the PAM configuration file (by the
> server's sys admin) and it was then possible to dynamically support all
> flavors of authentication scheme in a way that the server's admin could
> control/combine. (All without recompiling ssh again. :^)
So this seems to be same thing that the ssh-agent does?
> I'd like to see this sort of authentication prompting supported by the
> eventual form of this authentication draft.
>
> The client/server telling all regarding supported methods on the first
> exchange, does not gel well with PAM as it is currently implemented. In
> this generic authentication environment, I'd be happy to learn why this
> is an important requirement.
No, the server never gives out list of supported methods, it gives out
list of possible continuations of the authentication exchange. That
list may change over the authentication process. It might for example
fist only offer hostbased authentication and after that has been
successfully performed, it will say that ok, that was partial success,
now the user still must do either rsa or password authentication. The
list is sent out in each SSH_MSG_USERAUTH_FAILURE message and it may
change.
--
[EMAIL PROTECTED] Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
