[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)
Please help review and test solution for SSHD-849
Here is the issue in a nutshell - a client might open an SSH tunnel, send some data and close (normally) its side of the tunnel before the channel to the other side has been successfully established and all data transmitted. Currently a race condition may occur in such a scenario where the code closes the channel while pending messages are still in transit. The patch attempts to accumulate pending messages until channel is open (successfully) and then flush them while maintaining their *order*. At the same time, it attempts to "delay" other messages that may arrive while flushing is in progress so that they will also be sent in the correct order. It also delays the closing of the tunnel until pending data has been flushed (unless an error occurs during the flush...). Since the code is a bit complicated, I would appreciate several extra pairs of eyes reviewing the code. My main areas of concern are (though please feel free to add more): * Does it solve the problem? * Are there any race conditions/deadlocks that it might encounter ? * Is throughput adversely impacted by the extra overhead involved in processing incoming messages - even if no more pending messages. The PR can be found at https://github.com/apache/mina-sshd/pull/72/ and a branch containing this code can be checked out from https://github.com/lgoldstein/mina-sshd/tree/SSHD-849. I would really appreciate your feedback and review on the posted code. Thanks Lyor
[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=16655582#comment-16655582
]
Thomas Wolf commented on SSHD-850:
--
I don't quite understand that. As far as I see, KeyPairProviders are intended
to lazily load keys already. Overriding and re-implementing {{doLoadKey(String
resourceKey, InputStream inputStream, FilePasswordProvider provider)}} should
be good enough.
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). One
is also still left with the problem of how exactly to pass in the desired
number of attempts. Perhaps through the {{FilePasswordProvider}} or a new
subclass thereof (which could even provide a {{getPasswordAgain()}} method),
but if the same one is used for different sessions, that may still get messy.
But lazy-loading keys is problematic anyway with the default {{SshClient}}
since {{SshClient.connect(HostConfigEntry hostConfig)}} pre-loads all
identities from the {{HostConfigEntry}} anyway. At that point it'll ask for
passwords even for keys that may finally not even be used.
Oh, and the {{ClientIdentityLoader}} would also have to be re-done.
> 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] [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=16655328#comment-16655328 ] ASF GitHub Bot commented on SSHD-849: - GitHub user lgoldstein opened a pull request: https://github.com/apache/mina-sshd/pull/72 [SSHD-849] Using a ClientChannelPendingMessagesQueue to regulate messages order while forwarding channel is being set up You can merge this pull request into a Git repository by running: $ git pull https://github.com/lgoldstein/mina-sshd SSHD-849 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mina-sshd/pull/72.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #72 commit 9e4493768917613d6394ad8d170e03806001ac65 Author: Lyor Goldstein Date: 2018-10-18T14:34:53Z [SSHD-849] Using a ClientChannelPendingMessagesQueue to regulate messages order while forwarding channel is being set up > 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)
[GitHub] mina-sshd pull request #72: [SSHD-849] Using a ClientChannelPendingMessagesQ...
GitHub user lgoldstein opened a pull request: https://github.com/apache/mina-sshd/pull/72 [SSHD-849] Using a ClientChannelPendingMessagesQueue to regulate messages order while forwarding channel is being set up You can merge this pull request into a Git repository by running: $ git pull https://github.com/lgoldstein/mina-sshd SSHD-849 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mina-sshd/pull/72.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #72 commit 9e4493768917613d6394ad8d170e03806001ac65 Author: Lyor Goldstein Date: 2018-10-18T14:34:53Z [SSHD-849] Using a ClientChannelPendingMessagesQueue to regulate messages order while forwarding channel is being set up ---
[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)
[GitHub] mina-sshd pull request #71: OpenSSH client creates hash with port, mina shou...
Github user lgoldstein closed the pull request at: https://github.com/apache/mina-sshd/pull/71 ---
[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)
[jira] [Comment Edited] (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=16654040#comment-16654040
]
Goldstein Lyor edited comment on SSHD-852 at 10/18/18 10:28 AM:
Thanks for the contribution - created
[https://github.com/apache/mina-sshd/pull/71] I will review it and merge it in
if no problems come up. Can you provide some link to the documentation that
explains how known host hashes should be calculated for standard and
non-standard ports ? I would be especially interested also in how to hash IPv6
addresses (though not an issue at the moment).
was (Author: lgoldstein):
Thanks for the contribution - created
[https://github.com/apache/mina-sshd/pull/71.] I will review it and merge it in
if no problems come up. Can you provide some link to the documentation that
explains how known host hashes should be calculated for standard and
non-standard ports ? I would be especially interested also in how to hash IPv6
addresses (though not an issue at the moment).
> 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
>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)
