[jira] [Closed] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early

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

     [ https://issues.apache.org/jira/browse/SSHD-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Goldstein Lyor closed SSHD-866.
-------------------------------
    Resolution: Not A Bug
      Assignee: Goldstein Lyor

I believe your interpretation of the "keyboard-interactive" RFC is incorrect. Please note that nowhere in the RFC does it say that this authentication method should support password prompting. The RFC mentions a *generic* challenge-response mechanism - not necessarily limited to password prompting nor (as I have mentioned) does it require or even recommend supporting passwords - it only gives an *example* for password prompt, but it also gives other non-password related examples. Furthermore it does not even describe how such an exchange should look like.  Many confuse the examples as some "SHOULD" or "MAY" support indication, but that is definitely not the case.

That being said, the code tries to accommodate the fact that many clients/servers seem to use this protocol for *de-facto* password prompting. The only way we do that is for looking for exactly *one* prompt called "password" - therefore assuming that an empty prompt means "password" seems to violate the RFC's spirit . Let's ask ourselves why limit this only to "password" or empty string - why not add other strings that are interpreted as password requests - e.g., "password ?", "Please enter the password", "Contrasena" (Spanish), etc....

You do have an option though to override this "complimentary" behavior by providing your own {{UserInteraction}} implementation that behaves in some *properietary* manner and replace the default one in {{SshClient}}.

> Client: keyboard-interactive protocol implementation aborts too early
> ---------------------------------------------------------------------
>
>                 Key: SSHD-866
>                 URL: https://issues.apache.org/jira/browse/SSHD-866
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>            Reporter: Thomas Wolf
>            Assignee: Goldstein Lyor
>            Priority: Minor
>
> Keyboard-interactive authentication counts _all_ SSH_MSG_USERAUTH_INFO_REQUESTs against the {{maxTrials}} limit. However, the protocol as specified in [RFC 4256|https://tools.ietf.org/html/rfc4256] allows for info requests without prompts, to which the client must also respond. Such requests should not count towards the {{maxTrials}} limit.
> This is a real-world problem. For instance the sshd server on my Mac replies which such a zero-prompt info request before it sends the SSH_MSG_USERAUTH_SUCCESS. So with the default {{maxTries == 3}}, a login attempt via an sshd using {{UserAuthKeyboardInteractive}} fails if I mis-type the password twice and provide the correct password on the third try because then the zero-prompt info request will be the _fourth_ info request and {{UserAuthKeyboardInteractive}} therefore aborts.
> Here's a log snippet from a normal login _not_ via sshd, which succeeds:
> $ ssh -vvv myself@localhost
>  ...
>  debug1: Next authentication method: keyboard-interactive
>  debug2: userauth_kbdint
>  debug3: send packet: type 50
>  debug2: we sent a keyboard-interactive packet, wait for reply
>  debug3: receive packet: type 60
>  debug2: input_userauth_info_req
>  debug2: input_userauth_info_req: num_prompts 1
>  Password: _<attempt *1*: wrong password entered>_
>  debug3: send packet: type 61
>  debug3: receive packet: type 51
>  debug1: Authentications that can continue: keyboard-interactive
>  debug2: userauth_kbdint
>  debug3: send packet: type 50
>  debug2: we sent a keyboard-interactive packet, wait for reply
>  debug3: receive packet: type 60
>  debug2: input_userauth_info_req
>  debug2: input_userauth_info_req: num_prompts 1
>  Password: _<attempt *2*: wrong password entered>_
>  debug3: send packet: type 61
>  debug3: receive packet: type 51
>  debug1: Authentications that can continue: keyboard-interactive
>  debug2: userauth_kbdint
>  debug3: send packet: type 50
>  debug2: we sent a keyboard-interactive packet, wait for reply
>  debug3: receive packet: type 60
>  debug2: input_userauth_info_req
>  debug2: input_userauth_info_req: num_prompts 1
>  Password: _<attempt *3*: correct password entered>_
>  debug3: send packet: type 61
>  debug3: {color:#ff0000}receive packet: type 60{color}
>  debug2: {color:#ff0000}input_userauth_info_req{color}
>  debug2: {color:#ff0000}input_userauth_info_req: _num_prompts 0_{color}
>  debug3: {color:#ff0000}send packet: type 61{color}
>  debug3: receive packet: type 52
>  debug1: Authentication succeeded (keyboard-interactive).
>  Authenticated to localhost ([::1]:22).
>  ...
>  
> If I do the same with an sshd client, authentication fails because of the {color:#ff0000}red{color} _fourth_ info request. RFC 4256 contains an example showing such an additional zero-prompt info request, though not for a normal authentication but for a password change. But it appears that it can also occur on normal authentications.
> So I think only info requests with {{num_prompts > 0}} should count towards {{maxTrials}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)