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

["Thomas Wolf (JIRA)" <ji...@apache.org>]

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

Thomas Wolf updated SSHD-866:
-----------------------------
    Summary: Client: keyboard-interactive protocol implementation aborts too early  (was: Keyboard-interactive protocol implementation aborts too early)

> 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
>            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)