[jira] [Updated] (SSHD-863) Add local/remote port forwarding to/from Unix sockets
[ https://issues.apache.org/jira/browse/SSHD-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goldstein Lyor updated SSHD-863: Labels: future wishlist (was: ) > Add local/remote port forwarding to/from Unix sockets > - > > Key: SSHD-863 > URL: https://issues.apache.org/jira/browse/SSHD-863 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Björn Kautler >Assignee: Goldstein Lyor >Priority: Minor > Labels: future, wishlist > > Would be nice if MINA SSHD also supports forwarding sockets, not only ports. > Currently you can only forward from port to port, but SSH now can do from > port to socket, from socket to port, from port to port and from port to > socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-868) Add some protection against maliciously crafted packets
[
https://issues.apache.org/jira/browse/SSHD-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690968#comment-16690968
]
Goldstein Lyor commented on SSHD-868:
-
There are a few more such pitfalls that 1st allocate and then try to loop or
just loop - see [commit
db6e5b5344dcf687ad01a6d7bc94cfa531809d37|https://github.com/apache/mina-sshd/commit/db6e5b5344dcf687ad01a6d7bc94cfa531809d37],
and also [commit
775f34955151d6ec241a1ad3a634c53a87386a64|https://github.com/apache/mina-sshd/commit/775f34955151d6ec241a1ad3a634c53a87386a64]
> 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
>Priority: Major
> Labels: memory, overflow, security
> Fix For: 2.1.1
>
>
> 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)
[jira] [Work started] (SSHD-865) Use lazy-loading for keys specified in the HostConfigEntry
[
https://issues.apache.org/jira/browse/SSHD-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-865 started by Goldstein Lyor.
---
> Use lazy-loading for keys specified in the HostConfigEntry
> --
>
> Key: SSHD-865
> URL: https://issues.apache.org/jira/browse/SSHD-865
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> Following SSHD-860 key loading occurs lazily - thus encrypted keys password
> is not requested until the key is actually needed. The exception to this rule
> are keys specified as part of a {{HostConfigEntry}} specified in an
> [ssh_config file|http://www.gsp.com/cgi-bin/man.cgi?topic=ssh_config].
> h5. Implementation details
> * Need to change {{SshClient#loadClientIdentities}} to return a
> {{KeyPairProvider}} that is propagated all the way to
> {{SshClient#onConnectOperationComplete}}.
> * The code in {{SshClient#onConnectOperationComplete}} should check after
> {{setupDefaultSessionIdentities}} if there is a non-empty {{KeyPairProvider}}
> propagated and *aggregate* it with any already set such provider on the
> session
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-868) Add some protection against maliciously crafted packets
[
https://issues.apache.org/jira/browse/SSHD-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-868.
-
Resolution: Fixed
Fix Version/s: 2.1.1
> 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
>Priority: Major
> Labels: memory, overflow, security
> Fix For: 2.1.1
>
>
> 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)
[jira] [Resolved] (SSHD-864) Provide initial private key resource object used to read its data when loading a key
[
https://issues.apache.org/jira/browse/SSHD-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-864.
-
Resolution: Fixed
Fix Version/s: 2.1.1
> Provide initial private key resource object used to read its data when
> loading a key
>
>
> Key: SSHD-864
> URL: https://issues.apache.org/jira/browse/SSHD-864
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> The current code propagates only a string representation of the "source" of a
> private key's data when it is being read. This source however, could be a
> {{Path}}, {{URL}}, {{URI}} or just a plain old path string. This information
> is "lost" when the code reaches supporting interfaces such as the
> {{FilePasswordProvider}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-868) Add some protection against maliciously crafted packets
[
https://issues.apache.org/jira/browse/SSHD-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-868 started by Goldstein Lyor.
---
> 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
>Priority: Major
> Labels: memory, overflow, security
>
> 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)
[jira] [Resolved] (SSHD-862) Provide session context to FilePasswordProvider
[
https://issues.apache.org/jira/browse/SSHD-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-862.
-
Resolution: Fixed
Fix Version/s: 2.1.1
> Provide session context to FilePasswordProvider
> ---
>
> Key: SSHD-862
> URL: https://issues.apache.org/jira/browse/SSHD-862
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> Provide the session context (if known) to the {{FilePasswordProvider}} -
> e.g., decide on different behavior based on the session attributes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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=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)
[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)
[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] [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] [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=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=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
[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.
>
[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=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] [Assigned] (SSHD-863) Add local/remote port forwarding to/from Unix sockets
[ https://issues.apache.org/jira/browse/SSHD-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goldstein Lyor reassigned SSHD-863: --- Assignee: Goldstein Lyor > Add local/remote port forwarding to/from Unix sockets > - > > Key: SSHD-863 > URL: https://issues.apache.org/jira/browse/SSHD-863 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Björn Kautler >Assignee: Goldstein Lyor >Priority: Minor > > Would be nice if MINA SSHD also supports forwarding sockets, not only ports. > Currently you can only forward from port to port, but SSH now can do from > port to socket, from socket to port, from port to port and from port to > socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-863) Add local/remote port forwarding to/from Unix sockets
[ https://issues.apache.org/jira/browse/SSHD-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688293#comment-16688293 ] Goldstein Lyor commented on SSHD-863: - Thanks - I will look them over, but like I said - we have very limited R resources so unless it is relatively easy to add the required support or it becomes a popular request I don't see it done in the near future unless someone decide it is important enough for them to undertake and make the contribution. > Add local/remote port forwarding to/from Unix sockets > - > > Key: SSHD-863 > URL: https://issues.apache.org/jira/browse/SSHD-863 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Björn Kautler >Priority: Minor > > Would be nice if MINA SSHD also supports forwarding sockets, not only ports. > Currently you can only forward from port to port, but SSH now can do from > port to socket, from socket to port, from port to port and from port to > socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-863) Add local/remote port forwarding to/from Unix sockets
[
https://issues.apache.org/jira/browse/SSHD-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688137#comment-16688137
]
Goldstein Lyor commented on SSHD-863:
-
{quote}
For documentation for example look at the ssh man page at
https://man.openbsd.org/ssh. The description of the -L and -R options.
{quote}
We support the IP local/remote port forwarding in full - both on server and
client. As far as _Unix_ sockets are concerned, there is no available Java
library that I am aware of that provides this service since it involves
*native* code. If you can recommend a good framework for it then we can think
about this issue. However, since the feature is not in great demand (thus
marked it as _Minor_), you might want to consider adding such support yourself
(see _sshd-contrib_ package) - with some help from us. It can be a good
exercise in using SSHD library as well as a welcome contribution. If it does
become very popular we may consider adding support for it - again, depending on
the availability of some 3rd party library that can provide this kind of
support.
> Add local/remote port forwarding to/from Unix sockets
> -
>
> Key: SSHD-863
> URL: https://issues.apache.org/jira/browse/SSHD-863
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Björn Kautler
>Priority: Minor
>
> Would be nice if MINA SSHD also supports forwarding sockets, not only ports.
> Currently you can only forward from port to port, but SSH now can do from
> port to socket, from socket to port, from port to port and from port to
> socket.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SSHD-863) Add local/remote port forwarding to/from Unix sockets
[ https://issues.apache.org/jira/browse/SSHD-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goldstein Lyor updated SSHD-863: Priority: Minor (was: Major) > Add local/remote port forwarding to/from Unix sockets > - > > Key: SSHD-863 > URL: https://issues.apache.org/jira/browse/SSHD-863 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Björn Kautler >Priority: Minor > > Would be nice if MINA SSHD also supports forwarding sockets, not only ports. > Currently you can only forward from port to port, but SSH now can do from > port to socket, from socket to port, from port to port and from port to > socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SSHD-863) Add local/remote port forwarding to/from Unix sockets
[ https://issues.apache.org/jira/browse/SSHD-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goldstein Lyor updated SSHD-863: Summary: Add local/remote port forwarding to/from Unix sockets (was: Forwarding sockets) > Add local/remote port forwarding to/from Unix sockets > - > > Key: SSHD-863 > URL: https://issues.apache.org/jira/browse/SSHD-863 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Björn Kautler >Priority: Major > > Would be nice if MINA SSHD also supports forwarding sockets, not only ports. > Currently you can only forward from port to port, but SSH now can do from > port to socket, from socket to port, from port to port and from port to > socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (SSHD-864) Provide initial private key resource object used to read its data when loading a key
[
https://issues.apache.org/jira/browse/SSHD-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-864 started by Goldstein Lyor.
---
> Provide initial private key resource object used to read its data when
> loading a key
>
>
> Key: SSHD-864
> URL: https://issues.apache.org/jira/browse/SSHD-864
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> The current code propagates only a string representation of the "source" of a
> private key's data when it is being read. This source however, could be a
> {{Path}}, {{URL}}, {{URI}} or just a plain old path string. This information
> is "lost" when the code reaches supporting interfaces such as the
> {{FilePasswordProvider}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-865) Use lazy-loading for keys specified in the HostConfigEntry
Goldstein Lyor created SSHD-865:
---
Summary: Use lazy-loading for keys specified in the HostConfigEntry
Key: SSHD-865
URL: https://issues.apache.org/jira/browse/SSHD-865
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor
Following SSHD-860 key loading occurs lazily - thus encrypted keys password is
not requested until the key is actually needed. The exception to this rule are
keys specified as part of a {{HostConfigEntry}} specified in an [ssh_config
file|http://www.gsp.com/cgi-bin/man.cgi?topic=ssh_config].
h5. Implementation details
* Need to change {{SshClient#loadClientIdentities}} to return a
{{KeyPairProvider}} that is propagated all the way to
{{SshClient#onConnectOperationComplete}}.
* The code in {{SshClient#onConnectOperationComplete}} should check after
{{setupDefaultSessionIdentities}} if there is a non-empty {{KeyPairProvider}}
propagated and *aggregate* it with any already set such provider on the session
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (SSHD-862) Provide session context to FilePasswordProvider
[
https://issues.apache.org/jira/browse/SSHD-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-862:
Comment: was deleted
(was: The issue of propagating the session context (where available) to the
location where the {{FilePasswordProvider}} can use it is quite complex -
requires many API changes. Will consider doing it in the future should a need
arise (or more time available).)
> Provide session context to FilePasswordProvider
> ---
>
> Key: SSHD-862
> URL: https://issues.apache.org/jira/browse/SSHD-862
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> Provide the session context (if known) to the {{FilePasswordProvider}} -
> e.g., decide on different behavior based on the session attributes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-864) Provide initial private key resource object used to read its data when loading a key
Goldstein Lyor created SSHD-864:
---
Summary: Provide initial private key resource object used to read
its data when loading a key
Key: SSHD-864
URL: https://issues.apache.org/jira/browse/SSHD-864
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor
The current code propagates only a string representation of the "source" of a
private key's data when it is being read. This source however, could be a
{{Path}}, {{URL}}, {{URI}} or just a plain old path string. This information is
"lost" when the code reaches supporting interfaces such as the
{{FilePasswordProvider}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-863) Forwarding sockets
[
https://issues.apache.org/jira/browse/SSHD-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687488#comment-16687488
]
Goldstein Lyor commented on SSHD-863:
-
* What does it mean {quote}to forward from/to socket to/from port{quote} ? How
is it different than SSH tunneling ?
* Can you provide some links to documentations of standards (even if de-facto
ones) or code example how this is done by other libraries ?
> Forwarding sockets
> ---
>
> Key: SSHD-863
> URL: https://issues.apache.org/jira/browse/SSHD-863
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Björn Kautler
>Priority: Major
>
> Would be nice if MINA SSHD also supports forwarding sockets, not only ports.
> Currently you can only forward from port to port, but SSH now can do from
> port to socket, from socket to port, from port to port and from port to
> socket.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-862) Provide session context to FilePasswordProvider
[
https://issues.apache.org/jira/browse/SSHD-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-862 started by Goldstein Lyor.
---
> Provide session context to FilePasswordProvider
> ---
>
> Key: SSHD-862
> URL: https://issues.apache.org/jira/browse/SSHD-862
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> Provide the session context (if known) to the {{FilePasswordProvider}} -
> e.g., decide on different behavior based on the session attributes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-862) Provide session context to FilePasswordProvider
[
https://issues.apache.org/jira/browse/SSHD-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685304#comment-16685304
]
Goldstein Lyor commented on SSHD-862:
-
The issue of propagating the session context (where available) to the location
where the {{FilePasswordProvider}} can use it is quite complex - requires many
API changes. Will consider doing it in the future should a need arise (or more
time available).
> Provide session context to FilePasswordProvider
> ---
>
> Key: SSHD-862
> URL: https://issues.apache.org/jira/browse/SSHD-862
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> Provide the session context (if known) to the {{FilePasswordProvider}} -
> e.g., decide on different behavior based on the session attributes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work stopped] (SSHD-862) Provide session context to FilePasswordProvider
[
https://issues.apache.org/jira/browse/SSHD-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-862 stopped by Goldstein Lyor.
---
> Provide session context to FilePasswordProvider
> ---
>
> Key: SSHD-862
> URL: https://issues.apache.org/jira/browse/SSHD-862
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> Provide the session context (if known) to the {{FilePasswordProvider}} -
> e.g., decide on different behavior based on the session attributes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-862) Provide session context to FilePasswordProvider
Goldstein Lyor created SSHD-862:
---
Summary: Provide session context to FilePasswordProvider
Key: SSHD-862
URL: https://issues.apache.org/jira/browse/SSHD-862
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 2.1.0
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor
Provide the session context (if known) to the {{FilePasswordProvider}} - e.g.,
decide on different behavior based on the session attributes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-862) Provide session context to FilePasswordProvider
[
https://issues.apache.org/jira/browse/SSHD-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-862 started by Goldstein Lyor.
---
> Provide session context to FilePasswordProvider
> ---
>
> Key: SSHD-862
> URL: https://issues.apache.org/jira/browse/SSHD-862
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> Provide the session context (if known) to the {{FilePasswordProvider}} -
> e.g., decide on different behavior based on the session attributes.
--
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=16684259#comment-16684259
]
Goldstein Lyor commented on SSHD-860:
-
Great - the fix will be released as part of 2.2 (or higher) - I believe some
time in Q1 2019
> 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] [Resolved] (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:all-tabpanel
]
Goldstein Lyor resolved SSHD-860.
-
Resolution: Fixed
> 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=16684161#comment-16684161
]
Goldstein Lyor commented on SSHD-860:
-
Hi [~wolft], I have "un-fangled" the code you indicated and pushed the changes
to the _master_ branch. I would like to ask you to check that it indeed fixes
the issue (or at least the code you mentioned). Please do re-open the issue if
you find more "fangled" code...
> 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-861) Handling extra '@' present in username,password while creating SftpFileSystemProvider.createFileSystemURI
[
https://issues.apache.org/jira/browse/SSHD-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682947#comment-16682947
]
Goldstein Lyor commented on SSHD-861:
-
You will have to wait until it (or 2.2) is released - for now, it seems to be
some time in Q1 2019. Meanwhile, as a workaround, you can create a URI yourself
(using the code you recommended) and then call {{newFileSystem(uri,
Collections.emptyMap())}}
> Handling extra '@' present in username,password while creating
> SftpFileSystemProvider.createFileSystemURI
> -
>
> Key: SSHD-861
> URL: https://issues.apache.org/jira/browse/SSHD-861
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
> Environment: Dell Laptop,
> Intel i5-7200U 8gb RAM
> Windows 10 pro 64-bit
>Reporter: Mohammed Salman
>Assignee: Goldstein Lyor
>Priority: Minor
> Labels: easyfix
> Fix For: 2.1.1
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> From the documentation
> [mina-sshd|https://github.com/apache/mina-sshd/blob/master/README.md] ,
> {code:java}
> URI uri = SftpFileSystemProvider.createFileSystemURI(host, port, username,
> password);
> {code}
> if username or password parameters contain a character '@' , for example,
>
>
> {code:java}
> username = "J@ck";
> password = "d@Ripper";
> {code}
> then the resulting URI has hostname null ,because
> {code:java}
> SftpFileSystemProvider.createSystemURI{code}
> internally uses
> {code:java}
> URI.create(sb.ToString) {code}
> which does not handle this. To solve this, URI constructor should be used as
> suggested in the answer
> [here|https://stackoverflow.com/questions/26450910/java-sftp-apache-vfs2-password-with]
> .
>
> {code:java}
> String userInfo = userName + ":" + password; String path = remoteDirectory +
> filename; // Need a '/' between them? URI sftpUri = new URI("sftp", userInfo,
> remoteServerAddress, portNo, null, null, null);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-861) Handling extra '@' present in username,password while creating SftpFileSystemProvider.createFileSystemURI
[
https://issues.apache.org/jira/browse/SSHD-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-861.
-
Resolution: Fixed
Fix Version/s: 2.1.1
> Handling extra '@' present in username,password while creating
> SftpFileSystemProvider.createFileSystemURI
> -
>
> Key: SSHD-861
> URL: https://issues.apache.org/jira/browse/SSHD-861
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
> Environment: Dell Laptop,
> Intel i5-7200U 8gb RAM
> Windows 10 pro 64-bit
>Reporter: Mohammed Salman
>Assignee: Goldstein Lyor
>Priority: Minor
> Labels: easyfix
> Fix For: 2.1.1
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> From the documentation
> [mina-sshd|https://github.com/apache/mina-sshd/blob/master/README.md] ,
> {code:java}
> URI uri = SftpFileSystemProvider.createFileSystemURI(host, port, username,
> password);
> {code}
> if username or password parameters contain a character '@' , for example,
>
>
> {code:java}
> username = "J@ck";
> password = "d@Ripper";
> {code}
> then the resulting URI has hostname null ,because
> {code:java}
> SftpFileSystemProvider.createSystemURI{code}
> internally uses
> {code:java}
> URI.create(sb.ToString) {code}
> which does not handle this. To solve this, URI constructor should be used as
> suggested in the answer
> [here|https://stackoverflow.com/questions/26450910/java-sftp-apache-vfs2-password-with]
> .
>
> {code:java}
> String userInfo = userName + ":" + password; String path = remoteDirectory +
> filename; // Need a '/' between them? URI sftpUri = new URI("sftp", userInfo,
> remoteServerAddress, portNo, null, null, null);{code}
--
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=16682894#comment-16682894
]
Goldstein Lyor commented on SSHD-860:
-
Thanks for the reply - I will try and take care of the rest as well - starting
from
{{KeyIdentityProvider.resolveKeyIdentityProvider(session.getRegisteredIdentities(),
session.getKeyPairProvider())}}.
> 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] [Updated] (SSHD-861) Handling extra '@' present in username,password while creating SftpFileSystemProvider.createFileSystemURI
[
https://issues.apache.org/jira/browse/SSHD-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-861:
Priority: Minor (was: Critical)
> Handling extra '@' present in username,password while creating
> SftpFileSystemProvider.createFileSystemURI
> -
>
> Key: SSHD-861
> URL: https://issues.apache.org/jira/browse/SSHD-861
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
> Environment: Dell Laptop,
> Intel i5-7200U 8gb RAM
> Windows 10 pro 64-bit
>Reporter: Mohammed Salman
>Assignee: Goldstein Lyor
>Priority: Minor
> Labels: easyfix
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> From the documentation
> [mina-sshd|https://github.com/apache/mina-sshd/blob/master/README.md] ,
> {code:java}
> URI uri = SftpFileSystemProvider.createFileSystemURI(host, port, username,
> password);
> {code}
> if username or password parameters contain a character '@' , for example,
>
>
> {code:java}
> username = "J@ck";
> password = "d@Ripper";
> {code}
> then the resulting URI has hostname null ,because
> {code:java}
> SftpFileSystemProvider.createSystemURI{code}
> internally uses
> {code:java}
> URI.create(sb.ToString) {code}
> which does not handle this. To solve this, URI constructor should be used as
> suggested in the answer
> [here|https://stackoverflow.com/questions/26450910/java-sftp-apache-vfs2-password-with]
> .
>
> {code:java}
> String userInfo = userName + ":" + password; String path = remoteDirectory +
> filename; // Need a '/' between them? URI sftpUri = new URI("sftp", userInfo,
> remoteServerAddress, portNo, null, null, null);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SSHD-861) Handling extra '@' present in username,password while creating SftpFileSystemProvider.createFileSystemURI
[
https://issues.apache.org/jira/browse/SSHD-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor reassigned SSHD-861:
---
Assignee: Goldstein Lyor
> Handling extra '@' present in username,password while creating
> SftpFileSystemProvider.createFileSystemURI
> -
>
> Key: SSHD-861
> URL: https://issues.apache.org/jira/browse/SSHD-861
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
> Environment: Dell Laptop,
> Intel i5-7200U 8gb RAM
> Windows 10 pro 64-bit
>Reporter: Mohammed Salman
>Assignee: Goldstein Lyor
>Priority: Critical
> Labels: easyfix
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> From the documentation
> [mina-sshd|https://github.com/apache/mina-sshd/blob/master/README.md] ,
> {code:java}
> URI uri = SftpFileSystemProvider.createFileSystemURI(host, port, username,
> password);
> {code}
> if username or password parameters contain a character '@' , for example,
>
>
> {code:java}
> username = "J@ck";
> password = "d@Ripper";
> {code}
> then the resulting URI has hostname null ,because
> {code:java}
> SftpFileSystemProvider.createSystemURI{code}
> internally uses
> {code:java}
> URI.create(sb.ToString) {code}
> which does not handle this. To solve this, URI constructor should be used as
> suggested in the answer
> [here|https://stackoverflow.com/questions/26450910/java-sftp-apache-vfs2-password-with]
> .
>
> {code:java}
> String userInfo = userName + ":" + password; String path = remoteDirectory +
> filename; // Need a '/' between them? URI sftpUri = new URI("sftp", userInfo,
> remoteServerAddress, portNo, null, null, null);{code}
--
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=16680150#comment-16680150
]
Goldstein Lyor commented on SSHD-860:
-
Hi [~wolft]
{quote}
The first call to current.hasNext() in UserAuthPublicKeyIterator now still
loads the two keys of the first KeyPair iterator. Basically
LazyIterablesConcatenator.lazyConcatenateIterables(one, two) isn't lazy yet.
There's pre-loading going on for "one", and once "one" is exhausted and the
first hasNext() on "two" is called, there's pre-loading happening on "two".
{quote}
I am not sure I understand how this happens - after all, calling {{hasNext()}}
actually indicates that someone is going to call {{next()}} - so I don't see
how 2 instances are pre-loaded. I will review the code some more and try to
figure out if/how this happens. The only way I can see it happening is if
{{hasNext()}} is called twice (or more) without calling {{next()}}. But even in
this case, there is no "pre-loading" just a code error of having skipped a
key-pair.
{quote}
It is legal to call Iterator.next() without having called Iterator.hasNext()
before. So all those cases where the new code does throw new
IllegalStateException("'next()' called without a preceding 'hasNext()' query");
are wrong.
{quote}
I am not so sure - but I'll review the javadoc and see. If it is as you
describe I'll try and see if I can find the time to fix this.
{quote}
even with the new code, ends up using these newfangled spliterators,
{quote}
Can you indicate the code that uses these "newfangled spliterators" ? I'd like
to take a look at it and see if I can "un-fangle" it... :)
Thanks for the quick test and feedback. If you come up with some ides for a fix
please publish a PR - I'll be more than happy to review it and eventually merge
it into the code.
> 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] [Resolved] (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:all-tabpanel
]
Goldstein Lyor resolved SSHD-860.
-
Resolution: Fixed
Fix Version/s: 2.1.1
Hi [~wolft], I believe I have alleviated if not fixed the flow you described.
Can you get the latest code, compile it and see if indeed it solves the problem
? If not, please re-open the issue and describe the flow that seems to be
flawed.
> 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=16677974#comment-16677974
]
Goldstein Lyor commented on SSHD-860:
-
I have some time and some ideas so I am working on it - I don't think I am
going to have a full solution, but greatly alleviate the condition.
> 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
>
> {{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] [Work started] (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:all-tabpanel
]
Work on SSHD-860 started by Goldstein Lyor.
---
> 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
>
> {{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] [Assigned] (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:all-tabpanel
]
Goldstein Lyor reassigned SSHD-860:
---
Assignee: Goldstein Lyor
> 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
>
> {{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=16677170#comment-16677170
]
Goldstein Lyor commented on SSHD-860:
-
I do not necessarily agree with the severity but I can see why some may think
it is not minor (so upgraded it to major). Unfortunately, loading key pairs
lazily is a major overhaul of the code which we can afford at the moment given
the extremely limited R resources at our disposal. We have considered it in
the past but I am not sure when we might find the time for such an overhaul.
The good news is that we do accept code contributions (;)). If this is indeed
critical for you I recommend not to wait for us to get around to it, clone the
code and publish a PR. (Again, not because we don't want to, but because in the
foreseeable future we might not be able to invest the time it requires). If you
do go ahead with it, please note that not only this class needs an overhaul,
but perhaps all the other identity loaders and all their code
> 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
>Priority: Major
>
> {{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] [Updated] (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:all-tabpanel
]
Goldstein Lyor updated SSHD-860:
Priority: Major (was: Minor)
> 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
>Priority: Major
>
> {{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] [Updated] (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:all-tabpanel
]
Goldstein Lyor updated SSHD-860:
Priority: Minor (was: Critical)
> 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
>Priority: Minor
>
> {{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/commit/a71c62e66]
> 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-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677002#comment-16677002 ] Goldstein Lyor commented on SSHD-849: - Not a problem - time spent trying to improve the code is never wasted - even if it turns out that there was nothing to do. At least we have a double confirmation that the original code works. Closing the issue... > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.1.1 > > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > The code changes against master code are : > https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[
https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676595#comment-16676595
]
Goldstein Lyor commented on SSHD-849:
-
Here is how to make sure you are correctly rebased (assuming you have followed
my previous instructions)
* Edit your {{~/.gitconfig}} file and add
{noformat}
[pull]
rebase = true
{noformat}
** or {code:bash}git config --global pull.rebase true{code}
** or {code:bash}git config pull.rebase true{code} - if you don't want it in
all your projects
* {{git co master}} - assuming {{origin/master}} is the MINA SSHD github project
* {{git pull -tp}}
* {{git co master -b SSHD-849}}
* ...make only your changes...
* {{git push -u (if 1st time yous push this branch) -f (if you already have
pushed this branch) fork SSHD-849}}
* Go to your github fork and create a PR
I would like to emphasize again - please do not reformat the code and make sure
only your changes are in the commit.
> Possible race condition for local port forwarding channels
> --
>
> Key: SSHD-849
> URL: https://issues.apache.org/jira/browse/SSHD-849
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> Hi Lyor,
> We found another critical race condition sending data through local port
> forwarding channels that causes loosing data bytes sent by client to target
> server.
> As soon as possible I will open a pull request with our potential changes to
> fix this issue.
> I let you know when done because I would like to know your feedback.
> Hi Lyor,
> We made some code changes to your proposed solution based on
> ClientChannelPendingMessageQueue.
> You can find our commit at
> https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d
> Can you review our code and give us feedback ?
> If it satisfies you can you merge it in Apache SSHD master repository ?
> Our definitive working code is at
> https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6
> Cheers.
> Roberto
> Cheers
> Roberto
> The code changes against master code are :
> https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676486#comment-16676486 ] Goldstein Lyor commented on SSHD-849: - Hi Roberto, Sorry, but the PR is still not "clean" - it is (still) not rebased on latest _master_ version + contains re-formatting (which I asked not to do...). Lyor > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.1.1 > > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > The code changes against master code are : > https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[
https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675514#comment-16675514
]
Goldstein Lyor commented on SSHD-849:
-
Hi Roberto,
I appreciate the effort, but I cannot review the link you sent as it is (still)
* out-of-date with master
* contains re-formatting
* contains code that does not seem part of the patch
I propose you try the following procedure:
1. fork on github https://github.com/apache/mina-sshd/ to your account
2. {{git clone https://github.com/apache/mina-sshd.git}}
3. {{git remote add fork https://github.com/YOURUSER/mina-sshd.git}}
4. {{git checkout origin/master -b SSHD-849}}
5. Make your changes (reminder: do not re-format the files)
6. {{git commit -m ".commit message(s)..."}}
7. {{git push -u fork SSHD-849}}-- need to do it only the *first* time you
push Afterwards you can simply {{git push}}
8. Keep committing and pushing changes
Once you think the code is ready for review
* Go to *your* github fork of the code
* Select the SSHD-849 branch - you will see a large green button called
{{Compare & Pull request}}
* Click it
* Go over the PR and make sure it contains *only your changes* and nothing
else
* Submit it
Until we have a "clean" PR I cannot review the code with any degree of
certainty...
> Possible race condition for local port forwarding channels
> --
>
> Key: SSHD-849
> URL: https://issues.apache.org/jira/browse/SSHD-849
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> Hi Lyor,
> We found another critical race condition sending data through local port
> forwarding channels that causes loosing data bytes sent by client to target
> server.
> As soon as possible I will open a pull request with our potential changes to
> fix this issue.
> I let you know when done because I would like to know your feedback.
> Hi Lyor,
> We made some code changes to your proposed solution based on
> ClientChannelPendingMessageQueue.
> You can find our commit at
> https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d
> Can you review our code and give us feedback ?
> If it satisfies you can you merge it in Apache SSHD master repository ?
> Our definitive working code is at
> https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6
> Cheers.
> Roberto
> Cheers
> Roberto
> The code changes against master code are :
> https://github.com/robertodeandrea/myclone/commit/0602840140ce82f51446b0d5a05fb409e730adad
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-854) Massive object graph in NioSocketSession
[
https://issues.apache.org/jira/browse/SSHD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675116#comment-16675116
]
Goldstein Lyor commented on SSHD-854:
-
Hi guys,
If you do decide to patch something in MINA core, a patch to 2.0.x will be
appreciated since upgrading to 2.1 in SSHD is a bit of an issue right now (we
are using 2.0.19..). If you recommend 2.1 please let me know and we will make
an effort to upgrade to it.
> Massive object graph in NioSocketSession
>
>
> Key: SSHD-854
> URL: https://issues.apache.org/jira/browse/SSHD-854
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: jpalacios
>Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap ->
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object
> graph? Should MINA apply any defense mechanism to prevent this??
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675113#comment-16675113 ] Goldstein Lyor commented on SSHD-849: - Hi Roberto, The code you published is out-of-sync with the _master_ branch, which makes it very difficult to review. Please: * rebase your branch on latest _master_ version. * create/update a PR that has only the changes you recommend and nothing more * please refrain from re-formatting the code - if your IDE is set up to auto-format on save (as is mine) then please make sure the formatting is according to SSHD's look-and-feel. Otherwise, please disable the feature in your IDE. > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.1.1 > > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-854) Massive object graph in NioSocketSession
[
https://issues.apache.org/jira/browse/SSHD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671949#comment-16671949
]
Goldstein Lyor commented on SSHD-854:
-
{quote}
It's worth noting that the changes you've made to use session attributes
instead of a map to store/retrieve the cached value, would solve the problem
I'm describing. When do you think we can expect those changes to be released?
{quote}
I believe when we release 2.2 - some time in Q1 2019 (unless there is an urgent
need to release before that)
> Massive object graph in NioSocketSession
>
>
> Key: SSHD-854
> URL: https://issues.apache.org/jira/browse/SSHD-854
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: jpalacios
>Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap ->
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object
> graph? Should MINA apply any defense mechanism to prevent this??
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[
https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670307#comment-16670307
]
Goldstein Lyor commented on SSHD-849:
-
Please create a new PR based on the latest checked in version of {{mina-sshd}}.
At the same time, please do not re-format existing code as it makes the review
near impossible.
> Possible race condition for local port forwarding channels
> --
>
> Key: SSHD-849
> URL: https://issues.apache.org/jira/browse/SSHD-849
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> Hi Lyor,
> We found another critical race condition sending data through local port
> forwarding channels that causes loosing data bytes sent by client to target
> server.
> As soon as possible I will open a pull request with our potential changes to
> fix this issue.
> I let you know when done because I would like to know your feedback.
> Hi Lyor,
> We made some code changes to your proposed solution based on
> ClientChannelPendingMessageQueue.
> You can find our commit at
> https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d
> Can you review our code and give us feedback ?
> If it satisfies you can you merge it in Apache SSHD master repository ?
> Our definitive working code is at
> https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6
> Cheers.
> Roberto
> Cheers
> Roberto
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[
https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670042#comment-16670042
]
Goldstein Lyor commented on SSHD-849:
-
Hi Roberto,
Quick reminder:
* :) {quote}Your code changes are acceptable for us, you can merge it into
master repo.{quote}
* :( {quote}Your committed changes do not work fine for us{quote}
No harm done, but let's try and be more thorough next time in order to avoid
this back and forth - I rely on your reports since you are the only one that
can reproduce the problem (for now at least...)
> Possible race condition for local port forwarding channels
> --
>
> Key: SSHD-849
> URL: https://issues.apache.org/jira/browse/SSHD-849
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> Hi Lyor,
> We found another critical race condition sending data through local port
> forwarding channels that causes loosing data bytes sent by client to target
> server.
> As soon as possible I will open a pull request with our potential changes to
> fix this issue.
> I let you know when done because I would like to know your feedback.
> Hi Lyor,
> We made some code changes to your proposed solution based on
> ClientChannelPendingMessageQueue.
> You can find our commit at
> https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d
> Can you review our code and give us feedback ?
> If it satisfies you can you merge it in Apache SSHD master repository ?
> Our definitive working code is at
> https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6
> Cheers.
> Roberto
> Cheers
> Roberto
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work stopped] (SSHD-757) Add support for PGP authorized keys usage
[
https://issues.apache.org/jira/browse/SSHD-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-757 stopped by Goldstein Lyor.
---
> Add support for PGP authorized keys usage
> -
>
> Key: SSHD-757
> URL: https://issues.apache.org/jira/browse/SSHD-757
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Labels: authorization, key, key-management, pgp, ssh
>
> [SSH 2.3|http://www.onlamp.com/pub/a/onlamp/excerpt/ssh_8/] seems to have
> added the capability to use PGP keys as authorized ones:
> {quote}
> SSH2 Version 2.0.13 introduced support for PGP authentication. Your
> authorization file may also include {{PgpPublicKeyFile, PgpKeyName, PgpKey
> Fingerprint}}, and {{PgpKeyId}} lines. A Command line may follow them, just
> as it may follow Key:
> {noformat}
> # SSH2 only
> PgpKeyName my-key
> Command "/bin/echo PGP authentication was detected"
> {noformat}
> {quote}
> Some examples of how to use _Bouncycastle_ to facilitate this:
> * [Sample code|https://github.com/damico/OpenPgp-BounceCastle-Example]
> * [jpgpj Library wrapper|https://github.com/justinludwig/jpgpj]
> _Python_ [converter
> pgp->ssh|https://raw.githubusercontent.com/fincham/ssh-to-pgp/master/ssh-to-pgp]
> _openssh-gpg_ [configuration|http://www.red-bean.com/~nemo/openssh-gpg/]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-859) Provide client session connection context that is propagated to the SSH session
[
https://issues.apache.org/jira/browse/SSHD-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-859.
-
Resolution: Fixed
Fix Version/s: 2.1.1
> Provide client session connection context that is propagated to the SSH
> session
> ---
>
> Key: SSHD-859
> URL: https://issues.apache.org/jira/browse/SSHD-859
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> When creating a client session the caller cannot provide any kind of
> "context" that will be propagated to the session, and thru it to the various
> listeners/verifiers/authenticators. Such a context may be useful in the case
> where an {{SshClient}} instance is used to connect various hosts or the same
> host for various purposes. In such a case, it is conceivable that the user
> may wish the various registered "callbacks" to behave differently according
> to some connection context provided when the SSH session was established. The
> current code allows such decisions based on the peer host address/port, but
> this information might not be enough for the required decision functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SSHD-859) Provide client session connection context that is propagated to the SSH session
[
https://issues.apache.org/jira/browse/SSHD-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-859:
Description: When creating a client session the caller cannot provide any
kind of "context" that will be propagated to the session, and thru it to the
various listeners/verifiers/authenticators. Such a context may be useful in the
case where an {{SshClient}} instance is used to connect various hosts or the
same host for various purposes. In such a case, it is conceivable that the user
may wish the various registered "callbacks" to behave differently according to
some connection context provided when the SSH session was established. The
current code allows such decisions based on the peer host address/port, but
this information might not be enough for the required decision functionality.
(was: When creating a client session the caller cannot provide any kind of
"context" that will be propagated to the session, and thru it to the various
listeners/verifiers/authenticators. Such a context may be useful in the case
where an {{SshClient}} instance is used to connect various hosts or the same
host for various purposes. In such a case, it is conceivable that the user may
wish the various registered to behave differently according to some connection
context provided when the SSH session was established. The current code allows
such decisions based on the peer host address/port, but this information might
not be enough for the required decision functionality.)
> Provide client session connection context that is propagated to the SSH
> session
> ---
>
> Key: SSHD-859
> URL: https://issues.apache.org/jira/browse/SSHD-859
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> When creating a client session the caller cannot provide any kind of
> "context" that will be propagated to the session, and thru it to the various
> listeners/verifiers/authenticators. Such a context may be useful in the case
> where an {{SshClient}} instance is used to connect various hosts or the same
> host for various purposes. In such a case, it is conceivable that the user
> may wish the various registered "callbacks" to behave differently according
> to some connection context provided when the SSH session was established. The
> current code allows such decisions based on the peer host address/port, but
> this information might not be enough for the required decision functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goldstein Lyor resolved SSHD-849. - Resolution: Fixed Assignee: Goldstein Lyor Fix Version/s: 2.1.1 See https://github.com/apache/mina-sshd/commit/5156285473fe7b42577e747c9c8f458f98fa73ca > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.1.1 > > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16668473#comment-16668473 ] Goldstein Lyor commented on SSHD-849: - As soon as you tell me that these changes are acceptable to you... :) > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Priority: Major > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Our definitive working code is at > https://github.com/robertodeandrea/mina-sshd/commit/c381e522dc254387009d82612dc15f0c584dece6 > Cheers. > Roberto > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SSHD-859) Provide client session connection context that is propagated to the SSH session
Goldstein Lyor created SSHD-859:
---
Summary: Provide client session connection context that is
propagated to the SSH session
Key: SSHD-859
URL: https://issues.apache.org/jira/browse/SSHD-859
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor
When creating a client session the caller cannot provide any kind of "context"
that will be propagated to the session, and thru it to the various
listeners/verifiers/authenticators. Such a context may be useful in the case
where an {{SshClient}} instance is used to connect various hosts or the same
host for various purposes. In such a case, it is conceivable that the user may
wish the various registered to behave differently according to some connection
context provided when the SSH session was established. The current code allows
such decisions based on the peer host address/port, but this information might
not be enough for the required decision functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-859) Provide client session connection context that is propagated to the SSH session
[
https://issues.apache.org/jira/browse/SSHD-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-859 started by Goldstein Lyor.
---
> Provide client session connection context that is propagated to the SSH
> session
> ---
>
> Key: SSHD-859
> URL: https://issues.apache.org/jira/browse/SSHD-859
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> When creating a client session the caller cannot provide any kind of
> "context" that will be propagated to the session, and thru it to the various
> listeners/verifiers/authenticators. Such a context may be useful in the case
> where an {{SshClient}} instance is used to connect various hosts or the same
> host for various purposes. In such a case, it is conceivable that the user
> may wish the various registered to behave differently according to some
> connection context provided when the SSH session was established. The current
> code allows such decisions based on the peer host address/port, but this
> information might not be enough for the required decision functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-854) Massive object graph in NioSocketSession
[
https://issues.apache.org/jira/browse/SSHD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16668136#comment-16668136
]
Goldstein Lyor commented on SSHD-854:
-
Hi Juan,
I don't really have a theory as to how this can happen in version 1.7.0.
Perhaps there is some code flow that causes one (or more) of the session
listener methods not to be called, thus causing the huge buildup. As far as 2.x
changes that specifically resolve it, again, I apologize but I cannot recall
anything specific to this issue off-hand. I do know there have been several
changes in the way we handle connection closing - the code plugged some "gaps"
that were found. These gaps were not directly related to the issue at hand, but
they may have indirectly also solved this issue. In any case, even if you don't
want or cannot upgrade to 2.x (and there are no guarantees that it would fix
this issue), the fix I introduced in the ongoing code as a result for this
issue can easily be duplicated and used in 1.7.0 (though we cannot release such
a patch, it should be relatively easy to introduce it as a local workaround by
you).
> Massive object graph in NioSocketSession
>
>
> Key: SSHD-854
> URL: https://issues.apache.org/jira/browse/SSHD-854
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: jpalacios
>Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap ->
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object
> graph? Should MINA apply any defense mechanism to prevent this??
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-858) Allow users to handle incoming un-implemented session messages via ReservedSessionMessagesHandler
[
https://issues.apache.org/jira/browse/SSHD-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-858.
-
Resolution: Fixed
Fix Version/s: 2.1.1
> Allow users to handle incoming un-implemented session messages via
> ReservedSessionMessagesHandler
> -
>
> Key: SSHD-858
> URL: https://issues.apache.org/jira/browse/SSHD-858
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Labels: handler, ssh, sshd
> Fix For: 2.1.1
>
>
> The current code only informs users about incoming {{SSH_MSG_UNIMPLEMENTED}}
> messages, but does not provide a hook to handle unknown commands - it simply
> sends and {{SSH_MSG_UNIMPLEMENTED}} message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-857) Add session disconnect event signalling to SessionListener
[ https://issues.apache.org/jira/browse/SSHD-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goldstein Lyor resolved SSHD-857. - Resolution: Fixed Fix Version/s: 2.1.1 > Add session disconnect event signalling to SessionListener > -- > > Key: SSHD-857 > URL: https://issues.apache.org/jira/browse/SSHD-857 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.1 >Reporter: Goldstein Lyor >Assignee: Goldstein Lyor >Priority: Minor > Labels: EventListener, session > Fix For: 2.1.1 > > > Provide more information about important events in a session's lifecycle -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-851) Last chunk of data lost into local port forwarding channel
[
https://issues.apache.org/jira/browse/SSHD-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16667576#comment-16667576
]
Goldstein Lyor commented on SSHD-851:
-
{quote}
can you suggest another way to solve this issue ?
{quote}
Sorry, not off-hand. May I suggest you try and post this on the
{{dev@mina.apache.org}} mailing list - perhaps someone can come up with an idea
(or maybe convince me that it is OK to forego the asynchronous close...)
> Last chunk of data lost into local port forwarding channel
> --
>
> Key: SSHD-851
> URL: https://issues.apache.org/jira/browse/SSHD-851
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Roberto Deandrea
>Priority: Major
> Attachments: sshd.agent.trace
>
>
> Hi Lyor,
> I found another problem transferring data through a local port forwarding
> channel.
> It seems that the problem is located into Apache SSHD server code according
> to me.
> All the data are transferred from the originating client to the Apache SSH
> client and then go to the SSHD server through a local port forwarding channel.
> When the client stops sending data, and the channel is being closed, the
> SSHD server fail to send the last chunk of data to the target destination.
> In the attached trace file the problem is isolated as the following:
> *local port forwarding channel : [id=732 recipient=732]*
> *Nio2Session[local=/0:0:0:0:0:0:0:0:50047, remote=/192.168.2.107:62284
> session against target server*
> Looking through the traces I see that when the local port forwarding channel
> is closed, the Nio2Session against the target server is closed gracefully,
> but instead of waiting to complete pending socket writes to the target server
> the Nio2Session is then closed immediately causing write failures.
> In the traces I see:
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-1]
> [AbstractCloseable.close] close(Nio2Session[local=/0:0:0:0:0:0:0:0:50047,
> remote=/192.168.2.107:62284]) Closing gracefully
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2]
> [AbstractCloseable.close]
> close(org.apache.sshd.common.io.nio2.Nio2Connector@77fcff14) Closing
> immediately^M
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2]
> [AbstractCloseable.close] close(Nio2Session[local=/0:0:0:0:0:0:0:0:50047,
> remote=/192.168.2.107:62284]) Closing immediately
> After that I see:
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2]
> [Nio2Session.doCloseImmediately]
> doCloseImmediately(Nio2Session[local=/0:0:0:0:0:0:0:0:50047,
> remote=/192.168.2.107:62284]) signal write abort for
> future=Nio2DefaultIoWriteFuture[id=/192.168.2.107:62284][value=null]
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2]
> [TcpipServerChannel.handleWriteDataFailure]
> handleWriteDataFailure(TcpipServerChannel[id=732,
> recipient=732]-ServerSessionImpl[aixdmzdriverssh@/192.168.10.34:55335])[SSH_MSG_CHANNEL_DATA]
> failed (WriteAbortedException) to write len=16384: Write request aborted due
> to immediate session close
>
> These errors are repeated multiple times.
> The sum of bytes not written are equal to the chunk of data missing ad the
> target server.
> Can you troubleshoot this problem?
> Let me know if you need more info.
>
> Cheers
> Roberto
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-858) Allow users to handle incoming un-implemented session messages via ReservedSessionMessagesHandler
[
https://issues.apache.org/jira/browse/SSHD-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-858 started by Goldstein Lyor.
---
> Allow users to handle incoming un-implemented session messages via
> ReservedSessionMessagesHandler
> -
>
> Key: SSHD-858
> URL: https://issues.apache.org/jira/browse/SSHD-858
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Labels: handler, ssh, sshd
>
> The current code only informs users about incoming {{SSH_MSG_UNIMPLEMENTED}}
> messages, but does not provide a hook to handle unknown commands - it simply
> sends and {{SSH_MSG_UNIMPLEMENTED}} message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-858) Allow users to handle incoming un-implemented session messages via ReservedSessionMessagesHandler
Goldstein Lyor created SSHD-858:
---
Summary: Allow users to handle incoming un-implemented session
messages via ReservedSessionMessagesHandler
Key: SSHD-858
URL: https://issues.apache.org/jira/browse/SSHD-858
Project: MINA SSHD
Issue Type: Improvement
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor
The current code only informs users about incoming {{SSH_MSG_UNIMPLEMENTED}}
messages, but does not provide a hook to handle unknown commands - it simply
sends and {{SSH_MSG_UNIMPLEMENTED}} message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-857) Add session disconnect event signalling to SessionListener
Goldstein Lyor created SSHD-857: --- Summary: Add session disconnect event signalling to SessionListener Key: SSHD-857 URL: https://issues.apache.org/jira/browse/SSHD-857 Project: MINA SSHD Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Goldstein Lyor Assignee: Goldstein Lyor Provide more information about important events in a session's lifecycle -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (SSHD-857) Add session disconnect event signalling to SessionListener
[ https://issues.apache.org/jira/browse/SSHD-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-857 started by Goldstein Lyor. --- > Add session disconnect event signalling to SessionListener > -- > > Key: SSHD-857 > URL: https://issues.apache.org/jira/browse/SSHD-857 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.1 >Reporter: Goldstein Lyor >Assignee: Goldstein Lyor >Priority: Minor > Labels: EventListener, session > > Provide more information about important events in a session's lifecycle -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-854) Massive object graph in NioSocketSession
[
https://issues.apache.org/jira/browse/SSHD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1316#comment-1316
]
Goldstein Lyor commented on SSHD-854:
-
In this context, I re-wrote {{CachingPublicKeyAuthenticator}} to [use a
session
attribute|https://github.com/apache/mina-sshd/commit/5c7cc71377ef8d720683957548e8f0c66756d5c2]
instead of a listener-updated map. This will make sure that when the session
is GC'ed, the attributes will be cleaned-up regardless of whether
{{sessionClosed}} was called or not (due to some bug/issue).
> Massive object graph in NioSocketSession
>
>
> Key: SSHD-854
> URL: https://issues.apache.org/jira/browse/SSHD-854
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: jpalacios
>Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap ->
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object
> graph? Should MINA apply any defense mechanism to prevent this??
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-856) Use some kind of continuous integration mechanism to validate master branch
Goldstein Lyor created SSHD-856:
---
Summary: Use some kind of continuous integration mechanism to
validate master branch
Key: SSHD-856
URL: https://issues.apache.org/jira/browse/SSHD-856
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Goldstein Lyor
We currently rely on manual compilation before pushing to master branch. We
should have some continuous integration mechanism that makes sure latest pushed
version passes all its tests.
h5. Requirements
* Java 8 (or whatever the project's minimum version requirement is)
* _Windows_ *and* _Linux_ environments tests
* Overcome intermittent failures (SSHD-213, SSHD-822)
* Apply also {{findbugs}}, {{owasp}} and some coverage tool as well
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-854) Massive object graph in NioSocketSession
[
https://issues.apache.org/jira/browse/SSHD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1294#comment-1294
]
Goldstein Lyor commented on SSHD-854:
-
Hi [~jpalacios], after reviewing the issue's comments more thoroughly, I
observed that the SSHD version in use is quite old (1.7.0). Since then, there
have been many significant changes (hopefully improvements...) - including to
the session management cycle. I would like to ask you to try to reproduce the
issue with the latest released version (2.1.0).
Please see also the [section dealing with IOServiceFactory
selection|https://github.com/apache/mina-sshd#selecting-an-ioservicefactoryfactory]
and note that by default, we started using the *built-in* NIO2 factory. If you
cannot reproduce it with NIO2, see if you can reproduce it with MINA - that may
provide us a better understanding of where there might be an issue (or not...)
> Massive object graph in NioSocketSession
>
>
> Key: SSHD-854
> URL: https://issues.apache.org/jira/browse/SSHD-854
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: jpalacios
>Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap ->
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object
> graph? Should MINA apply any defense mechanism to prevent this??
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-854) Massive object graph in NioSocketSession
[
https://issues.apache.org/jira/browse/SSHD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1290#comment-1290
]
Goldstein Lyor commented on SSHD-854:
-
{quote}
Clearly, the sessionClosed() method from the CachingPublicKeyAuthenticator
class is not being called,
{quote}
As far as I can tell from looking at the code, {{sessionClosed}} is always
called since it is part of the {{preClose}} sequence - which is part of any
{{Closeable#close}}.
That being said, I am not able to see the benefits of this class - why would we
want to cache the authentication result per-session ? After all, once the
session is authenticated, the verifier is not consulted again (for the same
session).
> Massive object graph in NioSocketSession
>
>
> Key: SSHD-854
> URL: https://issues.apache.org/jira/browse/SSHD-854
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: jpalacios
>Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap ->
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object
> graph? Should MINA apply any defense mechanism to prevent this??
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-854) Massive object graph in NioSocketSession
[
https://issues.apache.org/jira/browse/SSHD-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665213#comment-16665213
]
Goldstein Lyor commented on SSHD-854:
-
Will try to look at it when I get the chance.
> Massive object graph in NioSocketSession
>
>
> Key: SSHD-854
> URL: https://issues.apache.org/jira/browse/SSHD-854
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: jpalacios
>Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap ->
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object
> graph? Should MINA apply any defense mechanism to prevent this??
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-853) Support for Diffie-Hellman 3072 for key exchange
[
https://issues.apache.org/jira/browse/SSHD-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661696#comment-16661696
]
Goldstein Lyor commented on SSHD-853:
-
How is this an issue ? see
{{org.apache.sshd.common.util.security.SecurityUtils.getMaxDHGroupExchangeKeySize()}}.
We auto-detect the maximum supported for the JCE (or _BouncyCastle_).
> Support for Diffie-Hellman 3072 for key exchange
>
>
> Key: SSHD-853
> URL: https://issues.apache.org/jira/browse/SSHD-853
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: chris ullock
>Priority: Major
> Attachments: CNSA-Suite-and-Quantum-Computing-FAQ.pdf
>
>
> as per NSA 2016 guidelines, recommendation is to support Diffie-Hellman 3072
> for key exchange:
> [https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660536#comment-16660536 ] Goldstein Lyor commented on SSHD-849: - Hi [~roberto.deandrea] I have made the changes based on your idea - pushed it into the same branch (https://github.com/lgoldstein/mina-sshd/tree/SSHD-849) + PR. Can you review + test it an see ? > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Priority: Major > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Cheers. > Roberto > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660470#comment-16660470 ] Goldstein Lyor edited comment on SSHD-849 at 10/23/18 11:38 AM: I take it back - after reviewing the code (see my remarks) there are still problems - mainly the fact the `completedFuture` may remain in undefined state if exceptions occur. I like your idea though and am working on an update of my initial code based on yours. was (Author: lgoldstein): I take it back - after reviewing the code (see my remarks) there are still problems - mainly the fact the `completedFuture` may remain in undefined state if exceptions occur. > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Priority: Major > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Cheers. > Roberto > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660470#comment-16660470 ] Goldstein Lyor commented on SSHD-849: - I take it back - after reviewing the code (see my remarks) there are still problems - mainly the fact the `completedFuture` may remain in undefined state if exceptions occur. > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Priority: Major > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Cheers. > Roberto > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-851) Last chunk of data lost into local port forwarding channel
[ https://issues.apache.org/jira/browse/SSHD-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660469#comment-16660469 ] Goldstein Lyor commented on SSHD-851: - Hi [~roberto.deandrea] - sorry, don't think the patch is correct - see my remarks. > Last chunk of data lost into local port forwarding channel > -- > > Key: SSHD-851 > URL: https://issues.apache.org/jira/browse/SSHD-851 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Priority: Major > Attachments: sshd.agent.trace > > > Hi Lyor, > I found another problem transferring data through a local port forwarding > channel. > It seems that the problem is located into Apache SSHD server code according > to me. > All the data are transferred from the originating client to the Apache SSH > client and then go to the SSHD server through a local port forwarding channel. > When the client stops sending data, and the channel is being closed, the > SSHD server fail to send the last chunk of data to the target destination. > In the attached trace file the problem is isolated as the following: > *local port forwarding channel : [id=732 recipient=732]* > *Nio2Session[local=/0:0:0:0:0:0:0:0:50047, remote=/192.168.2.107:62284 > session against target server* > Looking through the traces I see that when the local port forwarding channel > is closed, the Nio2Session against the target server is closed gracefully, > but instead of waiting to complete pending socket writes to the target server > the Nio2Session is then closed immediately causing write failures. > In the traces I see: > 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-1] > [AbstractCloseable.close] close(Nio2Session[local=/0:0:0:0:0:0:0:0:50047, > remote=/192.168.2.107:62284]) Closing gracefully > 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2] > [AbstractCloseable.close] > close(org.apache.sshd.common.io.nio2.Nio2Connector@77fcff14) Closing > immediately^M > 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2] > [AbstractCloseable.close] close(Nio2Session[local=/0:0:0:0:0:0:0:0:50047, > remote=/192.168.2.107:62284]) Closing immediately > After that I see: > 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2] > [Nio2Session.doCloseImmediately] > doCloseImmediately(Nio2Session[local=/0:0:0:0:0:0:0:0:50047, > remote=/192.168.2.107:62284]) signal write abort for > future=Nio2DefaultIoWriteFuture[id=/192.168.2.107:62284][value=null] > 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2] > [TcpipServerChannel.handleWriteDataFailure] > handleWriteDataFailure(TcpipServerChannel[id=732, > recipient=732]-ServerSessionImpl[aixdmzdriverssh@/192.168.10.34:55335])[SSH_MSG_CHANNEL_DATA] > failed (WriteAbortedException) to write len=16384: Write request aborted due > to immediate session close > > These errors are repeated multiple times. > The sum of bytes not written are equal to the chunk of data missing ad the > target server. > Can you troubleshoot this problem? > Let me know if you need more info. > > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660457#comment-16660457 ] Goldstein Lyor commented on SSHD-849: - Hi [~roberto.deandrea], seems in order, but I do have some remarks regarding style - so please create a PR *after* making sure the code compiles without any +Checkstyle+ or +PMD+ issues (as well as passing all unit tests). I will add the style remarks on the PR. > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Priority: Major > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > Hi Lyor, > We made some code changes to your proposed solution based on > ClientChannelPendingMessageQueue. > You can find our commit at > https://github.com/robertodeandrea/mina-sshd/commit/4523138ee2b4efa483bc956e8769eafb13eff05d > Can you review our code and give us feedback ? > If it satisfies you can you merge it in Apache SSHD master repository ? > Cheers. > Roberto > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-850.
-
Resolution: Fixed
Fix Version/s: 2.1.1
See {{FilePasswordProvider#handleDecodeAttemptResult}}
> Add capability to retry a failed private key decryption when client is
> decrypting private key file(s)
> -
>
> Key: SSHD-850
> URL: https://issues.apache.org/jira/browse/SSHD-850
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.0.0, 2.1.0
>Reporter: Thomas Wolf
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> In openssh, the ssh config entry NumberOfPasswordPrompts controls the number
> of times the ssh client keeps asking for a password if the one entered was
> invalid in two cases:
> # keyboard-interactive authentication, and
> # asking for passwords for encrypted private keys in identity files in
> pubkey authentication (see [openssh sources;
> sshconnect2.c|https://github.com/openssh/openssh-portable/blob/1a4a9cf/sshconnect2.c#L1380]).
> sshd-core only has support for (1) through setting the property
> {{ClientAuthenticationManager.PASSWORD_PROMPTS}} in the session's properties.
> There doesn't seem to be any support for FilePasswordProvider to make it
> respect this value.
> {{AbstractPEMResourceKeyPairParser.extractkeyPairs()}} and also
> {{BouncyCastleKeyPairResourceParser.loadKeyPair()}} call
> {{FilePasswordProvider.getPassword()}} exactly once.
> So how can I write a ssh client using sshd that asks the user
> NumberOfPasswordPrompts times? Either I'm missing something, or there is some
> support for this missing in sshd.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-852) Verification fails for hashed known host entry on non standard port generated by OpenSSH client
[
https://issues.apache.org/jira/browse/SSHD-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-852.
-
Resolution: Fixed
Make sure non-standard port and hash are correctly written to known-hosts file
> Verification fails for hashed known host entry on non standard port generated
> by OpenSSH client
> ---
>
> Key: SSHD-852
> URL: https://issues.apache.org/jira/browse/SSHD-852
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Linux Mint 19
>Reporter: Stefan Verhoeven
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
> Attachments: ConnectToNonDefaultPortTest.java
>
>
> The Apache SshClient is unable to verify a known host entry that was made by
> the OpenSSH client when the entry is on a port other than 22.
>
> I get the following exception
> {code:java}
> org.apache.sshd.common.SshException: Server key did not validate
> at
> org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:440)
> ...{code}
>
> The OpenSSH client will create a hash for `[host]:port` while Apache
> SshClient will check hashed entries for `host` (see
> https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130[).|https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130.]
> This difference will cause the correct known host entry to be marked as not
> a match which in turn causes the exception.
>
> The error can be reproduced by setting up the a SSH server
> {code:java}
> rm ~/.ssh/known_hosts
> docker run -d -p :22 nlesc/xenon-ssh
> # Prime known hosts with hash entry, password=javagat
> ssh xenon@localhost -p 10022 hostname
> {code}
> and then running the attached test.
>
> I created a fix and tests at
> https://github.com/apache/mina-sshd/compare/master...NLeSC:hashed-known-host-port
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-852) Verification fails for hashed known host entry on non standard port generated by OpenSSH client
[
https://issues.apache.org/jira/browse/SSHD-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656931#comment-16656931
]
Goldstein Lyor commented on SSHD-852:
-
{quote}
When the Apache ssh client adds a hashed known entry
(https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-core/src/main/java/org/apache/sshd/client/keyverifier/KnownHostsServerKeyVerifier.java;h=c4cb849b6007b905919417fa0717e0f42d7bc463;hb=HEAD#l702)
it only uses the hostname. This will make Apache ssh client not trust the hash
it added itself. So this should be changed to also use `[host]:port` format
when port!=22.
{quote}
Thanks for the observation - will fix
> Verification fails for hashed known host entry on non standard port generated
> by OpenSSH client
> ---
>
> Key: SSHD-852
> URL: https://issues.apache.org/jira/browse/SSHD-852
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Linux Mint 19
>Reporter: Stefan Verhoeven
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
> Attachments: ConnectToNonDefaultPortTest.java
>
>
> The Apache SshClient is unable to verify a known host entry that was made by
> the OpenSSH client when the entry is on a port other than 22.
>
> I get the following exception
> {code:java}
> org.apache.sshd.common.SshException: Server key did not validate
> at
> org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:440)
> ...{code}
>
> The OpenSSH client will create a hash for `[host]:port` while Apache
> SshClient will check hashed entries for `host` (see
> https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130[).|https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130.]
> This difference will cause the correct known host entry to be marked as not
> a match which in turn causes the exception.
>
> The error can be reproduced by setting up the a SSH server
> {code:java}
> rm ~/.ssh/known_hosts
> docker run -d -p :22 nlesc/xenon-ssh
> # Prime known hosts with hash entry, password=javagat
> ssh xenon@localhost -p 10022 hostname
> {code}
> and then running the attached test.
>
> I created a fix and tests at
> https://github.com/apache/mina-sshd/compare/master...NLeSC:hashed-known-host-port
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (SSHD-852) Verification fails for hashed known host entry on non standard port generated by OpenSSH client
[
https://issues.apache.org/jira/browse/SSHD-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor reopened SSHD-852:
-
> Verification fails for hashed known host entry on non standard port generated
> by OpenSSH client
> ---
>
> Key: SSHD-852
> URL: https://issues.apache.org/jira/browse/SSHD-852
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Linux Mint 19
>Reporter: Stefan Verhoeven
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
> Attachments: ConnectToNonDefaultPortTest.java
>
>
> The Apache SshClient is unable to verify a known host entry that was made by
> the OpenSSH client when the entry is on a port other than 22.
>
> I get the following exception
> {code:java}
> org.apache.sshd.common.SshException: Server key did not validate
> at
> org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:440)
> ...{code}
>
> The OpenSSH client will create a hash for `[host]:port` while Apache
> SshClient will check hashed entries for `host` (see
> https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130[).|https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130.]
> This difference will cause the correct known host entry to be marked as not
> a match which in turn causes the exception.
>
> The error can be reproduced by setting up the a SSH server
> {code:java}
> rm ~/.ssh/known_hosts
> docker run -d -p :22 nlesc/xenon-ssh
> # Prime known hosts with hash entry, password=javagat
> ssh xenon@localhost -p 10022 hostname
> {code}
> and then running the attached test.
>
> I created a fix and tests at
> https://github.com/apache/mina-sshd/compare/master...NLeSC:hashed-known-host-port
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656269#comment-16656269 ] Goldstein Lyor commented on SSHD-849: - The code can also be checked out and tested from https://github.com/lgoldstein/mina-sshd/tree/SSHD-849. > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Priority: Major > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor reassigned SSHD-850:
---
Assignee: Goldstein Lyor
> Add capability to retry a failed private key decryption when client is
> decrypting private key file(s)
> -
>
> Key: SSHD-850
> URL: https://issues.apache.org/jira/browse/SSHD-850
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.0.0, 2.1.0
>Reporter: Thomas Wolf
>Assignee: Goldstein Lyor
>Priority: Minor
>
> In openssh, the ssh config entry NumberOfPasswordPrompts controls the number
> of times the ssh client keeps asking for a password if the one entered was
> invalid in two cases:
> # keyboard-interactive authentication, and
> # asking for passwords for encrypted private keys in identity files in
> pubkey authentication (see [openssh sources;
> sshconnect2.c|https://github.com/openssh/openssh-portable/blob/1a4a9cf/sshconnect2.c#L1380]).
> sshd-core only has support for (1) through setting the property
> {{ClientAuthenticationManager.PASSWORD_PROMPTS}} in the session's properties.
> There doesn't seem to be any support for FilePasswordProvider to make it
> respect this value.
> {{AbstractPEMResourceKeyPairParser.extractkeyPairs()}} and also
> {{BouncyCastleKeyPairResourceParser.loadKeyPair()}} call
> {{FilePasswordProvider.getPassword()}} exactly once.
> So how can I write a ssh client using sshd that asks the user
> NumberOfPasswordPrompts times? Either I'm missing something, or there is some
> support for this missing in sshd.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-850 started by Goldstein Lyor.
---
> Add capability to retry a failed private key decryption when client is
> decrypting private key file(s)
> -
>
> Key: SSHD-850
> URL: https://issues.apache.org/jira/browse/SSHD-850
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.0.0, 2.1.0
>Reporter: Thomas Wolf
>Assignee: Goldstein Lyor
>Priority: Minor
>
> In openssh, the ssh config entry NumberOfPasswordPrompts controls the number
> of times the ssh client keeps asking for a password if the one entered was
> invalid in two cases:
> # keyboard-interactive authentication, and
> # asking for passwords for encrypted private keys in identity files in
> pubkey authentication (see [openssh sources;
> sshconnect2.c|https://github.com/openssh/openssh-portable/blob/1a4a9cf/sshconnect2.c#L1380]).
> sshd-core only has support for (1) through setting the property
> {{ClientAuthenticationManager.PASSWORD_PROMPTS}} in the session's properties.
> There doesn't seem to be any support for FilePasswordProvider to make it
> respect this value.
> {{AbstractPEMResourceKeyPairParser.extractkeyPairs()}} and also
> {{BouncyCastleKeyPairResourceParser.loadKeyPair()}} call
> {{FilePasswordProvider.getPassword()}} exactly once.
> So how can I write a ssh client using sshd that asks the user
> NumberOfPasswordPrompts times? Either I'm missing something, or there is some
> support for this missing in sshd.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-849) Possible race condition for local port forwarding channels
[ https://issues.apache.org/jira/browse/SSHD-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656162#comment-16656162 ] Goldstein Lyor commented on SSHD-849: - Hi, please review the solution I posted as a PR (https://github.com/apache/mina-sshd/pull/72) - if it looks reasonable, it would help if you could run some sanity as well as stress tests to see not only if it works, but what impact (if any) it has on sustained throughput tunneling. > Possible race condition for local port forwarding channels > -- > > Key: SSHD-849 > URL: https://issues.apache.org/jira/browse/SSHD-849 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.1 >Reporter: Roberto Deandrea >Priority: Major > > Hi Lyor, > We found another critical race condition sending data through local port > forwarding channels that causes loosing data bytes sent by client to target > server. > As soon as possible I will open a pull request with our potential changes to > fix this issue. > I let you know when done because I would like to know your feedback. > > Cheers > Roberto > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656138#comment-16656138
]
Goldstein Lyor commented on SSHD-850:
-
{quote}
But it remains a big ugly hack in my opinion. Doing it that level requires
guessing things (such as if I get an IOException before I asked for a
passsword, it's some other problem, don't retry, but if I get one after, then
it is in all likelihood an indication of a wrong password). That's why I think
it'd be much better implemented in core, at the place(s) where getPassword() is
called. There one knows much more, and is not restricted to guesswork (which
may moreover break if the core implementation changes).
{quote}
Sounds reasonable, but is more difficult then it sounds since the location
where {{getPassword}} is called is not necessarily the same as where the
decoding is attempted. Therefore changes at the core level for (IMO) a minor
feature do not seem like a good idea at this time. I do have an idea that I
would like to explore that may help facilitate implement this issue - although
it will not relieve the user from having to track whether {{getPassword}} was
called for a specific file and do a bit of "guesswork" (as you put it):
* Add a *default* method to {{FilePasswordProvider}} called
{{handleDecodingAttemptResult}}
{code:java}
enum FileDecodeResult {
TERMINATE,
RETRY,
IGNORE; // Ignore and take your chances with the code that is trying to
use this key
}
default FileDecodeResult handleDecodingAttemptResult(String resourceKey,
Exception err /* null if success */) {
return FileDecodeResult .TERMINATE;
}
{code}
* The method will be invoked regardless of whether {{getPassword}} was invoked
(so the user knows about successes as well as failures)
* The user can/should use the resource key in order to decide whether
{{getPassword}} has been called for the specified file or not.
* The user can then examine the reported exception (thus "some guesswork") and
decide whether to proceed with a retry or not.
* The {{IGNORE}} case is provided for future uses and/or "advanced" coders who
know what they're doing and are willing to take a chance with the fact that the
decoding did not succeed and no key was loaded (note that the code is quite
tolerant of the fact that no keys are available - at least on the client side).
Note that failure to decode is more likely to be due to a
{{GeneralSecurityException}} rather than an {{IOException}}, but there are no
guarantees as to how failure to decode is signaled. However, as an initial
implementation of this feature I think that users can treat all I/O or security
exceptions as some problem with the password simply display the exception
type/text as a prompt to the interactive framework.
The success call is provided so that implementors can clear any internal state
associated with tracking calls to {{getPassword}}
> Add capability to retry a failed private key decryption when client is
> decrypting private key file(s)
> -
>
> Key: SSHD-850
> URL: https://issues.apache.org/jira/browse/SSHD-850
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.0.0, 2.1.0
>Reporter: Thomas Wolf
>Priority: Minor
>
> In openssh, the ssh config entry NumberOfPasswordPrompts controls the number
> of times the ssh client keeps asking for a password if the one entered was
> invalid in two cases:
> # keyboard-interactive authentication, and
> # asking for passwords for encrypted private keys in identity files in
> pubkey authentication (see [openssh sources;
> sshconnect2.c|https://github.com/openssh/openssh-portable/blob/1a4a9cf/sshconnect2.c#L1380]).
> sshd-core only has support for (1) through setting the property
> {{ClientAuthenticationManager.PASSWORD_PROMPTS}} in the session's properties.
> There doesn't seem to be any support for FilePasswordProvider to make it
> respect this value.
> {{AbstractPEMResourceKeyPairParser.extractkeyPairs()}} and also
> {{BouncyCastleKeyPairResourceParser.loadKeyPair()}} call
> {{FilePasswordProvider.getPassword()}} exactly once.
> So how can I write a ssh client using sshd that asks the user
> NumberOfPasswordPrompts times? Either I'm missing something, or there is some
> support for this missing in sshd.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655339#comment-16655339
]
Goldstein Lyor commented on SSHD-850:
-
One possible avenue of solution might be to override {{Iterable
loadKeys()}} and encapsulate an {{Iterator}} that "lazily" loads the keys, so
that when a key with a problematic password is encountered it can execute the
retry mechanism behind the scenes.
> Add capability to retry a failed private key decryption when client is
> decrypting private key file(s)
> -
>
> Key: SSHD-850
> URL: https://issues.apache.org/jira/browse/SSHD-850
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.0.0, 2.1.0
>Reporter: Thomas Wolf
>Priority: Minor
>
> In openssh, the ssh config entry NumberOfPasswordPrompts controls the number
> of times the ssh client keeps asking for a password if the one entered was
> invalid in two cases:
> # keyboard-interactive authentication, and
> # asking for passwords for encrypted private keys in identity files in
> pubkey authentication (see [openssh sources;
> sshconnect2.c|https://github.com/openssh/openssh-portable/blob/1a4a9cf/sshconnect2.c#L1380]).
> sshd-core only has support for (1) through setting the property
> {{ClientAuthenticationManager.PASSWORD_PROMPTS}} in the session's properties.
> There doesn't seem to be any support for FilePasswordProvider to make it
> respect this value.
> {{AbstractPEMResourceKeyPairParser.extractkeyPairs()}} and also
> {{BouncyCastleKeyPairResourceParser.loadKeyPair()}} call
> {{FilePasswordProvider.getPassword()}} exactly once.
> So how can I write a ssh client using sshd that asks the user
> NumberOfPasswordPrompts times? Either I'm missing something, or there is some
> support for this missing in sshd.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (SSHD-852) Verification fails for hashed known host entry on non standard port generated by OpenSSH client
[
https://issues.apache.org/jira/browse/SSHD-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor resolved SSHD-852.
-
Resolution: Fixed
Fix Version/s: 2.1.1
> Verification fails for hashed known host entry on non standard port generated
> by OpenSSH client
> ---
>
> Key: SSHD-852
> URL: https://issues.apache.org/jira/browse/SSHD-852
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Linux Mint 19
>Reporter: Stefan Verhoeven
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
> Attachments: ConnectToNonDefaultPortTest.java
>
>
> The Apache SshClient is unable to verify a known host entry that was made by
> the OpenSSH client when the entry is on a port other than 22.
>
> I get the following exception
> {code:java}
> org.apache.sshd.common.SshException: Server key did not validate
> at
> org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:440)
> ...{code}
>
> The OpenSSH client will create a hash for `[host]:port` while Apache
> SshClient will check hashed entries for `host` (see
> https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130[).|https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130.]
> This difference will cause the correct known host entry to be marked as not
> a match which in turn causes the exception.
>
> The error can be reproduced by setting up the a SSH server
> {code:java}
> rm ~/.ssh/known_hosts
> docker run -d -p :22 nlesc/xenon-ssh
> # Prime known hosts with hash entry, password=javagat
> ssh xenon@localhost -p 10022 hostname
> {code}
> and then running the attached test.
>
> I created a fix and tests at
> https://github.com/apache/mina-sshd/compare/master...NLeSC:hashed-known-host-port
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-852) Verification fails for hashed known host entry on non standard port generated by OpenSSH client
[
https://issues.apache.org/jira/browse/SSHD-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655162#comment-16655162
]
Goldstein Lyor commented on SSHD-852:
-
Many thanks for the patch - merged it in (with a few minor changes) and
[committed with
acknowledgement|https://github.com/apache/mina-sshd/commit/326725da23bc83593b3a6ce8a367a321f6bb81fd]
- closing the PR as well.
> Verification fails for hashed known host entry on non standard port generated
> by OpenSSH client
> ---
>
> Key: SSHD-852
> URL: https://issues.apache.org/jira/browse/SSHD-852
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Linux Mint 19
>Reporter: Stefan Verhoeven
>Assignee: Goldstein Lyor
>Priority: Minor
> Attachments: ConnectToNonDefaultPortTest.java
>
>
> The Apache SshClient is unable to verify a known host entry that was made by
> the OpenSSH client when the entry is on a port other than 22.
>
> I get the following exception
> {code:java}
> org.apache.sshd.common.SshException: Server key did not validate
> at
> org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:440)
> ...{code}
>
> The OpenSSH client will create a hash for `[host]:port` while Apache
> SshClient will check hashed entries for `host` (see
> https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130[).|https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130.]
> This difference will cause the correct known host entry to be marked as not
> a match which in turn causes the exception.
>
> The error can be reproduced by setting up the a SSH server
> {code:java}
> rm ~/.ssh/known_hosts
> docker run -d -p :22 nlesc/xenon-ssh
> # Prime known hosts with hash entry, password=javagat
> ssh xenon@localhost -p 10022 hostname
> {code}
> and then running the attached test.
>
> I created a fix and tests at
> https://github.com/apache/mina-sshd/compare/master...NLeSC:hashed-known-host-port
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (SSHD-852) Verification fails for hashed known host entry on non standard port generated by OpenSSH client
[
https://issues.apache.org/jira/browse/SSHD-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-852 started by Goldstein Lyor.
---
> Verification fails for hashed known host entry on non standard port generated
> by OpenSSH client
> ---
>
> Key: SSHD-852
> URL: https://issues.apache.org/jira/browse/SSHD-852
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Linux Mint 19
>Reporter: Stefan Verhoeven
>Assignee: Goldstein Lyor
>Priority: Minor
> Attachments: ConnectToNonDefaultPortTest.java
>
>
> The Apache SshClient is unable to verify a known host entry that was made by
> the OpenSSH client when the entry is on a port other than 22.
>
> I get the following exception
> {code:java}
> org.apache.sshd.common.SshException: Server key did not validate
> at
> org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:440)
> ...{code}
>
> The OpenSSH client will create a hash for `[host]:port` while Apache
> SshClient will check hashed entries for `host` (see
> https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130[).|https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130.]
> This difference will cause the correct known host entry to be marked as not
> a match which in turn causes the exception.
>
> The error can be reproduced by setting up the a SSH server
> {code:java}
> rm ~/.ssh/known_hosts
> docker run -d -p :22 nlesc/xenon-ssh
> # Prime known hosts with hash entry, password=javagat
> ssh xenon@localhost -p 10022 hostname
> {code}
> and then running the attached test.
>
> I created a fix and tests at
> https://github.com/apache/mina-sshd/compare/master...NLeSC:hashed-known-host-port
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (SSHD-852) Verification fails for hashed known host entry on non standard port generated by OpenSSH client
[
https://issues.apache.org/jira/browse/SSHD-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor reassigned SSHD-852:
---
Assignee: Goldstein Lyor
> Verification fails for hashed known host entry on non standard port generated
> by OpenSSH client
> ---
>
> Key: SSHD-852
> URL: https://issues.apache.org/jira/browse/SSHD-852
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Linux Mint 19
>Reporter: Stefan Verhoeven
>Assignee: Goldstein Lyor
>Priority: Minor
> Attachments: ConnectToNonDefaultPortTest.java
>
>
> The Apache SshClient is unable to verify a known host entry that was made by
> the OpenSSH client when the entry is on a port other than 22.
>
> I get the following exception
> {code:java}
> org.apache.sshd.common.SshException: Server key did not validate
> at
> org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:440)
> ...{code}
>
> The OpenSSH client will create a hash for `[host]:port` while Apache
> SshClient will check hashed entries for `host` (see
> https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130[).|https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130.]
> This difference will cause the correct known host entry to be marked as not
> a match which in turn causes the exception.
>
> The error can be reproduced by setting up the a SSH server
> {code:java}
> rm ~/.ssh/known_hosts
> docker run -d -p :22 nlesc/xenon-ssh
> # Prime known hosts with hash entry, password=javagat
> ssh xenon@localhost -p 10022 hostname
> {code}
> and then running the attached test.
>
> I created a fix and tests at
> https://github.com/apache/mina-sshd/compare/master...NLeSC:hashed-known-host-port
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
