[
https://issues.apache.org/jira/browse/SSHD-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16130069#comment-16130069
]
Goldstein Lyor commented on SSHD-762:
-------------------------------------
I have reviewed the code and I believe there is some confusion as to the SSH
authentication using passwords:
1. There is actually only *one* password authentication mechanism - the one
specified as {{password}} in [RFC4252 section
8|https://www.ietf.org/rfc/rfc4252.txt].
*Note*: that this is *non-interactive* - meaning, the server cannot determine
what prompts will be shown to the user and how the client should behave if the
authentication is rejected. Specifically for
{{SSH_MSG_USERAUTH_PASSWD_CHANGEREQ}} scenario described in the RFC, SSHD
supports it by checking if the {{PasswordAuthenticator}} threw a
{{PasswordChangeRequiredException}} and generating the appropriate response. In
any case, all it tells the client is that the password needs to be changed -
but it does not tell the client which prompt to show and whether to allow the
user to retry and if so, how many times. All these are at the *client's*
discretion.
2. The {{keyboard-interactive}} protocol described in
[RFC4256|https://tools.ietf.org/html/rfc4256] allows the server to generate a
series of challenge/response at the end of which it can decide whether the user
is "authenticated" - whatever this may mean.
Note that the protocol does not say anything about passwords, retries count,
etc. - it uses an *abstraction* called challenge-response, but what they, what
they mean and how the client must respond to them must be *coordinated* between
client and server. In other words, if the client does not not what challenges
to expect, what they mean and how to behave, then there is nothing the server
can do about it.
In this context, I am not sure that we fully support re-sending a new
{{SSH_MSG_USERAUTH_INFO_REQUEST}} as described
{quote}
After receiving the response, the server MUST send either an
SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
SSH_MSG_USERAUTH_INFO_REQUEST message.
{quote}
which might help towards what you described, but won't overcome the basic
problem of client-server coordination.
Specifically for your code - you can keep track of the "protocol" you describe
via session attributes, but only *your* clients will behave as expected -
generic ones (e.g., {{OpenSSH}}) won't know what to do. It may be the case that
you can reverse-engineer {{OpenSSH}} client and find out what kind of
challenges it know how to respond to, or maybe add a hook to it, but it would
not be a generic solution - the next client might not be {{OpenSSH}} or the
same version...
> Keyboard Interactive Authentication only supports one-time interaction
> ----------------------------------------------------------------------
>
> Key: SSHD-762
> URL: https://issues.apache.org/jira/browse/SSHD-762
> Project: MINA SSHD
> Issue Type: Improvement
> Affects Versions: 1.6.0
> Reporter: Li Fangning
> Assignee: Goldstein Lyor
> Priority: Minor
> Fix For: 1.7.0
>
> Attachments: SshdKeyboardInteractiveSample.java
>
>
> The _org.apache.sshd.server.auth.keyboard.KeyboardInteractiveAuthenticator_
> interface only support one-time interaction with the client.
> Therefore, some features can not be achieved, such as the scenario of the
> expiration of user's password.
> See the second authentication example of [RFC
> 4256|https://www.ietf.org/rfc/rfc4256.txt].
> Regards
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
