[ https://issues.apache.org/jira/browse/SSHD-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on SSHD-866 started by Goldstein Lyor. ------------------------------------------- > 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)