Re: Q: your take on SSHD-868 - a.k.a. the dangers of RLE...
On Fri, Nov 16, 2018 at 7:14 PM Lyor Goldstein wrote: > >> In ApacheDS, we decided to limit the size of a PDU to avoid crazy big > (and crafted) messages to be processed. This is of course configurable. I > guess you could do the same. Note that I don't think it makes sense to send > a big chunk of data in SSH, IMO. > > Please note though that the limiting the size of the PDU is not really the > solution. One can send a "small" PDU claiming to contain an array of 2GB of > data (remember - RLE). Therefore any code that first allocates data and > only then tries to read it will be susceptible to out-of-memory errors. > Correct. You still need to check that the length dos not exceed the limit. > >> Otherwise, I'm not a SSH specialist, but it seems that the SSH maximum > packet > size is 32Kb (https://tools.ietf.org/html/rfc4253, par. 6.1). Is it > relevant ? > > I believe it is relevant - you have given me an idea - any code that reads > a length of data should validate that indeed enough data is available to > satisfy the request. I.e., if one declares that the PDU contains X amount > of data, then the code should make sure that indeed the PDU contains at > least X bytes *before* allocating and reading them from the PDU. > > This still leaves code that 1st reads some N and then executes a loop of N > iterations - we need to make sure that the N is of some generous yet > limited size. > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Q: your take on SSHD-868 - a.k.a. the dangers of RLE...
>> In ApacheDS, we decided to limit the size of a PDU to avoid crazy big (and crafted) messages to be processed. This is of course configurable. I guess you could do the same. Note that I don't think it makes sense to send a big chunk of data in SSH, IMO. Please note though that the limiting the size of the PDU is not really the solution. One can send a "small" PDU claiming to contain an array of 2GB of data (remember - RLE). Therefore any code that first allocates data and only then tries to read it will be susceptible to out-of-memory errors. >> Otherwise, I'm not a SSH specialist, but it seems that the SSH maximum packet size is 32Kb (https://tools.ietf.org/html/rfc4253, par. 6.1). Is it relevant ? I believe it is relevant - you have given me an idea - any code that reads a length of data should validate that indeed enough data is available to satisfy the request. I.e., if one declares that the PDU contains X amount of data, then the code should make sure that indeed the PDU contains at least X bytes *before* allocating and reading them from the PDU. This still leaves code that 1st reads some N and then executes a loop of N iterations - we need to make sure that the N is of some generous yet limited size.
Re: Q: your take on SSHD-868 - a.k.a. the dangers of RLE...
Interesting problem... In ApacheDS, we decided to limit the size of a PDU to avoid crazy big (and crafted) messages to be processed. This is of course configurable. I guess you could do the same. Note that I don't think it makes sense to send a big chunk of data in SSH, IMO. Otherwise, I'm not a SSH specialist, but it seems that the SSH maximum packet size is 32Kb (https://tools.ietf.org/html/rfc4253, par. 6.1). Is it relevant ? On Fri, Nov 16, 2018 at 5:47 PM Lyor Goldstein wrote: > The issue recognizes the fact that since SSH packets are RLE (read-length > encoded) it is possible to craft malicious packets that can cause memory > allocation errors due to reporting extremely large lengths of data (up to > 32-bit). We can easily implement some mechanism that executes some sanity > check whenever it decodes a "string" (byte array preceded by a length > specification) or when it allocates an array based on some packet "num-of" > field (e.g., keyboard-interactive challenges count, SFTP number of listed > names, etc). > > The problem with such a mechanism is that we would have to use > *hardwired *internal > limitations that while reasonably "generous", are not part of any RFC, so > in theory (if not in practice) we may too "stingy" and encounter some > client/server that exceeds our internal limitations without being > malicious. > > My question is whether the benefits of "hardening" the code against > malicious packets is worth the cost of loss of flexibility and > compatibility. Especially since such a limitation would not really prevent > malicious packets 100% - e.g., in the case of keyboard-interactive > authentication, even if we limit the number of challenges to several 100's > and the size of each challenge or response to several KB's (...generous - > remember ?...) it can still come out to several MB's - not to mention the > fact that we might be blocking some perfectly "legal" mechanism from > working just because it uses some larger numbers. > > In view of this - should we embark on what are definitely extensive code > changes for this feature ? > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
[jira] [Commented] (SSHD-867) HostConfigEntry.getProperty(String name, String defaultValue) may return null even if defaultValue != null
[
https://issues.apache.org/jira/browse/SSHD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689686#comment-16689686
]
Goldstein Lyor commented on SSHD-867:
-
Fixed by
[01fc9fec8d9790767b5def1f6aad21922a25ba29|https://github.com/apache/mina-sshd/commit/01fc9fec8d9790767b5def1f6aad21922a25ba29]
> HostConfigEntry.getProperty(String name, String defaultValue) may return null
> even if defaultValue != null
> --
>
> Key: SSHD-867
> URL: https://issues.apache.org/jira/browse/SSHD-867
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Thomas Wolf
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> {{HostConfigEntry.getProperty(String name, String defaultValue)}} contains
> {code:java}
> Map props = getProperties();
> if (GenericUtils.isEmpty(props)) {
> return null;
> }{code}
> This should be
> {code:java}
> Map props = getProperties();
> if (GenericUtils.isEmpty(props)) {
> return defaultValue;
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early
[
https://issues.apache.org/jira/browse/SSHD-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-866.
-
Resolution: Fixed
Fix Version/s: 2.1.1
Fixed by
[34ac8a7ad6c6116674805e57f543ed247a2832ab|https://github.com/apache/mina-sshd/commit/34ac8a7ad6c6116674805e57f543ed247a2832ab]
> 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
> Fix For: 2.1.1
>
>
> 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: __
> 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: __
> 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: __
> debug3: send packet: type 61
> debug3: {color:#ff}receive packet: type 60{color}
> debug2: {color:#ff}input_userauth_info_req{color}
> debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
> debug3: {color:#ff}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:#ff}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)
Q: your take on SSHD-868 - a.k.a. the dangers of RLE...
The issue recognizes the fact that since SSH packets are RLE (read-length encoded) it is possible to craft malicious packets that can cause memory allocation errors due to reporting extremely large lengths of data (up to 32-bit). We can easily implement some mechanism that executes some sanity check whenever it decodes a "string" (byte array preceded by a length specification) or when it allocates an array based on some packet "num-of" field (e.g., keyboard-interactive challenges count, SFTP number of listed names, etc). The problem with such a mechanism is that we would have to use *hardwired *internal limitations that while reasonably "generous", are not part of any RFC, so in theory (if not in practice) we may too "stingy" and encounter some client/server that exceeds our internal limitations without being malicious. My question is whether the benefits of "hardening" the code against malicious packets is worth the cost of loss of flexibility and compatibility. Especially since such a limitation would not really prevent malicious packets 100% - e.g., in the case of keyboard-interactive authentication, even if we limit the number of challenges to several 100's and the size of each challenge or response to several KB's (...generous - remember ?...) it can still come out to several MB's - not to mention the fact that we might be blocking some perfectly "legal" mechanism from working just because it uses some larger numbers. In view of this - should we embark on what are definitely extensive code changes for this feature ?
[jira] [Created] (SSHD-868) Add some protection against maliciously crafted packets
Goldstein Lyor created SSHD-868:
---
Summary: Add some protection against maliciously crafted packets
Key: SSHD-868
URL: https://issues.apache.org/jira/browse/SSHD-868
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor
According to [RFC4256 - section 3.2|https://tools.ietf.org/html/rfc4256]
{quote}
The server SHOULD take into consideration that some clients may not
be able to properly display a long name or prompt field (see next
section), and limit the lengths of those fields if possible.
{quote}
The current code in {{UserAuthKeyboardInteractive#processAuthDataRequest}} does
not make sure that the number of challenges or the length of each challenge is
reasonable (not to mention the other packet components). Therefore, a
maliciously crafted packet can cause out-of-memory errors by requesting an
extremely large number of responses or sending very large challenges.
It is important to notice that this problem is not limited to the
{{keyboard-interactive}} protocol but to the entire packet encode/decode
mechanism since it is a RLE (read-length encoding). Wherever possible we should
add some reasonable but large enough limitations on the expected size of
strings/arrays/etc.. being decoded from incoming SSH packets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Next MINA release (2.0.20?)
That's great, thank you. Greg On Tue, 13 Nov 2018 at 22:50, Emmanuel Lecharny wrote: > We probably can get a release with only this issue being fixed. I would > suggest we test it on Java 11 (Java 10 is not going to be supported while > 11 is LTS). > > On Tue, Nov 13, 2018 at 4:55 PM Greg Thomas > wrote: > > > Hi there, > > > > Are there any plans for a new release of MINA anytime soon? I ask because > > we're blocked on Java 10+ support because of > > https://issues.apache.org/jira/browse/DIRMINA-1088 which, although > fixed, > > has yet to be included in a release. > > > > Is there anything we can do to help push a release through? > > > > Thanks, > > > > Greg > > > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
[jira] [Resolved] (SSHD-867) HostConfigEntry.getProperty(String name, String defaultValue) may return null even if defaultValue != null
[
https://issues.apache.org/jira/browse/SSHD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-867.
-
Resolution: Fixed
Fix Version/s: 2.1.1
> HostConfigEntry.getProperty(String name, String defaultValue) may return null
> even if defaultValue != null
> --
>
> Key: SSHD-867
> URL: https://issues.apache.org/jira/browse/SSHD-867
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Thomas Wolf
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> {{HostConfigEntry.getProperty(String name, String defaultValue)}} contains
> {code:java}
> Map props = getProperties();
> if (GenericUtils.isEmpty(props)) {
> return null;
> }{code}
> This should be
> {code:java}
> Map props = getProperties();
> if (GenericUtils.isEmpty(props)) {
> return defaultValue;
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early
[
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: __
> 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: __
> 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: __
> debug3: send packet: type 61
> debug3: {color:#ff}receive packet: type 60{color}
> debug2: {color:#ff}input_userauth_info_req{color}
> debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
> debug3: {color:#ff}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:#ff}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)
[jira] [Assigned] (SSHD-867) HostConfigEntry.getProperty(String name, String defaultValue) may return null even if defaultValue != null
[
https://issues.apache.org/jira/browse/SSHD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor reassigned SSHD-867:
---
Assignee: Goldstein Lyor
> HostConfigEntry.getProperty(String name, String defaultValue) may return null
> even if defaultValue != null
> --
>
> Key: SSHD-867
> URL: https://issues.apache.org/jira/browse/SSHD-867
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Thomas Wolf
>Assignee: Goldstein Lyor
>Priority: Minor
>
> {{HostConfigEntry.getProperty(String name, String defaultValue)}} contains
> {code:java}
> Map props = getProperties();
> if (GenericUtils.isEmpty(props)) {
> return null;
> }{code}
> This should be
> {code:java}
> Map props = getProperties();
> if (GenericUtils.isEmpty(props)) {
> return defaultValue;
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-867) HostConfigEntry.getProperty(String name, String defaultValue) may return null even if defaultValue != null
[
https://issues.apache.org/jira/browse/SSHD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-867 started by Goldstein Lyor.
---
> HostConfigEntry.getProperty(String name, String defaultValue) may return null
> even if defaultValue != null
> --
>
> Key: SSHD-867
> URL: https://issues.apache.org/jira/browse/SSHD-867
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Thomas Wolf
>Assignee: Goldstein Lyor
>Priority: Minor
>
> {{HostConfigEntry.getProperty(String name, String defaultValue)}} contains
> {code:java}
> Map props = getProperties();
> if (GenericUtils.isEmpty(props)) {
> return null;
> }{code}
> This should be
> {code:java}
> Map props = getProperties();
> if (GenericUtils.isEmpty(props)) {
> return defaultValue;
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early
[
https://issues.apache.org/jira/browse/SSHD-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689555#comment-16689555
]
Goldstein Lyor edited comment on SSHD-866 at 11/16/18 3:31 PM:
---
In view of
{quote:title=RFC 4256 section 3.4}
In the case that the server sends a `0' num-prompts field in the request
message, the client MUST send a response message with a `0' num-responses field
to complete the exchange.
{quote}
{quote}
So I think only info requests with num_prompts > 0 should count towards
maxTrials.
{quote}
Seems a reasonable request
was (Author: lgoldstein):
{quote}
In the case that the server sends a `0' num-prompts field in the request
message, the client MUST send a response message with a `0' num-responses field
to complete the exchange.
{quote}
Seems a reasonable request
> 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: __
> 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: __
> 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: __
> debug3: send packet: type 61
> debug3: {color:#ff}receive packet: type 60{color}
> debug2: {color:#ff}input_userauth_info_req{color}
> debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
> debug3: {color:#ff}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:#ff}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)
[jira] [Commented] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early
[
https://issues.apache.org/jira/browse/SSHD-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689555#comment-16689555
]
Goldstein Lyor commented on SSHD-866:
-
{quote}
In the case that the server sends a `0' num-prompts field in the request
message, the client MUST send a response message with a `0' num-responses field
to complete the exchange.
{quote}
Seems a reasonable request
> 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: __
> 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: __
> 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: __
> debug3: send packet: type 61
> debug3: {color:#ff}receive packet: type 60{color}
> debug2: {color:#ff}input_userauth_info_req{color}
> debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
> debug3: {color:#ff}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:#ff}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)
[jira] [Issue Comment Deleted] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early
[
https://issues.apache.org/jira/browse/SSHD-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-866:
Comment: was deleted
(was: 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: __
> 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: __
> 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: __
> debug3: send packet: type 61
> debug3: {color:#ff}receive packet: type 60{color}
> debug2: {color:#ff}input_userauth_info_req{color}
> debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
> debug3: {color:#ff}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:#ff}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 req
[jira] [Reopened] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early
[
https://issues.apache.org/jira/browse/SSHD-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor reopened SSHD-866:
-
> 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: __
> 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: __
> 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: __
> debug3: send packet: type 61
> debug3: {color:#ff}receive packet: type 60{color}
> debug2: {color:#ff}input_userauth_info_req{color}
> debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
> debug3: {color:#ff}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:#ff}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)
[jira] [Closed] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early
[
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: __
> 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: __
> 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: __
> debug3: send packet: type 61
> debug3: {color:#ff}receive packet: type 60{color}
> debug2: {color:#ff}input_userauth_info_req{color}
> debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
> debug3: {color:#ff}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:#ff}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.
> S
[jira] [Commented] (SSHD-860) org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client identities (private key files)
[
https://issues.apache.org/jira/browse/SSHD-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689536#comment-16689536
]
Goldstein Lyor commented on SSHD-860:
-
Correct - we always mark fixed issues with the *tentative* next version. It
would have been 2.1.1 if we did not break backward compatibility. This issue
does not, but there are other issue that we fixed/added that do - so the next
version will probably be 2.2 or higher. In other words there will *not* be a
2.1.1 release - however, since we have not decided yet what the next release
version is, we use 2.1.1 as a *convenience* marker to say "next version".
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client
> identities (private key files)
>
>
> Key: SSHD-860
> URL: https://issues.apache.org/jira/browse/SSHD-860
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0, 2.1.0, 2.1.1
>Reporter: Thomas Wolf
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} loads and
> caches in memory private keys prematurely. Keys are loaded even if they are
> not used at all in the end. In other words, incremental loading of keys
> doesn't work.
> This is bad for two reasons:
> # Private keys should be kept in memory only if and when needed. Loading
> completely unused private keys must be avoided.
> # With encrypted private keys, the user may end up being asked for
> passphrases for keys that are not used at all in the end, which is highly
> disruptive.
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} does in its
> constructor:
> {code:java}
> Iterator current;
> Collection> identities = new
> LinkedList<>();
> ...
> identities.add(Stream.of(ClientSession.providerOf(session))
> .map(KeyIdentityProvider::loadKeys)
> .flatMap(GenericUtils::stream)
> .map(kp -> new KeyPairIdentity(signatureFactories, session, kp)));
> current = identities.stream().flatMap(r -> r).iterator();
> {code}
> The final {{current}} iterator uses some internal buffer (size unknown;
> didn't try to determine it) and will pre-fill this buffer completely. So with
> buffer size _N_ it'll pre-load the first _N_ keys from the combined identity
> stream. If the first key authenticates successfully, loading all the others
> must not be done.
> See my [test
> case|https://github.com/tomaswolf/mina-sshd/blob/SSHD-860/sshd-core/src/test/java/org/apache/sshd/client/ClientKeyLoadTest.java]
> showing this faulty behavior. It does exactly the same as the
> {{UserAuthPublicKeyIterator}} constructor, using two iterators with two
> identity files each, and then tests the resulting iterator. The first
> {{hasNext()/next()}} call on the {{current}} iterator _loads all four keys!_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-860) org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client identities (private key files)
[
https://issues.apache.org/jira/browse/SSHD-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16689430#comment-16689430
]
Konrad Windszus commented on SSHD-860:
--
[~lgoldstein] Does that mean the fix-version 2.1.1 indicated on this JIRA is
not correct?
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client
> identities (private key files)
>
>
> Key: SSHD-860
> URL: https://issues.apache.org/jira/browse/SSHD-860
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0, 2.1.0, 2.1.1
>Reporter: Thomas Wolf
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} loads and
> caches in memory private keys prematurely. Keys are loaded even if they are
> not used at all in the end. In other words, incremental loading of keys
> doesn't work.
> This is bad for two reasons:
> # Private keys should be kept in memory only if and when needed. Loading
> completely unused private keys must be avoided.
> # With encrypted private keys, the user may end up being asked for
> passphrases for keys that are not used at all in the end, which is highly
> disruptive.
> {{org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator}} does in its
> constructor:
> {code:java}
> Iterator current;
> Collection> identities = new
> LinkedList<>();
> ...
> identities.add(Stream.of(ClientSession.providerOf(session))
> .map(KeyIdentityProvider::loadKeys)
> .flatMap(GenericUtils::stream)
> .map(kp -> new KeyPairIdentity(signatureFactories, session, kp)));
> current = identities.stream().flatMap(r -> r).iterator();
> {code}
> The final {{current}} iterator uses some internal buffer (size unknown;
> didn't try to determine it) and will pre-fill this buffer completely. So with
> buffer size _N_ it'll pre-load the first _N_ keys from the combined identity
> stream. If the first key authenticates successfully, loading all the others
> must not be done.
> See my [test
> case|https://github.com/tomaswolf/mina-sshd/blob/SSHD-860/sshd-core/src/test/java/org/apache/sshd/client/ClientKeyLoadTest.java]
> showing this faulty behavior. It does exactly the same as the
> {{UserAuthPublicKeyIterator}} constructor, using two iterators with two
> identity files each, and then tests the resulting iterator. The first
> {{hasNext()/next()}} call on the {{current}} iterator _loads all four keys!_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-867) HostConfigEntry.getProperty(String name, String defaultValue) may return null even if defaultValue != null
Thomas Wolf created SSHD-867:
Summary: HostConfigEntry.getProperty(String name, String
defaultValue) may return null even if defaultValue != null
Key: SSHD-867
URL: https://issues.apache.org/jira/browse/SSHD-867
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Thomas Wolf
{{HostConfigEntry.getProperty(String name, String defaultValue)}} contains
{code:java}
Map props = getProperties();
if (GenericUtils.isEmpty(props)) {
return null;
}{code}
This should be
{code:java}
Map props = getProperties();
if (GenericUtils.isEmpty(props)) {
return defaultValue;
}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early
[
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: __
> 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: __
> 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: __
> debug3: send packet: type 61
> debug3: {color:#ff}receive packet: type 60{color}
> debug2: {color:#ff}input_userauth_info_req{color}
> debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
> debug3: {color:#ff}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:#ff}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)
[jira] [Created] (SSHD-866) Keyboard-interactive protocol implementation aborts too early
Thomas Wolf created SSHD-866:
Summary: 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
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: __
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: __
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: __
debug3: send packet: type 61
debug3: {color:#ff}receive packet: type 60{color}
debug2: {color:#ff}input_userauth_info_req{color}
debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
debug3: {color:#ff}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:#ff}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)
