[jira] [Comment Edited] (SSHD-762) Keyboard Interactive Authentication only supports one-time interaction

["Goldstein Lyor (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SSHD-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16130069#comment-16130069 ] 

Goldstein Lyor edited comment on SSHD-762 at 8/17/17 8:10 AM:
--------------------------------------------------------------

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, 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 know 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...


was (Author: lgoldstein):
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)