[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=16658386#comment-16658386
]
Thomas Wolf commented on SSHD-850:
--
Thanks; that looks good.
> 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] [Commented] (SSHD-850) sshd client; encrypted private key identity file: FilePasswordProvider called only once; should be called NumberOfPasswordPrompts times
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653046#comment-16653046
]
Thomas Wolf commented on SSHD-850:
--
I know the two are different, and one (keyboard-interactive auth) is handled
fine by sshd. The other (passphrases for encrypted private keys) isn't.
Your proposed work-around for the missing functionality (implement my own
{{KeyPairProvider}} that does this) implies that this special
{{KeyPairProvider}} cannot use {{SecurityUtils.loadKeyPairIdentity()}}. It even
looks I'd have to implement a whole separate hierarchy of
{{KeyPairResourceParser}}s just to get something that in {{extractKeyPairs}}
loops the required number of times, since outside of that it is not known
whether a failure to read a key was due to a wrong password or some other
problem. It also looks to me that I'd need a stateful {{FilePasswordProvider}}
that remembers if it had been called at all for the key so that I can query it
– if it hasn't even been called by the key parser, the key wasn't encrypted (or
had a problem before we even got to decrypting it) and re-trying would be
futile. (Outside of {{extractKeyPairs}} it isn't even known whether the key is
encrypted at all.)
The fact that I'd have to side-step or re-implement quite a lot of the sshd
default behavior is to me an indication that something is missing here in sshd.
> sshd client; encrypted private key identity file: FilePasswordProvider called
> only once; should be called NumberOfPasswordPrompts times
> ---
>
> Key: SSHD-850
> URL: https://issues.apache.org/jira/browse/SSHD-850
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.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] [Created] (SSHD-850) sshd client; encrypted private key identity file: FilePasswordProvider called only once; should be called NumberOfPasswordPrompts times
Thomas Wolf created SSHD-850:
Summary: sshd client; encrypted private key identity file:
FilePasswordProvider called only once; should be called NumberOfPasswordPrompts
times
Key: SSHD-850
URL: https://issues.apache.org/jira/browse/SSHD-850
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Thomas Wolf
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] [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
]
Thomas Wolf updated SSHD-860:
-
Description:
{{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!_
was:
{{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!_
Link to test case updated.
I'm a bit surprised you consider this "minor"... note that this also means that
a serious sshd client cannot use {{UserAuthPublicKeyIterator}} but needs to
provide its own implementation, which is not possible without some minor
hacking. See for instance what we do in JGit to get around this problem:
*
[JGitPublicKeyIterator.java|https://git.eclipse.org/r/#/c/131884/6/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/internal/transport/sshd/JGitPublicKeyIterator.java]
*
[JGitPublicKeyAuthentication.java|https://git.eclipse.org/r/#/c/131884/6/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/internal/transport/sshd/JGitPublicKeyAuthentication.java]
– not calling {{super.init()}} is the "minor hack" I referred to above
*
[JGitPublicKeyAuthFactory.java|https://git.eclipse.org/r/#/c/131884/6/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/internal/transport/sshd/JGitPublicKeyAuthFactory.java]
> 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,
[jira] [Reopened] (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
]
Thomas Wolf reopened SSHD-860:
--
> 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=16679404#comment-16679404
]
Thomas Wolf commented on SSHD-860:
--
Thanks for the effort. But it doesn't work yet.
# 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".
# 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.
And actually I should test (1) in the solution I implemented in JGit, too. I
noticed that the JGit tests exercise this only with iterators containing one
element each, so I wouldn't have noticed. I need to add a test in JGit with
several identities per iterator. I suspect I'll then see that same behavior in
JGit, too. :(
> 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=16680201#comment-16680201
]
Thomas Wolf commented on SSHD-860:
--
{quote}I am not sure I understand how this happens
{quote}
It means that somewhere along the line, something still uses a stream operation
to obtain an iterator. An iterator on a stream will be such a spliterator, and
those buffer.
{quote}Can you indicate the code that uses these "newfangled spliterators" ?
{quote}
As far as I see, the culprit is this call chain:
* UserAuthPublicKeyIterator.initializeSessionIdentities()
* ClientSession.providerOf(session)
*
KeyIdentityProvider.resolveKeyIdentityProvider(session.getRegisteredIdentities(),
session.getKeyPairProvider())
* KeyIdentityProvider.multiProvider(identities, keys)
* KeyIdentityProvider.multiProvider(GenericUtils.asList(providers))
* KeyIdentityProvider.wrapKeyPairs(iterableOf(providers))
** iterableOf(providers) calls
*** GenericUtils.multiIterableSuppliers(GenericUtils.wrapIterable(providers, p
-> p::loadKeys)), which returns {{() -> GenericUtils.wrapIterator(iter,
mapper)}}
GenericUtils.wrapIterator(iter, mapper) does {{return
stream(iter).map(mapper).iterator()}}
*** GenericUtils.multiIterableSuppliers(...) does {{return () ->
stream(providers).flatMap(s ->
stream(s.get())).map(Function.identity()).iterator()}}
I'm not sure which of the last two is the real problem here; tracing this
through debugging is highly confusing once it enters hasNext(). Looks to me we
have in the end a spliterator over a stream of spliterators (a spliterator of
spliterators). Which also explains why in my JGit code it doesn't occur; I made
a point of not using any stream operations in these key iterators.
> 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] [Comment Edited] (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=16680201#comment-16680201
]
Thomas Wolf edited comment on SSHD-860 at 11/8/18 7:10 PM:
---
{quote}I am not sure I understand how this happens
{quote}
It means that somewhere along the line, something still uses a stream operation
to obtain an iterator. An iterator on a stream will be such a spliterator, and
those buffer.
{quote}Can you indicate the code that uses these "newfangled spliterators" ?
{quote}
As far as I see, the culprit is this call chain:
* UserAuthPublicKeyIterator.initializeSessionIdentities()
* ClientSession.providerOf(session)
*
KeyIdentityProvider.resolveKeyIdentityProvider(session.getRegisteredIdentities(),
session.getKeyPairProvider())
* KeyIdentityProvider.multiProvider(identities, keys)
* KeyIdentityProvider.multiProvider(GenericUtils.asList(providers))
* KeyIdentityProvider.wrapKeyPairs(iterableOf(providers))
** iterableOf(providers) calls
*** GenericUtils.multiIterableSuppliers(GenericUtils.wrapIterable(providers, p
-> p::loadKeys))
*** GenericUtils.wrapIterable(iter, mapper) returns {{() ->
GenericUtils.wrapIterator(iter, mapper)}}
GenericUtils.wrapIterator(iter, mapper) does {{return
stream(iter).map(mapper).iterator()}}
*** GenericUtils.multiIterableSuppliers(...) does {{return () ->
stream(providers).flatMap(s ->
stream(s.get())).map(Function.identity()).iterator()}}
I'm not sure which of the last two is the real problem here; tracing this
through debugging is highly confusing once it enters hasNext(). Looks to me we
have in the end a spliterator over a stream of spliterators (a spliterator of
spliterators). Which also explains why in my JGit code it doesn't occur; I made
a point of not using any stream operations in these key iterators.
was (Author: wolft):
{quote}I am not sure I understand how this happens
{quote}
It means that somewhere along the line, something still uses a stream operation
to obtain an iterator. An iterator on a stream will be such a spliterator, and
those buffer.
{quote}Can you indicate the code that uses these "newfangled spliterators" ?
{quote}
As far as I see, the culprit is this call chain:
* UserAuthPublicKeyIterator.initializeSessionIdentities()
* ClientSession.providerOf(session)
*
KeyIdentityProvider.resolveKeyIdentityProvider(session.getRegisteredIdentities(),
session.getKeyPairProvider())
* KeyIdentityProvider.multiProvider(identities, keys)
* KeyIdentityProvider.multiProvider(GenericUtils.asList(providers))
* KeyIdentityProvider.wrapKeyPairs(iterableOf(providers))
** iterableOf(providers) calls
*** GenericUtils.multiIterableSuppliers(GenericUtils.wrapIterable(providers, p
-> p::loadKeys)), which returns {{() -> GenericUtils.wrapIterator(iter,
mapper)}}
GenericUtils.wrapIterator(iter, mapper) does {{return
stream(iter).map(mapper).iterator()}}
*** GenericUtils.multiIterableSuppliers(...) does {{return () ->
stream(providers).flatMap(s ->
stream(s.get())).map(Function.identity()).iterator()}}
I'm not sure which of the last two is the real problem here; tracing this
through debugging is highly confusing once it enters hasNext(). Looks to me we
have in the end a spliterator over a stream of spliterators (a spliterator of
spliterators). Which also explains why in my JGit code it doesn't occur; I made
a point of not using any stream operations in these key iterators.
> 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)
>
[jira] [Created] (SSHD-866) Keyboard-interactive protocol implementation aborts too early
Thomas Wolf created SSHD-866:
Summary: Keyboard-interactive protocol implementation aborts too
early
Key: SSHD-866
URL: https://issues.apache.org/jira/browse/SSHD-866
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Thomas Wolf
Keyboard-interactive authentication counts _all_ SSH_MSG_USERAUTH_INFO_REQUESTs
against the {{maxTrials}} limit. However, the protocol as specified in [RFC
4256|https://tools.ietf.org/html/rfc4256] allows for info requests without
prompts, to which the client must also respond. Such requests should not count
towards the {{maxTrials}} limit.
This is a real-world problem. For instance the sshd server on my Mac replies
which such a zero-prompt info request before it sends the
SSH_MSG_USERAUTH_SUCCESS. So with the default {{maxTries == 3}}, a login
attempt via an sshd using {{UserAuthKeyboardInteractive}} fails if I mis-type
the password twice and provide the correct password on the third try because
then the zero-prompt info request will be the _fourth_ info request and
{{UserAuthKeyboardInteractive}} therefore aborts.
Here's a log snippet from a normal login _not_ via sshd, which succeeds:
$ ssh -vvv myself@localhost
...
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: __
debug3: send packet: type 61
debug3: receive packet: type 51
debug1: Authentications that can continue: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: __
debug3: send packet: type 61
debug3: receive packet: type 51
debug1: Authentications that can continue: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: __
debug3: send packet: type 61
debug3: {color:#ff}receive packet: type 60{color}
debug2: {color:#ff}input_userauth_info_req{color}
debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
debug3: {color:#ff}send packet: type 61{color}
debug3: receive packet: type 52
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to localhost ([::1]:22).
...
If I do the same with an sshd client, authentication fails because of the
{color:#ff}red{color} _fourth_ info request. RFC 4256 contains an example
showing such an additional zero-prompt info request, though not for a normal
authentication but for a password change. But it appears that it can also occur
on normal authentications.
So I think only info requests with {{num_prompts > 0}} should count towards
{{maxTrials}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SSHD-866) Client: keyboard-interactive protocol implementation aborts too early
[
https://issues.apache.org/jira/browse/SSHD-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-866:
-
Summary: Client: keyboard-interactive protocol implementation aborts too
early (was: Keyboard-interactive protocol implementation aborts too early)
> Client: keyboard-interactive protocol implementation aborts too early
> -
>
> Key: SSHD-866
> URL: https://issues.apache.org/jira/browse/SSHD-866
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Thomas Wolf
>Priority: Minor
>
> Keyboard-interactive authentication counts _all_
> SSH_MSG_USERAUTH_INFO_REQUESTs against the {{maxTrials}} limit. However, the
> protocol as specified in [RFC 4256|https://tools.ietf.org/html/rfc4256]
> allows for info requests without prompts, to which the client must also
> respond. Such requests should not count towards the {{maxTrials}} limit.
> This is a real-world problem. For instance the sshd server on my Mac replies
> which such a zero-prompt info request before it sends the
> SSH_MSG_USERAUTH_SUCCESS. So with the default {{maxTries == 3}}, a login
> attempt via an sshd using {{UserAuthKeyboardInteractive}} fails if I mis-type
> the password twice and provide the correct password on the third try because
> then the zero-prompt info request will be the _fourth_ info request and
> {{UserAuthKeyboardInteractive}} therefore aborts.
> Here's a log snippet from a normal login _not_ via sshd, which succeeds:
> $ ssh -vvv myself@localhost
> ...
> debug1: Next authentication method: keyboard-interactive
> debug2: userauth_kbdint
> debug3: send packet: type 50
> debug2: we sent a keyboard-interactive packet, wait for reply
> debug3: receive packet: type 60
> debug2: input_userauth_info_req
> debug2: input_userauth_info_req: num_prompts 1
> Password: __
> debug3: send packet: type 61
> debug3: receive packet: type 51
> debug1: Authentications that can continue: keyboard-interactive
> debug2: userauth_kbdint
> debug3: send packet: type 50
> debug2: we sent a keyboard-interactive packet, wait for reply
> debug3: receive packet: type 60
> debug2: input_userauth_info_req
> debug2: input_userauth_info_req: num_prompts 1
> Password: __
> debug3: send packet: type 61
> debug3: receive packet: type 51
> debug1: Authentications that can continue: keyboard-interactive
> debug2: userauth_kbdint
> debug3: send packet: type 50
> debug2: we sent a keyboard-interactive packet, wait for reply
> debug3: receive packet: type 60
> debug2: input_userauth_info_req
> debug2: input_userauth_info_req: num_prompts 1
> Password: __
> debug3: send packet: type 61
> debug3: {color:#ff}receive packet: type 60{color}
> debug2: {color:#ff}input_userauth_info_req{color}
> debug2: {color:#ff}input_userauth_info_req: _num_prompts 0_{color}
> debug3: {color:#ff}send packet: type 61{color}
> debug3: receive packet: type 52
> debug1: Authentication succeeded (keyboard-interactive).
> Authenticated to localhost ([::1]:22).
> ...
>
> If I do the same with an sshd client, authentication fails because of the
> {color:#ff}red{color} _fourth_ info request. RFC 4256 contains an example
> showing such an additional zero-prompt info request, though not for a normal
> authentication but for a password change. But it appears that it can also
> occur on normal authentications.
> So I think only info requests with {{num_prompts > 0}} should count towards
> {{maxTrials}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-867) HostConfigEntry.getProperty(String name, String defaultValue) may return null even if defaultValue != null
Thomas Wolf created SSHD-867:
Summary: HostConfigEntry.getProperty(String name, String
defaultValue) may return null even if defaultValue != null
Key: SSHD-867
URL: https://issues.apache.org/jira/browse/SSHD-867
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Thomas Wolf
{{HostConfigEntry.getProperty(String name, String defaultValue)}} contains
{code:java}
Map props = getProperties();
if (GenericUtils.isEmpty(props)) {
return null;
}{code}
This should be
{code:java}
Map props = getProperties();
if (GenericUtils.isEmpty(props)) {
return defaultValue;
}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-860) org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator pre-loads client identities (private key files)
Thomas Wolf created SSHD-860:
Summary:
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
{{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-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=16679427#comment-16679427
]
Thomas Wolf commented on SSHD-860:
--
I wrote:
{quote}I need to add a test in JGit with several identities per iterator.{quote}
No, actually there is a test in JGit for this; didn't look right. With the
solution I implemented in JGit it works. JGit only uses simple iterators. The
default in UserAuthPublicKey, even with the new code, ends up using these
newfangled spliterators, and those do that pre-loading.
> 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=16684218#comment-16684218
]
Thomas Wolf commented on SSHD-860:
--
Thank you; that did it. My test, adapted to current master, now passes, and
keys are indeed loaded one by one.
> 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-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=16690892#comment-16690892
]
Thomas Wolf commented on SSHD-868:
--
Is the length encoding really an issue? Ssh packet length is limited, in Apache
sshd apparently to 256kB (see [{{AbstractSession.decode()}}, line
1007|https://github.com/apache/mina-sshd/blob/0241783/sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java#L1007]).
And for instance {{ByteArrayBuffer.getString(Charset)}} checks that the buffer
does have enough unread bytes available. So if someone sends a packet
containing a bogus string with a length 0x, sshd will throw a buffer
exception, but it won't run into an OOM.
The number of challenges in keyboard-interactive authentication might perhaps
be a problem. A malicious server could just keep on sending zero-prompt info
requests to make the client be stuck. Perhaps counting the zero-prompt info
requests separately and aborting when that count reaches {{2 * maxTrials}}
might be an idea. I don't see any such count in openssh, though. They seem to
count only the number of inits for keyboard-interactive. See
[{{sshconnect2.c}}, lines
1705ff|https://github.com/openssh/openssh-portable/blob/aaed635/sshconnect2.c#L1705].
Looks to me that the Apache sshd way of counting is better.
> 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] [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=16690897#comment-16690897
]
Thomas Wolf commented on SSHD-868:
--
{quote}Perhaps counting the zero-prompt info requests separately and
aborting...{quote}
Ah, I see you did something like this already in [commit
a6dffd5|https://github.com/apache/mina-sshd/commit/a6dffd5].
> 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] [Comment Edited] (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=16690892#comment-16690892
]
Thomas Wolf edited comment on SSHD-868 at 11/18/18 12:55 PM:
-
Is the length encoding really an issue? Ssh packet length is limited, in Apache
sshd apparently to 256kB (see [{{AbstractSession.decode()}}, line
1007|https://github.com/apache/mina-sshd/blob/0241783/sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java#L1007]).
And for instance {{ByteArrayBuffer.getString(Charset)}} checks that the buffer
does have enough unread bytes available. So if someone sends a packet
containing a bogus string with a length 0x, sshd will throw a buffer
exception, but it won't run into an OOM.
The number of challenges in keyboard-interactive authentication might perhaps
be a problem. A malicious server could just keep on sending zero-prompt info
requests to make the client be stuck. At least until the client-side
authentication timeout kicks in? Perhaps counting the zero-prompt info requests
separately and aborting when that count reaches {{2 * maxTrials}} might be an
idea. I don't see any such count in openssh, though. They seem to count only
the number of inits for keyboard-interactive. See [{{sshconnect2.c}}, lines
1705ff|https://github.com/openssh/openssh-portable/blob/aaed635/sshconnect2.c#L1705].
Looks to me that the Apache sshd way of counting is better.
was (Author: wolft):
Is the length encoding really an issue? Ssh packet length is limited, in Apache
sshd apparently to 256kB (see [{{AbstractSession.decode()}}, line
1007|https://github.com/apache/mina-sshd/blob/0241783/sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java#L1007]).
And for instance {{ByteArrayBuffer.getString(Charset)}} checks that the buffer
does have enough unread bytes available. So if someone sends a packet
containing a bogus string with a length 0x, sshd will throw a buffer
exception, but it won't run into an OOM.
The number of challenges in keyboard-interactive authentication might perhaps
be a problem. A malicious server could just keep on sending zero-prompt info
requests to make the client be stuck. Perhaps counting the zero-prompt info
requests separately and aborting when that count reaches {{2 * maxTrials}}
might be an idea. I don't see any such count in openssh, though. They seem to
count only the number of inits for keyboard-interactive. See
[{{sshconnect2.c}}, lines
1705ff|https://github.com/openssh/openssh-portable/blob/aaed635/sshconnect2.c#L1705].
Looks to me that the Apache sshd way of counting is better.
> 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] [Created] (SSHD-884) Release plan?
Thomas Wolf created SSHD-884: Summary: Release plan? Key: SSHD-884 URL: https://issues.apache.org/jira/browse/SSHD-884 Project: MINA SSHD Issue Type: Question Reporter: Thomas Wolf Is there a release plan for Apache MINA sshd somewhere where users could learn when new releases are planned to be made? I've seen a mention in SSHD-861 that the next version (2.2.0 ?) would probably come "Q1 2019"? Would it be possible to have an sshd 2.2.0 in the maven repositories by mid-February? I'd very much like to update the integration in Eclipse (EGit/JGit) to sshd 2.2.0 for the next EGit release, which is on 2019-03-20. There've been quite a few fixes and improvements I'd like to see in Eclipse, too. For that I'd need to have maven artifacts available by mid-February at the latest. Otherwise we'll have to wait another three months. [Related EGit issue|https://bugs.eclipse.org/bugs/show_bug.cgi?id=541425]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SSHD-708) Add support for password encrypted OpenSSH private key files
[ https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16715205#comment-16715205 ] Thomas Wolf edited comment on SSHD-708 at 12/10/18 5:42 PM: No hurry. I didn't generalize it – OpenSSH has bcrypt hard-wired, and I didn't see the point of doing some YAGNI general solution, so I also hard-wired bcrypt. BTW, the corresponding Eclipse feature request is [bug 541703|https://bugs.eclipse.org/bugs/show_bug.cgi?id=541703]. was (Author: wolft): No hurry. I didn't generalize it – OpenSSH has bcrypt hard-wired, and I didn't see the point of doing some YAGNI general solution, so I also hard-wired bcrypt. > Add support for password encrypted OpenSSH private key files > > > Key: SSHD-708 > URL: https://issues.apache.org/jira/browse/SSHD-708 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Goldstein Lyor >Assignee: Goldstein Lyor >Priority: Minor > > The current code supports only reading un-encrypted private key files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-708) Add support for password encrypted OpenSSH private key files
[ https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16715167#comment-16715167 ] Thomas Wolf commented on SSHD-708: -- Quite a coincidence. The Eclipse legal team got back to me shortly after I had written the comment above; they also don't see a problem with including this source in Apache MINA sshd and then later using this Apache MINA sshd in Eclipse. So there's the PR. > Add support for password encrypted OpenSSH private key files > > > Key: SSHD-708 > URL: https://issues.apache.org/jira/browse/SSHD-708 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Goldstein Lyor >Assignee: Goldstein Lyor >Priority: Minor > > The current code supports only reading un-encrypted private key files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-708) Add support for password encrypted OpenSSH private key files
[ https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16715205#comment-16715205 ] Thomas Wolf commented on SSHD-708: -- No hurry. I didn't generalize it – OpenSSH has bcrypt hard-wired, and I didn't see the point of doing some YAGNI general solution, so I also hard-wired bcrypt. > Add support for password encrypted OpenSSH private key files > > > Key: SSHD-708 > URL: https://issues.apache.org/jira/browse/SSHD-708 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Goldstein Lyor >Assignee: Goldstein Lyor >Priority: Minor > > The current code supports only reading un-encrypted private key files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-708) Add support for password encrypted OpenSSH private key files
[
https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718592#comment-16718592
]
Thomas Wolf commented on SSHD-708:
--
This would have need a review.
* Thanks for the attribution, but it wouldn't have been necessary. Most of the
code I had written is not in that commit anyway but in the parent commit.
* It would have helped if you had created your own PR for this. Now it's
rather difficult for me to comment on this. :(
* It's *broken*.
[MAX_ROUNDS|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L58]
is wrong. OpenSSH does *not* store an exponent for the rounds but the number
of rounds. I even had a comment in my code pointing this out. The code as is
will fail to decode a key generated with {{ssh-keygen -t ed25519 -a 33}}.
Besides, I don't understand the comment about "doubling". What doubles?
* I very much like the addition of tests for the password-provider re-try loop.
* Setting local variables to {{null}} at the end of methods doesn't improve
"getting rid of sensitive data", does it? For arrays, yes, but if a password
comes in as a String, there's not much one can do.
*
[bcryptKdf|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L192]
doesn't throw any checked exceptions. The [catch block you added
above|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L167]
should actually be inside {{bcryptKdf}}, and it should not handle
{{IOException}} (never thrown there), only {{GeneralSecurityException}}. This
should simply be as in my PR.
* Otherwise it's very hard to review this because the code has changed very
much, has become IMO needlessly general and complicated, and the individual
commits include unrelated formatting changes.
> Add support for password encrypted OpenSSH private key files
>
>
> Key: SSHD-708
> URL: https://issues.apache.org/jira/browse/SSHD-708
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> The current code supports only reading un-encrypted private key files
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SSHD-708) Add support for password encrypted OpenSSH private key files
[
https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718592#comment-16718592
]
Thomas Wolf edited comment on SSHD-708 at 12/12/18 8:48 AM:
This would have needed a review.
* Thanks for the attribution, but it wouldn't have been necessary. Most of the
code I had written is not in that commit anyway but in the parent commit.
* It would have helped if you had created your own PR for this. Now it's
rather difficult for me to comment on this. :(
* It's *broken*.
[MAX_ROUNDS|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L58]
is wrong. OpenSSH does *not* store an exponent for the rounds but the number
of rounds. I even had a comment in my code pointing this out. The code as is
will fail to decode a key generated with {{ssh-keygen -t ed25519 -a 33}}.
Besides, I don't understand the comment about "doubling". What doubles?
* I very much like the addition of tests for the password-provider re-try loop.
* Setting local variables to {{null}} at the end of methods doesn't improve
"getting rid of sensitive data", does it? For arrays, yes, but if a password
comes in as a String, there's not much one can do.
*
[bcryptKdf|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L192]
doesn't throw any checked exceptions. The [catch block you added
above|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L167]
should actually be inside {{bcryptKdf}}, and it should not handle
{{IOException}} (never thrown there), only {{GeneralSecurityException}}. This
should simply be as in my PR.
* [This
constructor|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L76]
will bypass the length check on the salt in [Line
81|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L81].
Since this constructor is never used, why add it at all?
* Otherwise it's very hard to review this because the code has changed very
much, has become IMO needlessly general and complicated, and the individual
commits include unrelated formatting changes.
was (Author: wolft):
This would have needed a review.
* Thanks for the attribution, but it wouldn't have been necessary. Most of the
code I had written is not in that commit anyway but in the parent commit.
* It would have helped if you had created your own PR for this. Now it's
rather difficult for me to comment on this. :(
* It's *broken*.
[MAX_ROUNDS|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L58]
is wrong. OpenSSH does *not* store an exponent for the rounds but the number
of rounds. I even had a comment in my code pointing this out. The code as is
will fail to decode a key generated with {{ssh-keygen -t ed25519 -a 33}}.
Besides, I don't understand the comment about "doubling". What doubles?
* I very much like the addition of tests for the password-provider re-try loop.
* Setting local variables to {{null}} at the end of methods doesn't improve
"getting rid of sensitive data", does it? For arrays, yes, but if a password
comes in as a String, there's not much one can do.
*
[bcryptKdf|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L192]
doesn't throw any checked exceptions. The [catch block you added
above|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L167]
should actually be inside {{bcryptKdf}}, and it should not handle
{{IOException}} (never thrown there), only {{GeneralSecurityException}}. This
should simply be as in my PR.
* Otherwise it's very hard to review this because the code has changed very
much, has become IMO needlessly general and complicated, and the individual
commits include unrelated formatting changes.
> Add support for password encrypted OpenSSH private key files
>
>
> Key: SSHD-708
> URL: https://issues.apache.org/jira/browse/SSHD-708
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> The current code supports only reading
[jira] [Comment Edited] (SSHD-708) Add support for password encrypted OpenSSH private key files
[
https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718592#comment-16718592
]
Thomas Wolf edited comment on SSHD-708 at 12/12/18 8:26 AM:
This would have needed a review.
* Thanks for the attribution, but it wouldn't have been necessary. Most of the
code I had written is not in that commit anyway but in the parent commit.
* It would have helped if you had created your own PR for this. Now it's
rather difficult for me to comment on this. :(
* It's *broken*.
[MAX_ROUNDS|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L58]
is wrong. OpenSSH does *not* store an exponent for the rounds but the number
of rounds. I even had a comment in my code pointing this out. The code as is
will fail to decode a key generated with {{ssh-keygen -t ed25519 -a 33}}.
Besides, I don't understand the comment about "doubling". What doubles?
* I very much like the addition of tests for the password-provider re-try loop.
* Setting local variables to {{null}} at the end of methods doesn't improve
"getting rid of sensitive data", does it? For arrays, yes, but if a password
comes in as a String, there's not much one can do.
*
[bcryptKdf|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L192]
doesn't throw any checked exceptions. The [catch block you added
above|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L167]
should actually be inside {{bcryptKdf}}, and it should not handle
{{IOException}} (never thrown there), only {{GeneralSecurityException}}. This
should simply be as in my PR.
* Otherwise it's very hard to review this because the code has changed very
much, has become IMO needlessly general and complicated, and the individual
commits include unrelated formatting changes.
was (Author: wolft):
This would have need a review.
* Thanks for the attribution, but it wouldn't have been necessary. Most of the
code I had written is not in that commit anyway but in the parent commit.
* It would have helped if you had created your own PR for this. Now it's
rather difficult for me to comment on this. :(
* It's *broken*.
[MAX_ROUNDS|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L58]
is wrong. OpenSSH does *not* store an exponent for the rounds but the number
of rounds. I even had a comment in my code pointing this out. The code as is
will fail to decode a key generated with {{ssh-keygen -t ed25519 -a 33}}.
Besides, I don't understand the comment about "doubling". What doubles?
* I very much like the addition of tests for the password-provider re-try loop.
* Setting local variables to {{null}} at the end of methods doesn't improve
"getting rid of sensitive data", does it? For arrays, yes, but if a password
comes in as a String, there's not much one can do.
*
[bcryptKdf|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L192]
doesn't throw any checked exceptions. The [catch block you added
above|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L167]
should actually be inside {{bcryptKdf}}, and it should not handle
{{IOException}} (never thrown there), only {{GeneralSecurityException}}. This
should simply be as in my PR.
* Otherwise it's very hard to review this because the code has changed very
much, has become IMO needlessly general and complicated, and the individual
commits include unrelated formatting changes.
> Add support for password encrypted OpenSSH private key files
>
>
> Key: SSHD-708
> URL: https://issues.apache.org/jira/browse/SSHD-708
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> The current code supports only reading un-encrypted private key files
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SSHD-708) Add support for password encrypted OpenSSH private key files
[
https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718592#comment-16718592
]
Thomas Wolf edited comment on SSHD-708 at 12/12/18 8:50 AM:
This would have needed a review.
* Thanks for the attribution, but it wouldn't have been necessary. Most of the
code I had written is not in that commit anyway but in the parent commit.
* It would have helped if you had created your own PR for this. Now it's
rather difficult for me to comment on this. :(
* It's *broken*.
[MAX_ROUNDS|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L58]
is wrong. OpenSSH does *not* store an exponent for the rounds but the number
of rounds. I even had a comment in my code pointing this out. The code as is
will fail to decode a key generated with {{ssh-keygen -t ed25519 -a 33}}.
Besides, I don't understand the comment about "doubling". What doubles?
* I very much like the addition of tests for the password-provider re-try loop.
* Setting local variables to {{null}} at the end of methods doesn't improve
"getting rid of sensitive data", does it? For arrays, yes, clearing the values
should be done, but if a password comes in as a String, there's not much one
can do.
*
[bcryptKdf|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L192]
doesn't throw any checked exceptions. The [catch block you added
above|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L167]
should actually be inside {{bcryptKdf}}, and it should not handle
{{IOException}} (never thrown there), only {{GeneralSecurityException}}. This
should simply be as in my PR.
* [This
constructor|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L76]
will bypass the length check on the salt in [Line
81|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L81].
Since this constructor is never used, why add it at all?
* Otherwise it's very hard to review this because the code has changed very
much, has become IMO needlessly general and complicated, and the individual
commits include unrelated formatting changes.
was (Author: wolft):
This would have needed a review.
* Thanks for the attribution, but it wouldn't have been necessary. Most of the
code I had written is not in that commit anyway but in the parent commit.
* It would have helped if you had created your own PR for this. Now it's
rather difficult for me to comment on this. :(
* It's *broken*.
[MAX_ROUNDS|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L58]
is wrong. OpenSSH does *not* store an exponent for the rounds but the number
of rounds. I even had a comment in my code pointing this out. The code as is
will fail to decode a key generated with {{ssh-keygen -t ed25519 -a 33}}.
Besides, I don't understand the comment about "doubling". What doubles?
* I very much like the addition of tests for the password-provider re-try loop.
* Setting local variables to {{null}} at the end of methods doesn't improve
"getting rid of sensitive data", does it? For arrays, yes, but if a password
comes in as a String, there's not much one can do.
*
[bcryptKdf|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L192]
doesn't throw any checked exceptions. The [catch block you added
above|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L167]
should actually be inside {{bcryptKdf}}, and it should not handle
{{IOException}} (never thrown there), only {{GeneralSecurityException}}. This
should simply be as in my PR.
* [This
constructor|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L76]
will bypass the length check on the salt in [Line
81|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/main/java/org/apache/sshd/common/config/keys/loader/openssh/kdf/BCryptKdfOptions.java#L81].
Since this constructor is never used, why add it at all?
* Otherwise it's very hard to review this because the code has changed very
much, has become IMO needlessly general and complicated, and the individual
commits include unrelated formatting changes.
> Add support for password
[jira] [Comment Edited] (SSHD-708) Add support for password encrypted OpenSSH private key files
[
https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718819#comment-16718819
]
Thomas Wolf edited comment on SSHD-708 at 12/12/18 11:26 AM:
-
{quote}
What I am trying to do is prevent some kind of "attack" by providing a
malicious (or corrupted) value that would cause the code to "hang" by executing
a very large number of round
{quote}
OpenSSH doesn't limit this; any value in the range [1 .. INT_MAX] is allowed.
IMO we shouldn't worry about unreasonably large values here; this is reading a
_private_ key of a user. If the user created that key with 2**30 rounds, so be
it. The code should just guard against rounds < 1.
Re attribution: of course it's a community effort. But with so many changes and
the code I provided spread even over two commits, one authored by you and a
second small one with my name on it, it isn't really worth the trouble. It's no
big deal; just that I would have done this differently. (Merge the PR, maybe
with just a little amend to remove the {{MessageFormat}}, then rebase my own
work on top of that merge and continue from there on.) But as I said, no big
deal.
was (Author: wolft):
{quote}What I am trying to do is prevent some kind of "attack" by providing a
malicious (or corrupted) value that would cause the code to "hang" by executing
a very large number of round\{quote}
OpenSSH doesn't limit this; any value in the range [1 .. INT_MAX] is allowed.
IMO we shouldn't worry about unreasonably large values here; this is reading a
_private_ key of a user. If the user created that key with 2**30 rounds, so be
it. The code should just guard against rounds < 1.
Re attribution: of course it's a community effort. But with so many changes and
the code I provided spread even over two commits, one authored by you and a
second small one with my name on it, it isn't really worth the trouble. It's no
big deal; just that I would have done this differently. (Merge the PR, maybe
with just a little amend to remove the {{MessageFormat}}, then rebase my own
work on top of that merge and continue from there on.) But as I said, no big
deal.
> Add support for password encrypted OpenSSH private key files
>
>
> Key: SSHD-708
> URL: https://issues.apache.org/jira/browse/SSHD-708
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> The current code supports only reading un-encrypted private key files
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-708) Add support for password encrypted OpenSSH private key files
[
https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718819#comment-16718819
]
Thomas Wolf commented on SSHD-708:
--
{quote}What I am trying to do is prevent some kind of "attack" by providing a
malicious (or corrupted) value that would cause the code to "hang" by executing
a very large number of round\{quote}
OpenSSH doesn't limit this; any value in the range [1 .. INT_MAX] is allowed.
IMO we shouldn't worry about unreasonably large values here; this is reading a
_private_ key of a user. If the user created that key with 2**30 rounds, so be
it. The code should just guard against rounds < 1.
Re attribution: of course it's a community effort. But with so many changes and
the code I provided spread even over two commits, one authored by you and a
second small one with my name on it, it isn't really worth the trouble. It's no
big deal; just that I would have done this differently. (Merge the PR, maybe
with just a little amend to remove the {{MessageFormat}}, then rebase my own
work on top of that merge and continue from there on.) But as I said, no big
deal.
> Add support for password encrypted OpenSSH private key files
>
>
> Key: SSHD-708
> URL: https://issues.apache.org/jira/browse/SSHD-708
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> The current code supports only reading un-encrypted private key files
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-708) Add support for password encrypted OpenSSH private key files
[
https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718870#comment-16718870
]
Thomas Wolf commented on SSHD-708:
--
{quote}
The code is *generic* - i.e., if we ever replace the {{bcrypt}} with something
else, this is how the I would like the {{catch}} block to behave, so I don't
see the harm in writing the code in this manner now rather than later.
{quote}
I had already noticed that we have quite different philosophies about this. :-)
I'm nearer the opposite end of the spectrum: do what's needed and not more, and
generalize later when and if a need arises. Yes, with a general _library_ one
needs to plan and build in _some_ genericity and configurability from the
beginning, but even then I like to keep interfaces as narrow and simple as
possible and generalize further only when there's a real need for it. I don't
think OpenSSH will switch from bcrypt to something else soon...
Anyway, it's allright as it is.
> Add support for password encrypted OpenSSH private key files
>
>
> Key: SSHD-708
> URL: https://issues.apache.org/jira/browse/SSHD-708
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> The current code supports only reading un-encrypted private key files
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-873) BuiltinCiphers.aes256cbc.getBlockSize() returns wrong value
[ https://issues.apache.org/jira/browse/SSHD-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704908#comment-16704908 ] Thomas Wolf commented on SSHD-873: -- Do we need a getKeyBytesCount()? There's already getKeySize() that returns the size in bits. > BuiltinCiphers.aes256cbc.getBlockSize() returns wrong value > --- > > Key: SSHD-873 > URL: https://issues.apache.org/jira/browse/SSHD-873 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Thomas Wolf >Assignee: Goldstein Lyor >Priority: Minor > > As far as I know AES always has a block size of 16. BuiltinCiphers returns 32 > for aes256, and 24 for aes192. That's not the block size, it's the key size > in bytes. > Maybe I misunderstand something? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-708) Add support for password encrypted ed25519 private key files
[ https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704013#comment-16704013 ] Thomas Wolf commented on SSHD-708: -- Supporting encrypted OpenSSH key files is getting somewhat more urgent. OpenSSH has switched in recent versions its default settings and now by default creates key files that use its "new" format, and it always uses that format for ed25519 keys. There is a Java library that implements the necessary Bcrypt KDF; available as maven artifact org.connectbot.jbcrypt:jbcrypt:1.0.0. That appears to be a copy of org.mindrot.jbcrypt, but with the pbkdf functionality added. License is ISC. With that library, decrypting encrypted OpenSSH key files is possible. See [Eclipse bug 541703|https://bugs.eclipse.org/bugs/show_bug.cgi?id=541703] for some initial thoughts. For use in Eclipse I'll have to get legal clearance for that org.connectbot.jbcrypt artifact from the Eclipse legal team. What constraints exist on the Apache side? Would it be OK if I provided a PR that just consumes this maven artifact via a dependency? Would it also be OK if we just copied the source of this BCrypt implementation into the sshd source tree (the artifact contains only a single implementation class)? (In both cases I'll have to check with the Eclipse legal team if doing either would be OK with _them_...) And which would you prefer? > Add support for password encrypted ed25519 private key files > > > Key: SSHD-708 > URL: https://issues.apache.org/jira/browse/SSHD-708 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Goldstein Lyor >Priority: Minor > > The current code supports only reading un-encrypted private key files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-708) Add support for password encrypted OpenSSH private key files
[ https://issues.apache.org/jira/browse/SSHD-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16714999#comment-16714999 ] Thomas Wolf commented on SSHD-708: -- I see you assigned this to yourself. I have the code all written; but I'm waiting for the OK from the Eclipse legal team. At least for uses in Eclipse it'll only cause trouble if they should be unhappy about including the source directly. > Add support for password encrypted OpenSSH private key files > > > Key: SSHD-708 > URL: https://issues.apache.org/jira/browse/SSHD-708 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Goldstein Lyor >Assignee: Goldstein Lyor >Priority: Minor > > The current code supports only reading un-encrypted private key files -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SSHD-873) BuiltinCiphers.aes256cbc.getBlockSize() returns wrong value
Thomas Wolf created SSHD-873: Summary: BuiltinCiphers.aes256cbc.getBlockSize() returns wrong value Key: SSHD-873 URL: https://issues.apache.org/jira/browse/SSHD-873 Project: MINA SSHD Issue Type: Bug Affects Versions: 2.0.0 Reporter: Thomas Wolf As far as I know AES always has a block size of 16. BuiltinCiphers returns 32 for aes256, and 24 for aes192. That's not the block size, it's the key size in bytes. Maybe I misunderstand something? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-928) Support gss authentication for SshClient
[ https://issues.apache.org/jira/browse/SSHD-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870539#comment-16870539 ] Thomas Wolf commented on SSHD-928: -- There is an implementation of this in [JGit|https://github.com/eclipse/jgit/tree/master/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/internal/transport/sshd] (the three GssApi* classes). The only reason we didn't contribute this back is that it's *completely untested*. We (the Eclipse EGit/JGit developers) have no Kerberos setup with which we could test that. So it's entirely possible that this code still has bugs. So far we've not received any bug reports about it, so either we have no users who use this, or it simply works for anybody using it, or it doesn't but people didn't bother to report bugs. :-) > Support gss authentication for SshClient > > > Key: SSHD-928 > URL: https://issues.apache.org/jira/browse/SSHD-928 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.2.0 >Reporter: Zhenliang Su >Priority: Major > > Support gss authentication for SshClient. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-930) Send the client version string after receiving the version string of the server
[
https://issues.apache.org/jira/browse/SSHD-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16882719#comment-16882719
]
Thomas Wolf commented on SSHD-930:
--
{quote}
Great - I will merge it
{quote}
Please don't; I think this will break client-side proxy connections. See [my
comment on
GitHub|https://github.com/apache/mina-sshd/pull/105/files#diff-8aac7f4644244d3dde683a1ef954804dR93].
> Send the client version string after receiving the version string of the
> server
> ---
>
> Key: SSHD-930
> URL: https://issues.apache.org/jira/browse/SSHD-930
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The rfc4253 does not indicate whether the ssh client must send its own
> version number right after receiving the version number of the server.
> I have encountered a situation where mina-sshd is used to connect to cisco's
> sshd service, sometimes it can be connected, sometimes not connected.
> Some rules are found by capturing packets. If the client sends its own
> version number after receiving the version number of the server, it can be
> connected. If the client sends its own version number before receiving the
> version number of the server, then it will not be connected.
> I think, a better way is to change the SshClient code to send the version
> number of the client right after receiving the version number of the server.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-930) Send the client version string after receiving the version string of the server
[
https://issues.apache.org/jira/browse/SSHD-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883217#comment-16883217
]
Thomas Wolf commented on SSHD-930:
--
{quote}
can some kind of listener callback fix this issue ?
{quote}
The proxy protocol must be started in both cases (delayed client identification
or not) at the very beginning. The client has to first negotiate with the
_proxy_ the connection to the ssh server. Only once that request-reply protocol
(both SOCKS and HTTP CONNECT are request-reply) has terminated with a "success"
answer from the proxy the SSH protocol may start, be that the client sending
its id and then the server answering with its own, or vice versa.
Client-side proxy support is not ideal as it is, but I managed to shoehorn the
provided mechanisms into doing proper proxy connections in the JGit ssh client.
Perhaps the simplest might be to factor out the proxy initialization from
`sendClientIdentification()` and invoke it unconditionally in the constructor
before starting the SSH protocol.
> Send the client version string after receiving the version string of the
> server
> ---
>
> Key: SSHD-930
> URL: https://issues.apache.org/jira/browse/SSHD-930
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The rfc4253 does not indicate whether the ssh client must send its own
> version number right after receiving the version number of the server.
> I have encountered a situation where mina-sshd is used to connect to cisco's
> sshd service, sometimes it can be connected, sometimes not connected.
> Some rules are found by capturing packets. If the client sends its own
> version number after receiving the version number of the server, it can be
> connected. If the client sends its own version number before receiving the
> version number of the server, then it will not be connected.
> I think, a better way is to change the SshClient code to send the version
> number of the client right after receiving the version number of the server.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-930) Send the client version string after receiving the version string of the server
[ https://issues.apache.org/jira/browse/SSHD-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883638#comment-16883638 ] Thomas Wolf commented on SSHD-930: -- Finally, I'm not convinced sending the client's identification only once the server's banner has been received is really a good idea. First, OpenSSH doesn't do so; each side always sends its own identification first and then waits for the peer's; see [the OpenSSH sources|https://github.com/openssh/openssh-portable/blob/4d28fa7/kex.c#L1110]. Second, if the client waits first for the server, is there a timeout for this wait? If that Cisco device can be connected to with normal OpenSSH, then I guess the problem is not the order of these identifications at all. (Don't know where, though.) > Send the client version string after receiving the version string of the > server > --- > > Key: SSHD-930 > URL: https://issues.apache.org/jira/browse/SSHD-930 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.2.0 >Reporter: Zhenliang Su >Assignee: Goldstein Lyor >Priority: Major > Fix For: 2.3.1 > > Time Spent: 20m > Remaining Estimate: 0h > > The rfc4253 does not indicate whether the ssh client must send its own > version number right after receiving the version number of the server. > I have encountered a situation where mina-sshd is used to connect to cisco's > sshd service, sometimes it can be connected, sometimes not connected. > Some rules are found by capturing packets. If the client sends its own > version number after receiving the version number of the server, it can be > connected. If the client sends its own version number before receiving the > version number of the server, then it will not be connected. > I think, a better way is to change the SshClient code to send the version > number of the client right after receiving the version number of the server. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-930) Send the client version string after receiving the version string of the server
[
https://issues.apache.org/jira/browse/SSHD-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883907#comment-16883907
]
Thomas Wolf commented on SSHD-930:
--
More research: it appears that this changed in OpenSSH in version 6.2; see the
[release notes|https://www.openssh.com/txt/release-6.2], the corresponding
[discussion|https://bugzilla.mindrot.org/show_bug.cgi?id=1999] and
[commit|https://github.com/openssh/openssh-portable/commit/00c1518a4d]. That
was in 2012. Apparently reading the server's identification string first is SSH
v1. So maybe adding an option to do this might be worth the trouble after all
if one wants to use Apache MINA sshd to talk to old SSH servers. I notice that
{{sshj}} also has an option to first read the server's identification.
But the proxy protocol must still run earlier.
> Send the client version string after receiving the version string of the
> server
> ---
>
> Key: SSHD-930
> URL: https://issues.apache.org/jira/browse/SSHD-930
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The rfc4253 does not indicate whether the ssh client must send its own
> version number right after receiving the version number of the server.
> I have encountered a situation where mina-sshd is used to connect to cisco's
> sshd service, sometimes it can be connected, sometimes not connected.
> Some rules are found by capturing packets. If the client sends its own
> version number after receiving the version number of the server, it can be
> connected. If the client sends its own version number before receiving the
> version number of the server, then it will not be connected.
> I think, a better way is to change the SshClient code to send the version
> number of the client right after receiving the version number of the server.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-932) Mina client to connect remote Linux host and get few tasks done
[
https://issues.apache.org/jira/browse/SSHD-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885344#comment-16885344
]
Thomas Wolf commented on SSHD-932:
--
See [the
documentation|https://github.com/apache/mina-sshd/blob/master/docs/sftp.md].
Basically, one you have a {{ClientSession}}, use
{{SftpClientFactory.instance().createSftpClient()}} to create an
{{SftpClient}}, then use the operations provided there. Note that you'll have
to handle the "current directory" on the _client_ side; likewise any other
state. You'll need the sshd-sftp bundle, too.
Unclear what your question (2) means. Do you mean connecting with an SSH
public/private key pair (like {{~/.ssh/id_rsa}})? Yes, you can.
> Mina client to connect remote Linux host and get few tasks done
> ---
>
> Key: SSHD-932
> URL: https://issues.apache.org/jira/browse/SSHD-932
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.2.0
>Reporter: Zabee Ulla
>Priority: Major
>
> We are switching from Jsch to Apache MINA to connect and get a few tasks done
> from remote hosts.
> I need to achieve the following features,
> * List files of a remote host
> * Change directory of a remote host
> * Get file contents as bytes from a remote host
> * Put a file into the remote host
> I have the following questions,
> # How can I send a ZIP file to a remote host much easily in API level (not
> the Shell commands level)? And all other operations in API level.
> # Can I secure a connection between my localhost and remote through a
> certificate?
> # As of now, I am using SSHD-CORE and SSHD-COMMON version 2.2.0. Are these
> libraries enough or do I need to include any other libraries?
> # executeRemoteCommand() is stateless how can I maintain a state?
> Sorry, if the questions sound naive.
> Looking at this at an earlier opportunity will definitely help.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-932) Mina client to connect remote Linux host and get few tasks done
[
https://issues.apache.org/jira/browse/SSHD-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885344#comment-16885344
]
Thomas Wolf edited comment on SSHD-932 at 7/15/19 3:55 PM:
---
See [the
documentation|https://github.com/apache/mina-sshd/blob/master/docs/sftp.md].
Basically, once you have a {{ClientSession}}, use
{{SftpClientFactory.instance().createSftpClient()}} to create an
{{SftpClient}}, then use the operations provided there. Note that you'll have
to handle the "current directory" on the _client_ side; likewise any other
state. You'll need the sshd-sftp bundle, too.
Unclear what your question (2) means. Do you mean connecting with an SSH
public/private key pair (like {{~/.ssh/id_rsa}})? Yes, you can.
was (Author: wolft):
See [the
documentation|https://github.com/apache/mina-sshd/blob/master/docs/sftp.md].
Basically, one you have a {{ClientSession}}, use
{{SftpClientFactory.instance().createSftpClient()}} to create an
{{SftpClient}}, then use the operations provided there. Note that you'll have
to handle the "current directory" on the _client_ side; likewise any other
state. You'll need the sshd-sftp bundle, too.
Unclear what your question (2) means. Do you mean connecting with an SSH
public/private key pair (like {{~/.ssh/id_rsa}})? Yes, you can.
> Mina client to connect remote Linux host and get few tasks done
> ---
>
> Key: SSHD-932
> URL: https://issues.apache.org/jira/browse/SSHD-932
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.2.0
>Reporter: Zabee Ulla
>Priority: Major
>
> We are switching from Jsch to Apache MINA to connect and get a few tasks done
> from remote hosts.
> I need to achieve the following features,
> * List files of a remote host
> * Change directory of a remote host
> * Get file contents as bytes from a remote host
> * Put a file into the remote host
> I have the following questions,
> # How can I send a ZIP file to a remote host much easily in API level (not
> the Shell commands level)? And all other operations in API level.
> # Can I secure a connection between my localhost and remote through a
> certificate?
> # As of now, I am using SSHD-CORE and SSHD-COMMON version 2.2.0. Are these
> libraries enough or do I need to include any other libraries?
> # executeRemoteCommand() is stateless how can I maintain a state?
> Sorry, if the questions sound naive.
> Looking at this at an earlier opportunity will definitely help.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-941) mina ssh client times out connecting with IOS 15.2
[
https://issues.apache.org/jira/browse/SSHD-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935309#comment-16935309
]
Thomas Wolf commented on SSHD-941:
--
{quote}what does {{SSH_BUG_DHGEX_LARGE}} control ?{quote}
See commit
[b282fec1aa05246ed3482270eb70fc3ec5f39a00|https://github.com/openssh/openssh-portable/commit/b282fec1aa05246ed3482270eb70fc3ec5f39a00]
in OpenSSH-portable.
> mina ssh client times out connecting with IOS 15.2
> --
>
> Key: SSHD-941
> URL: https://issues.apache.org/jira/browse/SSHD-941
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Yuefeng
>Priority: Major
>
> Other device is Cisco IOS 15.2 -
> IOS-15#show version
> Cisco IOS Software, Linux Software (I86BI_LINUXL2-ADVENTERPRISEK9-M), Version
> 15.2(CML_NIGHTLY_20180510)FLO_DSGS7, EARLY DEPLOYMENT DEVELOPMENT BUILD,
> synced to V152_6_0_81_E
>
> apache.sshd always times out connecting to this device -
>
> {code:java}
> 2019-09-12 20:42:30.559Z [sshd-SshClient[4ae0d26a]-nio2-thread-15] DEBUG
> o.a.s.c.session.ClientSessionImpl:68 - Client session created:
> Nio2Session[local=/10.10.20.1:41950, remote=/10.10.20.25:22]
> 2019-09-12 20:42:30.559Z [sshd-SshClient[4ae0d26a]-nio2-thread-15] DEBUG
> o.a.s.c.s.ClientUserAuthService:101 -
> ClientUserAuthService(ClientSessionImpl[null@/10.10.20.25:22]) client
> methods: [publickey, keyboard-interactive, password]
> 2019-09-12 20:42:30.559Z [sshd-SshClient[4ae0d26a]-nio2-thread-15] DEBUG
> o.a.s.c.session.ClientSessionImpl:1569 -
> sendIdentification(ClientSessionImpl[null@/10.10.20.25:22]):
> SSH-2.0-SSHD-CORE-2.0.0
> 2019-09-12 20:42:30.560Z [sshd-SshClient[4ae0d26a]-nio2-thread-15] DEBUG
> o.a.s.c.session.ClientSessionImpl:1716 -
> sendKexInit(ClientSessionImpl[null@/10.10.20.25:22]) Send SSH_MSG_KEXINIT
> 2019-09-12 20:42:30.560Z [collector-55326-2] DEBUG
> o.a.s.c.s.ClientUserAuthService:150 -
> auth(ClientSessionImpl[admin@/10.10.20.25:22])[ssh-connection] send
> SSH_MSG_USERAUTH_REQUEST for 'none'
> 2019-09-12 20:42:30.564Z [collector-55326-2] DEBUG
> o.a.s.c.session.ClientSessionImpl:1110 -
> writePacket(ClientSessionImpl[admin@/10.10.20.25:22])[SSH_MSG_USERAUTH_REQUEST]
> Start flagging packets as pending until key exchange is done
> 2019-09-12 20:42:30.612Z [sshd-SshClient[4ae0d26a]-nio2-thread-9] DEBUG
> o.a.s.c.session.ClientSessionImpl:1653 -
> doReadIdentification(ClientSessionImpl[admin@/10.10.20.25:22])
> line='SSH-2.0-Cisco-1.25'
> 2019-09-12 20:42:30.612Z [sshd-SshClient[4ae0d26a]-nio2-thread-9] DEBUG
> o.a.s.c.session.ClientSessionImpl:375 -
> readIdentification(ClientSessionImpl[admin@/10.10.20.25:22]) Server version
> string: SSH-2.0-Cisco-1.25
> 2019-09-12 20:42:50.565Z [collector-55326-2] WARN
> c.forwardnetworks.client.web.a.b.e:181 - SSH auth failed:
> DefaultAuthFuture[ssh-connection]: Failed to get operation result within
> specified timeout: 2
> org.apache.sshd.common.SshException: DefaultAuthFuture[ssh-connection]:
> Failed to get operation result within specified timeout: 2
> {code}
>
> ssh on linux has no problem connecting -
> {code:java}
> root@eve-ng:/opt/fwd/logs# ssh - admin@10.10.20.25
> OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug2: resolving "10.10.20.25" port 22
> debug2: ssh_connect_direct: needpriv 0
> debug1: Connecting to 10.10.20.25 [10.10.20.25] port 22.
> debug1: Connection established.
> debug1: permanently_set_uid: 0/0
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_rsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_ed25519-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
> debug1: Remote protocol version 2.0, remote software version Cisco-1.25
> debug1: match: Cisco-1.25 pat Cisco-1.* compat 0x6000
> debug2: fd 3 setting O_NONBLOCK
> debug1: Authenticating to 10.10.20.25:22 as 'admin'
> debug3: hostkeys_foreach: reading
[jira] [Comment Edited] (SSHD-941) mina ssh client times out connecting with IOS 15.2
[
https://issues.apache.org/jira/browse/SSHD-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935309#comment-16935309
]
Thomas Wolf edited comment on SSHD-941 at 9/22/19 2:00 PM:
---
{quote}what does {{SSH_BUG_DHGEX_LARGE}} control ?
{quote}
See commit
[b282fec1aa05246ed3482270eb70fc3ec5f39a00|https://github.com/openssh/openssh-portable/commit/b282fec1aa05246ed3482270eb70fc3ec5f39a00]
in OpenSSH-portable.
More info including a ssh config work-around in the corresponding OpenSSH [bug
2209|https://bugzilla.mindrot.org/show_bug.cgi?id=2209].
was (Author: wolft):
{quote}what does {{SSH_BUG_DHGEX_LARGE}} control ?{quote}
See commit
[b282fec1aa05246ed3482270eb70fc3ec5f39a00|https://github.com/openssh/openssh-portable/commit/b282fec1aa05246ed3482270eb70fc3ec5f39a00]
in OpenSSH-portable.
> mina ssh client times out connecting with IOS 15.2
> --
>
> Key: SSHD-941
> URL: https://issues.apache.org/jira/browse/SSHD-941
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Yuefeng
>Priority: Major
>
> Other device is Cisco IOS 15.2 -
> IOS-15#show version
> Cisco IOS Software, Linux Software (I86BI_LINUXL2-ADVENTERPRISEK9-M), Version
> 15.2(CML_NIGHTLY_20180510)FLO_DSGS7, EARLY DEPLOYMENT DEVELOPMENT BUILD,
> synced to V152_6_0_81_E
>
> apache.sshd always times out connecting to this device -
>
> {code:java}
> 2019-09-12 20:42:30.559Z [sshd-SshClient[4ae0d26a]-nio2-thread-15] DEBUG
> o.a.s.c.session.ClientSessionImpl:68 - Client session created:
> Nio2Session[local=/10.10.20.1:41950, remote=/10.10.20.25:22]
> 2019-09-12 20:42:30.559Z [sshd-SshClient[4ae0d26a]-nio2-thread-15] DEBUG
> o.a.s.c.s.ClientUserAuthService:101 -
> ClientUserAuthService(ClientSessionImpl[null@/10.10.20.25:22]) client
> methods: [publickey, keyboard-interactive, password]
> 2019-09-12 20:42:30.559Z [sshd-SshClient[4ae0d26a]-nio2-thread-15] DEBUG
> o.a.s.c.session.ClientSessionImpl:1569 -
> sendIdentification(ClientSessionImpl[null@/10.10.20.25:22]):
> SSH-2.0-SSHD-CORE-2.0.0
> 2019-09-12 20:42:30.560Z [sshd-SshClient[4ae0d26a]-nio2-thread-15] DEBUG
> o.a.s.c.session.ClientSessionImpl:1716 -
> sendKexInit(ClientSessionImpl[null@/10.10.20.25:22]) Send SSH_MSG_KEXINIT
> 2019-09-12 20:42:30.560Z [collector-55326-2] DEBUG
> o.a.s.c.s.ClientUserAuthService:150 -
> auth(ClientSessionImpl[admin@/10.10.20.25:22])[ssh-connection] send
> SSH_MSG_USERAUTH_REQUEST for 'none'
> 2019-09-12 20:42:30.564Z [collector-55326-2] DEBUG
> o.a.s.c.session.ClientSessionImpl:1110 -
> writePacket(ClientSessionImpl[admin@/10.10.20.25:22])[SSH_MSG_USERAUTH_REQUEST]
> Start flagging packets as pending until key exchange is done
> 2019-09-12 20:42:30.612Z [sshd-SshClient[4ae0d26a]-nio2-thread-9] DEBUG
> o.a.s.c.session.ClientSessionImpl:1653 -
> doReadIdentification(ClientSessionImpl[admin@/10.10.20.25:22])
> line='SSH-2.0-Cisco-1.25'
> 2019-09-12 20:42:30.612Z [sshd-SshClient[4ae0d26a]-nio2-thread-9] DEBUG
> o.a.s.c.session.ClientSessionImpl:375 -
> readIdentification(ClientSessionImpl[admin@/10.10.20.25:22]) Server version
> string: SSH-2.0-Cisco-1.25
> 2019-09-12 20:42:50.565Z [collector-55326-2] WARN
> c.forwardnetworks.client.web.a.b.e:181 - SSH auth failed:
> DefaultAuthFuture[ssh-connection]: Failed to get operation result within
> specified timeout: 2
> org.apache.sshd.common.SshException: DefaultAuthFuture[ssh-connection]:
> Failed to get operation result within specified timeout: 2
> {code}
>
> ssh on linux has no problem connecting -
> {code:java}
> root@eve-ng:/opt/fwd/logs# ssh - admin@10.10.20.25
> OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug2: resolving "10.10.20.25" port 22
> debug2: ssh_connect_direct: needpriv 0
> debug1: Connecting to 10.10.20.25 [10.10.20.25] port 22.
> debug1: Connection established.
> debug1: permanently_set_uid: 0/0
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_rsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /root/.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
>
[jira] [Commented] (SSHD-945) DSA 2048 public key authentication fails
[
https://issues.apache.org/jira/browse/SSHD-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942207#comment-16942207
]
Thomas Wolf commented on SSHD-945:
--
The JCE (Java Cryptographic Extension) is not needed on anymore on modern
OpenJDK/Oracle JVMs. Which is pointed out at the link Christoph gave.
I found
[https://security.stackexchange.com/questions/112802/why-openssh-deprecated-dsa-keys]
interesting, and especially Darren's answer there, which points to
[https://bugzilla.mindrot.org/show_bug.cgi?id=1647] .
Does OpenSSH client (and server) actually work with DSA 2048 keys, as claimed
by some?
> DSA 2048 public key authentication fails
>
>
> Key: SSHD-945
> URL: https://issues.apache.org/jira/browse/SSHD-945
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Logan
>Priority: Major
> Attachments: DSAKeyTests.java
>
>
> While RSA 1024, 2048 and DSA 1024 keys succeed, DSA 2048 fails with error
> trace listed below. I am trying to figure out if the issue is related to DSA
> keys generated by JDK or apache SSHD. Attached is the test case.
>
> Tests with JSch API also fail with DSA 2048 keys.
>
> Error trace:
> {code:java}
> org.apache.sshd.common.SshException: No more authentication methods
> availableorg.apache.sshd.common.SshException: No more authentication methods
> available at
> org.apache.sshd.client.session.ClientUserAuthService.tryNext(ClientUserAuthService.java:318)
> at
> org.apache.sshd.client.session.ClientUserAuthService.processUserAuth(ClientUserAuthService.java:254)
> at
> org.apache.sshd.client.session.ClientUserAuthService.process(ClientUserAuthService.java:201)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:626)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:559)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1542)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:520)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:63)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:339)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:318)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:315)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at java.security.AccessController.doPrivileged(Native Method) at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker$2.run(Invoker.java:218) at
> sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
> [^DSAKeyTests.java]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-945) DSA 2048 public key authentication fails
[
https://issues.apache.org/jira/browse/SSHD-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943402#comment-16943402
]
Thomas Wolf edited comment on SSHD-945 at 10/3/19 9:45 AM:
---
{quote}org.apache.sshd.common.SshException: DefaultAuthFuture[ssh-connection]:
Failed (InvalidKeyException) to execute: The security strength of SHA-1 digest
algorithm is not sufficient for this key
{quote}
is exactly the problem pointed out in
[https://bugzilla.mindrot.org/show_bug.cgi?id=1647:] SHA-1 is 160 bits and is
mandated by RFC 4253, but for a DSA2048 key one would need a longer signature
hash (224 or 256bits).
Interestingly enough, OpenSSH does work with such keys (if DSA is enabled at
all in client and server), and uses SHA256 (client log; OS X, OpenSSH_7.4p1,
LibreSSL 2.5.0):
{code:java}
...
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /Users/thomas/.ssh/id_dsa_2048
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-dss blen 818
debug2: input_userauth_pk_ok: fp
SHA256:usOY30m0OcvF44d+OK0TezJ9xfOoY0c6Fn1lzA+gQ6M
debug3: sign_and_send_pubkey: DSA
SHA256:usOY30m0OcvF44d+OK0TezJ9xfOoY0c6Fn1lzA+gQ6M
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
...
{code}
See [https://zonena.me/2014/02/using-2048-bit-dsa-keys-with-openssh/] for how
to create a DSA 2048 bit key, and DSA must be enabled in both openSSH client
and server ({{PubkeyAcceptedKeyTypes=+ssh-dss}} in the config files).
was (Author: wolft):
{quote}
org.apache.sshd.common.SshException: DefaultAuthFuture[ssh-connection]: Failed
(InvalidKeyException) to execute: The security strength of SHA-1 digest
algorithm is not sufficient for this key
{quote}
is exactly the problem pointed out in
https://bugzilla.mindrot.org/show_bug.cgi?id=1647: SHA-1 is 160 bits and is
mandated by RFC 4253, but for a DSA2048 key one would need a longer hash (224
or 256bits).
Interestingly enough, OpenSSH does work with such keys (if DSA is enabled at
all in client and server), and uses SHA256 (client log; OS X, OpenSSH_7.4p1,
LibreSSL 2.5.0):
{code}
...
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /Users/thomas/.ssh/id_dsa_2048
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-dss blen 818
debug2: input_userauth_pk_ok: fp
SHA256:usOY30m0OcvF44d+OK0TezJ9xfOoY0c6Fn1lzA+gQ6M
debug3: sign_and_send_pubkey: DSA
SHA256:usOY30m0OcvF44d+OK0TezJ9xfOoY0c6Fn1lzA+gQ6M
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
...
{code}
See https://zonena.me/2014/02/using-2048-bit-dsa-keys-with-openssh/ for how to
create a DSA 2048 bit key, and DSA must be enabled in both openSSH client and
server ({{PubkeyAcceptedKeyTypes=+ssh-dss}} in the config files).
> DSA 2048 public key authentication fails
>
>
> Key: SSHD-945
> URL: https://issues.apache.org/jira/browse/SSHD-945
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Logan
>Priority: Major
> Attachments: DSAKeyTests.java
>
>
> While RSA 1024, 2048 and DSA 1024 keys succeed, DSA 2048 fails with error
> trace listed below. I am trying to figure out if the issue is related to DSA
> keys generated by JDK or apache SSHD. Attached is the test case.
>
> Tests with JSch API also fail with DSA 2048 keys.
>
> Error trace:
> {code:java}
> org.apache.sshd.common.SshException: No more authentication methods
> availableorg.apache.sshd.common.SshException: No more authentication methods
> available at
> org.apache.sshd.client.session.ClientUserAuthService.tryNext(ClientUserAuthService.java:318)
> at
> org.apache.sshd.client.session.ClientUserAuthService.processUserAuth(ClientUserAuthService.java:254)
> at
> org.apache.sshd.client.session.ClientUserAuthService.process(ClientUserAuthService.java:201)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:626)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:559)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1542)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:520)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:63)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:339)
> at
>
[jira] [Commented] (SSHD-945) DSA 2048 public key authentication fails
[
https://issues.apache.org/jira/browse/SSHD-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943455#comment-16943455
]
Thomas Wolf commented on SSHD-945:
--
Sorry, I mis-interpreted that bit:
{quote}
{code:java}
debug2: input_userauth_pk_ok: fp
SHA256:usOY30m0OcvF44d+OK0TezJ9xfOoY0c6Fn1lzA+gQ6M
debug3: sign_and_send_pubkey: DSA
SHA256:usOY30m0OcvF44d+OK0TezJ9xfOoY0c6Fn1lzA+gQ6M
{code}
{quote}
This SHA256 is just the hash of the DSA key.
Running the test again with server-side logging and then looking at the code of
OpenSSH, it looks as if OpenSSH actually uses the DSA 2048 key but with a
160bit SHA1 signature hash. The server goes through
*
[userauth_pubkey|https://github.com/openssh/openssh-portable/blob/be02d7c/auth2-pubkey.c#L213]
*
[sshkey_verify|https://github.com/openssh/openssh-portable/blob/be02d7c/sshkey.c#L2662]
*
[ssh_dss_verify|https://github.com/openssh/openssh-portable/blob/be02d7c/ssh-dss.c#L120]
where SHA1 and 160bits are hardcoded.
So it uses something it shouldn't use at all.
sshd is in fact correct to complain that "the security strength of SHA-1 digest
algorithm is not sufficient for this key".
> DSA 2048 public key authentication fails
>
>
> Key: SSHD-945
> URL: https://issues.apache.org/jira/browse/SSHD-945
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Logan
>Priority: Major
> Attachments: DSAKeyTests.java
>
>
> While RSA 1024, 2048 and DSA 1024 keys succeed, DSA 2048 fails with error
> trace listed below. I am trying to figure out if the issue is related to DSA
> keys generated by JDK or apache SSHD. Attached is the test case.
>
> Tests with JSch API also fail with DSA 2048 keys.
>
> Error trace:
> {code:java}
> org.apache.sshd.common.SshException: No more authentication methods
> availableorg.apache.sshd.common.SshException: No more authentication methods
> available at
> org.apache.sshd.client.session.ClientUserAuthService.tryNext(ClientUserAuthService.java:318)
> at
> org.apache.sshd.client.session.ClientUserAuthService.processUserAuth(ClientUserAuthService.java:254)
> at
> org.apache.sshd.client.session.ClientUserAuthService.process(ClientUserAuthService.java:201)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:626)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:559)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1542)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:520)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:63)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:339)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:318)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:315)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at java.security.AccessController.doPrivileged(Native Method) at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker$2.run(Invoker.java:218) at
> sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
> [^DSAKeyTests.java]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-945) DSA 2048 public key authentication fails
[
https://issues.apache.org/jira/browse/SSHD-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945367#comment-16945367
]
Thomas Wolf commented on SSHD-945:
--
The problem is not the key per se. OpenSSH client and server even work with a
DSA2048 key, but they still use a 160bit SHA1 signature hash, which is an
insecure setup. The signature hash should be 224 or 256 bits for such keys. If
a client uses a different signature hash, it'll violate RFC 4253 and it's
unlikely that this would work with an OpenSSH server.
> DSA 2048 public key authentication fails
>
>
> Key: SSHD-945
> URL: https://issues.apache.org/jira/browse/SSHD-945
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Logan
>Priority: Major
> Attachments: DSAKeyTests.java, maverick_id_dsa
>
>
> While RSA 1024, 2048 and DSA 1024 keys succeed, DSA 2048 fails with error
> trace listed below. I am trying to figure out if the issue is related to DSA
> keys generated by JDK or apache SSHD. Attached is the test case.
>
> Tests with JSch API also fail with DSA 2048 keys.
>
> Error trace:
> {code:java}
> org.apache.sshd.common.SshException: No more authentication methods
> availableorg.apache.sshd.common.SshException: No more authentication methods
> available at
> org.apache.sshd.client.session.ClientUserAuthService.tryNext(ClientUserAuthService.java:318)
> at
> org.apache.sshd.client.session.ClientUserAuthService.processUserAuth(ClientUserAuthService.java:254)
> at
> org.apache.sshd.client.session.ClientUserAuthService.process(ClientUserAuthService.java:201)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:626)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:559)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1542)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:520)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:63)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:339)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:318)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:315)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at java.security.AccessController.doPrivileged(Native Method) at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker$2.run(Invoker.java:218) at
> sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
> [^DSAKeyTests.java]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-985) Support Bouncy Castle Ed25519 and Ed448 keys
Thomas Wolf created SSHD-985: Summary: Support Bouncy Castle Ed25519 and Ed448 keys Key: SSHD-985 URL: https://issues.apache.org/jira/browse/SSHD-985 Project: MINA SSHD Issue Type: New Feature Affects Versions: 2.4.0 Reporter: Thomas Wolf Bouncy Castle nowadays (at least since 1.64) also has an EDDSA provider. Sshd should be able to work with those keys, too, not just with the ones from net.i2p.crypto.eddsa. One notable difference is that net.i2p produces keys that return from Key.getAlgorithm() "EdDSA", while the Bouncy Castle keys return "Ed25519" or "Ed448", respectively. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-985) Support Bouncy Castle Ed25519 and Ed448 keys
[ https://issues.apache.org/jira/browse/SSHD-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094578#comment-17094578 ] Thomas Wolf commented on SSHD-985: -- It's an optional dependency already. Removing it would just mean that ed25519 wouldn't work anymore for someone using only that net.i2p library. I could imagine that there might be such users out there. If one needs only ed25519, net.i2p is much smaller than the full BouncyCastle. > Support Bouncy Castle Ed25519 and Ed448 keys > > > Key: SSHD-985 > URL: https://issues.apache.org/jira/browse/SSHD-985 > Project: MINA SSHD > Issue Type: New Feature >Affects Versions: 2.4.0 >Reporter: Thomas Wolf >Priority: Minor > > Bouncy Castle nowadays (at least since 1.64) also has an EDDSA provider. Sshd > should be able to work with those keys, too, not just with the ones from > net.i2p.crypto.eddsa. > One notable difference is that net.i2p produces keys that return from > Key.getAlgorithm() "EdDSA", while the Bouncy Castle keys return "Ed25519" or > "Ed448", respectively. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094589#comment-17094589
]
Thomas Wolf commented on SSHD-984:
--
Well, a PR would be much more work. AT least I'd have to give this prototype
code a home in the sshd source tree. Right now it's outside.
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-984:
-
Attachment: sshd_key_writing.zip
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
> Attachments: sshd_key_writing.zip
>
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094609#comment-17094609
]
Thomas Wolf commented on SSHD-984:
--
Attachment done. Enjoy!
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
> Attachments: sshd_key_writing.zip
>
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094577#comment-17094577
]
Thomas Wolf commented on SSHD-984:
--
Lyor, BouncyCastle is not needed for this, and AFAIK has no support for writing
the modern OpenSSH format anyway.
I have whipped up a fairly complete prototype including a minimal test for
doing this (both writing PKCS#8 PEM files and the modern OpenSSH files with
bcrypt KDF), but it's not in a state that it could be integrated easily into
sshd.
I could provide you that code; shall I attach a zip here?
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095461#comment-17095461
]
Thomas Wolf commented on SSHD-984:
--
I tried to extend that prototype for better PEM writing (including encryption),
but I think I don't quite understand how this should be done, or there are
things missing in sshd. For instance, I don't see where and how I'd specify
that I'd want to use PBKDF2WithHMAC-SHA1AndAES256-CBC for a
passphrase-protected key to be written as a PKCS#8 PEM. So the PEM part of the
prototype is really only a very rough sketch, and perhaps writing encrypted
PEMs might indeed need Bouncy Castle.
The OpenSSH bcrypt format writing appears to work fine, though. (Tried only
with AES.)
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
> Attachments: sshd_key_writing.zip
>
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098473#comment-17098473
]
Thomas Wolf commented on SSHD-984:
--
All right, here's the PR for writing OpenSSH style key files:
https://github.com/apache/mina-sshd/pull/128
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
> Attachments: sshd_key_writing.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098493#comment-17098493
]
Thomas Wolf commented on SSHD-986:
--
For the ecdsa-256 test, kp.getPublic() has an ECCurve$Fp curve and a ECPoint$Fp
for G, while kp2.getPublic() has a SECP256R1Curve and a SECP256R1Point. The
curve specs are also different; kp.getPublic() has an ECNamedCurveSpec, while
kp2.getPublic() has an ECParameterSpec. The internal values appear to be the
same. The generated private key kp.getPrivate() also contains the public key,
while the read kp2.getPrivate doesn't.
Are there different equivalent X.509 encodings for an EC key? (Named vs.
unnamed, or some such?)
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-988) Replace net.ip artifact with Bouncycastle for EDDSA key support
[
https://issues.apache.org/jira/browse/SSHD-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098481#comment-17098481
]
Thomas Wolf commented on SSHD-988:
--
Would one have to use the BC OpenSSHPrivateKeyUtil? Is there no way to use
sshd's key decoding and then create a BC Ed25519 key from the data read?
BTW, while the OpenSSH format spec allows for more than one key, the OpenSSH
implementation doesn't.
As I mentioned on SSHD-985, replacing net.i2p by BC is perhaps not the best. I
think it'd be better to try to support both providers.
> Replace net.ip artifact with Bouncycastle for EDDSA key support
> ---
>
> Key: SSHD-988
> URL: https://issues.apache.org/jira/browse/SSHD-988
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.4.0
>Reporter: Lyor Goldstein
>Assignee: Lyor Goldstein
>Priority: Major
>
> As of version 1.6 _Bouncycastle_ seems to support EDDSA keys. By replacing
> {{net,ip}} module with it we decrease the amount of external dependencies
> libraries.
> An important part of this effort would be to ensure that we preserve the
> ability to read (and perhaps write) keys from files with the current formats
> already supported (PEM, _Putty_, _OpenSSH_, etc.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-986) Implement ECDSA public key recovery
Thomas Wolf created SSHD-986:
Summary: Implement ECDSA public key recovery
Key: SSHD-986
URL: https://issues.apache.org/jira/browse/SSHD-986
Project: MINA SSHD
Issue Type: New Feature
Affects Versions: 2.4.0
Reporter: Thomas Wolf
Attachments: ECRecoverTest.java
{{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
{{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but that
doesn't seem to be called at all) are not implemented for ECDSA keys.
EC public key recovery is a ECPoint scalar multiplication and can be done via
Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
code this might be one way to implement this.
Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key file
because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
Attached is small JUnit test showing how to compute the ECDSA public key from a
given ECDSA private key using Bouncy Castle.
According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
representation of a ECDSA private key SHOULD contain the public key, too, so if
it's present it might perhaps even be possible to avoid this scalar
multiplication altogether, but exploiting this might require some larger code
refactoring?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-987) AESPrivateKeyObfuscator generates wrong IV length
Thomas Wolf created SSHD-987:
Summary: AESPrivateKeyObfuscator generates wrong IV length
Key: SSHD-987
URL: https://issues.apache.org/jira/browse/SSHD-987
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.4.0
Reporter: Thomas Wolf
{{AESPrivateKeyObfuscator.generateInitializationVector()}} inherited from
{{AbstractPrivateKeyObfuscator}} produces IVs of length {{keyLength /
Byte.SIZE}}.
This works only for AES 128, but not for AES 192 or AES 256. The IV length for
AES is 16.
Compare also SSHD-873.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-707) Add support for writing OpenSSH ed25519 private keys to file
[ https://issues.apache.org/jira/browse/SSHD-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101801#comment-17101801 ] Thomas Wolf commented on SSHD-707: -- I think this was resolved with SSHD-984. > Add support for writing OpenSSH ed25519 private keys to file > > > Key: SSHD-707 > URL: https://issues.apache.org/jira/browse/SSHD-707 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Lyor Goldstein >Priority: Minor > > The current code knows how to read private keys from _OpenSSH_ formatted > private key files, and also contains some hooks for writing the data, > although more work is required - especially on generating the 64-octets hash > value. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101078#comment-17101078
]
Thomas Wolf commented on SSHD-986:
--
That's the "read public key from encoded private key data" solution. Looks OK.
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-997) Replace EdDSA-Java library with new ed25519-elisabeth implementation
[
https://issues.apache.org/jira/browse/SSHD-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112427#comment-17112427
]
Thomas Wolf commented on SSHD-997:
--
Pull request: https://github.com/apache/mina-sshd/pull/135
> Replace EdDSA-Java library with new ed25519-elisabeth implementation
>
>
> Key: SSHD-997
> URL: https://issues.apache.org/jira/browse/SSHD-997
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Recent addition to the SSHD library revealed issues with seed attribute in
> EdDSA-Java library:
> {code:java}
> +private boolean compare(KeyPair a, KeyPair b) {
> +if ("EDDSA".equals(data.algorithm)) {
> +// Bug in net.i2p.crypto.eddsa and in sshd? Both also compare the
> +// seed of the private key, but for a generated key, this is some
> +// random value, while it is all zeroes for a key read from a
> file.
> +return KeyUtils.compareKeys(a.getPublic(), b.getPublic())
> +&& Objects.equals(((EdDSAKey)
> a.getPrivate()).getParams(),
> +((EdDSAKey) b.getPrivate()).getParams());
> +}
> {code}
> The corresponding issue: [1] upstream pointing to the new library:
> [1] https://github.com/str4d/ed25519-java/issues/30#issuecomment-573389252
> [2] https://github.com/cryptography-cafe/ed25519-elisabeth
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-997) Replace EdDSA-Java library with new ed25519-elisabeth implementation
[
https://issues.apache.org/jira/browse/SSHD-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112365#comment-17112365
]
Thomas Wolf edited comment on SSHD-997 at 5/20/20, 3:44 PM:
I think I know why it is all zeroes for a key read from a file.
Check {{OpenSSHEd25519PrivateKeyEntryDecoder}}, lines 103ff:
{code:java}
byte[] sk = Arrays.copyOf(keypair, SK_SIZE);
EdDSAPrivateKey privateKey;
try {
// create the private key
EdDSAParameterSpec params =
EdDSANamedCurveTable.getByName(EdDSASecurityProviderUtils.CURVE_ED25519_SHA512);
privateKey = generatePrivateKey(new EdDSAPrivateKeySpec(sk,
params));
} finally {
// get rid of sensitive data a.s.a.p
Arrays.fill(sk, (byte) 0);
}
{code}
sshd clears the SK read from the file. But that SK is the same object as
{{privateKey.seed}}; it is _not_ copied during generatePrivateKey.
The key still works with sshd (I use ed25519 keys with sshd in JGit daily), but
this breaks round-tripping: reading a key from a file and writing it again
will produce a different file. (And of course it also breaks
{{KeyUtils.compareKeys()}}.)
The fix in sshd is to remove the {{try-finally}} and the {{Arrays.fill(sk,
(byte) 0);}}. A fix in i2p would be to make sure that the private key generated
from a spec does not reference any arrays passed in externally, but to copy the
data such that the key is the sole owner.
So this is actually not a "minor feature" but really a "bug".
was (Author: wolft):
I think I know why it is all zeroes for a key read from a file.
Check {{OpenSSHEd25519PrivateKeyEntryDecoder}}, lines 103ff:
{code:java}
byte[] sk = Arrays.copyOf(keypair, SK_SIZE);
EdDSAPrivateKey privateKey;
try {
// create the private key
EdDSAParameterSpec params =
EdDSANamedCurveTable.getByName(EdDSASecurityProviderUtils.CURVE_ED25519_SHA512);
privateKey = generatePrivateKey(new EdDSAPrivateKeySpec(sk,
params));
} finally {
// get rid of sensitive data a.s.a.p
Arrays.fill(sk, (byte) 0);
}
{code}
sshd clears the SK read from the file. But that SK is the same object as
{{privateKey.seed}}; it is _not_ copied during generatePrivateKey.
The key still works with sshd (I use ed25519 keys with sshd in JGit daily), but
this breaks round-tripping: reading a key from a file and writing it again
will produce a different file. (And of course it also breaks
{{KeyUtils.compareKeys()}}.)
The fix in sshd is to remove the {{try-finally}} and the {{Arrays.fill(sk,
(byte) 0);}}. A fix in i2p would be to make sure that the private key generated
from a spec does not reference any arrays passed in externally, but to copy the
data such that the key is the sole owner.
So this is actually not a "minor feature" but actually a "bug".
> Replace EdDSA-Java library with new ed25519-elisabeth implementation
>
>
> Key: SSHD-997
> URL: https://issues.apache.org/jira/browse/SSHD-997
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> Recent addition to the SSHD library revealed issues with seed attribute in
> EdDSA-Java library:
> {code:java}
> +private boolean compare(KeyPair a, KeyPair b) {
> +if ("EDDSA".equals(data.algorithm)) {
> +// Bug in net.i2p.crypto.eddsa and in sshd? Both also compare the
> +// seed of the private key, but for a generated key, this is some
> +// random value, while it is all zeroes for a key read from a
> file.
> +return KeyUtils.compareKeys(a.getPublic(), b.getPublic())
> +&& Objects.equals(((EdDSAKey)
> a.getPrivate()).getParams(),
> +((EdDSAKey) b.getPrivate()).getParams());
> +}
> {code}
> The corresponding issue: [1] upstream pointing to the new library:
> [1] https://github.com/str4d/ed25519-java/issues/30#issuecomment-573389252
> [2] https://github.com/cryptography-cafe/ed25519-elisabeth
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-997) Replace EdDSA-Java library with new ed25519-elisabeth implementation
[
https://issues.apache.org/jira/browse/SSHD-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112365#comment-17112365
]
Thomas Wolf commented on SSHD-997:
--
I think I know why it is all zeroes for a key read from a file.
Check {{OpenSSHEd25519PrivateKeyEntryDecoder}}, lines 103ff:
{code:java}
byte[] sk = Arrays.copyOf(keypair, SK_SIZE);
EdDSAPrivateKey privateKey;
try {
// create the private key
EdDSAParameterSpec params =
EdDSANamedCurveTable.getByName(EdDSASecurityProviderUtils.CURVE_ED25519_SHA512);
privateKey = generatePrivateKey(new EdDSAPrivateKeySpec(sk,
params));
} finally {
// get rid of sensitive data a.s.a.p
Arrays.fill(sk, (byte) 0);
}
{code}
sshd clears the SK read from the file. But that SK is the same object as
{{privateKey.seed}}; it is _not_ copied during generatePrivateKey.
The key still works with sshd (I use ed25519 keys with sshd in JGit daily), but
this breaks round-tripping: reading a key from a file and writing it again
will produce a different file. (And of course it also breaks
{{KeyUtils.compareKeys()}}.)
The fix in sshd is to remove the {{try-finally}} and the {{Arrays.fill(sk,
(byte) 0);}}. A fix in i2p would be to make sure that the private key generated
from a spec does not reference any arrays passed in externally, but to copy the
data such that the key is the sole owner.
So this is actually not a "minor feature" but actually a "bug".
> Replace EdDSA-Java library with new ed25519-elisabeth implementation
>
>
> Key: SSHD-997
> URL: https://issues.apache.org/jira/browse/SSHD-997
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> Recent addition to the SSHD library revealed issues with seed attribute in
> EdDSA-Java library:
> {code:java}
> +private boolean compare(KeyPair a, KeyPair b) {
> +if ("EDDSA".equals(data.algorithm)) {
> +// Bug in net.i2p.crypto.eddsa and in sshd? Both also compare the
> +// seed of the private key, but for a generated key, this is some
> +// random value, while it is all zeroes for a key read from a
> file.
> +return KeyUtils.compareKeys(a.getPublic(), b.getPublic())
> +&& Objects.equals(((EdDSAKey)
> a.getPrivate()).getParams(),
> +((EdDSAKey) b.getPrivate()).getParams());
> +}
> {code}
> The corresponding issue: [1] upstream pointing to the new library:
> [1] https://github.com/str4d/ed25519-java/issues/30#issuecomment-573389252
> [2] https://github.com/cryptography-cafe/ed25519-elisabeth
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1070) OutOfMemoryError when use port forwarding
[
https://issues.apache.org/jira/browse/SSHD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191465#comment-17191465
]
Thomas Wolf commented on SSHD-1070:
---
{quote}
1. Could this cause a deadlock?
{quote}
I think it should not, since a {{put()}} that succeeds then executes in the
same thread {{startWriting()}}, and {{startWriting()}} calls itself once a
buffered element has been written to process the rest of the queue. So
eventually there should be space again, and a pending {{put()}} should then
succeed.
What you describe, though, is exactly what happens in the SSHD-1069 case (all
threads only reading, no thread is writing), but since that problem already
existed before, it isn't caused by this change. I wonder if it happens because
the {{ChannelAsyncOutputStream}} delays the write until there'd be enough
window space; but if all threads are busy reading I don't see where a thread
would request a window adjust and eventually retrigger the pending write.
{quote}
2. The performance of asynchronous frameworks will be degraded...
{quote}
Perhaps. But the whole process here doesn't seem to be very asynchronous
anyway, with the same thread initiating the write. I didn't check in detail
what the {{ChannelAsyncOutputStream}} does ; I don't see it using different
threads for writing... I would expect different connections to use different
{{BufferedIoOutputStreams}} in any case. With a fixed thread pool for reading
and writing it seems to me that it is always possible that a fast connection is
slowed down by slower connections, or that a fast connection starves slower
ones.
Adding yet another queue like you suggest will just re-introduce the problem of
unbounded queues again, and then we can get OOMEs again.
But feel free to provide a better fix.
> OutOfMemoryError when use port forwarding
> -
>
> Key: SSHD-1070
> URL: https://issues.apache.org/jira/browse/SSHD-1070
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi [~gnodet], I found this commit implemented asynchronous port forwarding:
> [https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-33823b8546f71d77bb1d653358ecde70]
> However, when a large amount of data is returned from upstream application,
> it is possible to cause an OOM in SSHD.
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -L
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 120 -p 15678 -P 8 --reverse
> {code}
> *-R, --reverse run in reverse mode (server sends, client receives)*
> SSHD will receive a lot of data but will not be able to forward it in time.
> log when OOM:
> {code:java}
> 17:52:25.195 [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded17:52:25.195
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
>
[jira] [Comment Edited] (SSHD-1070) OutOfMemoryError when use port forwarding
[
https://issues.apache.org/jira/browse/SSHD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191375#comment-17191375
]
Thomas Wolf edited comment on SSHD-1070 at 9/6/20, 9:54 PM:
[PR #163|https://github.com/apache/mina-sshd/pull/163] implements this
throttling. Seems to work fine in my tests using Feng's iperf3 test with -P 1
or -P 2; with -P 8 I run into SSHD-1069. Also works fine with -P 8 if I apply
the work-around from 1069 and increase the number of NIO2 workers up front to
be >= 8.
was (Author: wolft):
[PR #163|https://github.com/apache/mina-sshd/pull/163] implements this
throttling. Seems to work fine in my tests using Feng's iperf3 test (with -P 1
or -P 2; with -P 8 I run into SSHD-1069).
> OutOfMemoryError when use port forwarding
> -
>
> Key: SSHD-1070
> URL: https://issues.apache.org/jira/browse/SSHD-1070
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi [~gnodet], I found this commit implemented asynchronous port forwarding:
> [https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-33823b8546f71d77bb1d653358ecde70]
> However, when a large amount of data is returned from upstream application,
> it is possible to cause an OOM in SSHD.
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -L
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 120 -p 15678 -P 8 --reverse
> {code}
> *-R, --reverse run in reverse mode (server sends, client receives)*
> SSHD will receive a lot of data but will not be able to forward it in time.
> log when OOM:
> {code:java}
> 17:52:25.195 [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded17:52:25.195
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doWriteCycle(Nio2Session.java:420)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startWriting(Nio2Session.java:404)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.finishWrite(Nio2Session.java:495)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleCompletedWriteCycle(Nio2Session.java:465)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:429)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:426)17:52:25.639
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-6] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33530, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
>
[jira] [Commented] (SSHD-1070) OutOfMemoryError when use port forwarding
[
https://issues.apache.org/jira/browse/SSHD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191369#comment-17191369
]
Thomas Wolf commented on SSHD-1070:
---
>From code inspection it looks like the queue in
>{{org.apache.sshd.common.channel.BufferedIoOutputStream}} should be a
>{{java.util.concurrent.LinkedBlockingQueue}} with a maximum capacity of a
>certain number of elements (say 10; maybe configurable?), and the
>{{BufferedIoOutputStream}} should use {{LinkedBlockingQueue.put()}} to enqueue
>the write futures. Unless I'm mistaken that would throttle reading from the
>fast producer to the speed of writing to the slower consumer?
> OutOfMemoryError when use port forwarding
> -
>
> Key: SSHD-1070
> URL: https://issues.apache.org/jira/browse/SSHD-1070
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
>
> Hi [~gnodet], I found this commit implemented asynchronous port forwarding:
> [https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-33823b8546f71d77bb1d653358ecde70]
> However, when a large amount of data is returned from upstream application,
> it is possible to cause an OOM in SSHD.
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -L
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 120 -p 15678 -P 8 --reverse
> {code}
> *-R, --reverse run in reverse mode (server sends, client receives)*
> SSHD will receive a lot of data but will not be able to forward it in time.
> log when OOM:
> {code:java}
> 17:52:25.195 [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded17:52:25.195
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doWriteCycle(Nio2Session.java:420)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startWriting(Nio2Session.java:404)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.finishWrite(Nio2Session.java:495)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleCompletedWriteCycle(Nio2Session.java:465)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:429)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:426)17:52:25.639
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-6] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33530, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at
[jira] [Commented] (SSHD-1070) OutOfMemoryError when use port forwarding
[
https://issues.apache.org/jira/browse/SSHD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191375#comment-17191375
]
Thomas Wolf commented on SSHD-1070:
---
[PR #163|https://github.com/apache/mina-sshd/pull/163] implements this
throttling. Seems to work fine in my tests using Feng's iperf3 test (with -P 1
or -P 2; with -P 8 I run into SSHD-1069).
> OutOfMemoryError when use port forwarding
> -
>
> Key: SSHD-1070
> URL: https://issues.apache.org/jira/browse/SSHD-1070
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi [~gnodet], I found this commit implemented asynchronous port forwarding:
> [https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-33823b8546f71d77bb1d653358ecde70]
> However, when a large amount of data is returned from upstream application,
> it is possible to cause an OOM in SSHD.
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -L
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 120 -p 15678 -P 8 --reverse
> {code}
> *-R, --reverse run in reverse mode (server sends, client receives)*
> SSHD will receive a lot of data but will not be able to forward it in time.
> log when OOM:
> {code:java}
> 17:52:25.195 [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded17:52:25.195
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doWriteCycle(Nio2Session.java:420)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startWriting(Nio2Session.java:404)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.finishWrite(Nio2Session.java:495)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleCompletedWriteCycle(Nio2Session.java:465)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:429)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:426)17:52:25.639
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-6] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33530, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at java.security.AccessController.doPrivileged(Native Method) at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
>
[jira] [Commented] (SSHD-1070) OutOfMemoryError when use port forwarding
[
https://issues.apache.org/jira/browse/SSHD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193695#comment-17193695
]
Thomas Wolf commented on SSHD-1070:
---
[~lgoldstein], I don't think this can be left to be configured by the user.
This is server-side. If someone implements a server, s/he cannot know how fast
the two ends will be, and what kind of throttling might needed. Which is why I
wrote on the PR I wouldn't know how to configure something like that. Perhaps
s/he could figure it out at run-time and implement some super-clever adaptive
scheme, but that probably means rewrite the whole forwarding mechanism.
> OutOfMemoryError when use port forwarding
> -
>
> Key: SSHD-1070
> URL: https://issues.apache.org/jira/browse/SSHD-1070
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hi [~gnodet], I found this commit implemented asynchronous port forwarding:
> [https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-33823b8546f71d77bb1d653358ecde70]
> However, when a large amount of data is returned from upstream application,
> it is possible to cause an OOM in SSHD.
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -L
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 120 -p 15678 -P 8 --reverse
> {code}
> *-R, --reverse run in reverse mode (server sends, client receives)*
> SSHD will receive a lot of data but will not be able to forward it in time.
> log when OOM:
> {code:java}
> 17:52:25.195 [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded17:52:25.195
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doWriteCycle(Nio2Session.java:420)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startWriting(Nio2Session.java:404)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.finishWrite(Nio2Session.java:495)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleCompletedWriteCycle(Nio2Session.java:465)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:429)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:426)17:52:25.639
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-6] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33530, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at
[jira] [Comment Edited] (SSHD-1070) OutOfMemoryError when use port forwarding
[
https://issues.apache.org/jira/browse/SSHD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192396#comment-17192396
]
Thomas Wolf edited comment on SSHD-1070 at 9/8/20, 6:44 PM:
That's rather nice. Indeed it works well. (y) It also seems to solve SSHD-1069?
was (Author: wolft):
That's rather nice. Indeed it works well. (y)
> OutOfMemoryError when use port forwarding
> -
>
> Key: SSHD-1070
> URL: https://issues.apache.org/jira/browse/SSHD-1070
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hi [~gnodet], I found this commit implemented asynchronous port forwarding:
> [https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-33823b8546f71d77bb1d653358ecde70]
> However, when a large amount of data is returned from upstream application,
> it is possible to cause an OOM in SSHD.
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -L
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 120 -p 15678 -P 8 --reverse
> {code}
> *-R, --reverse run in reverse mode (server sends, client receives)*
> SSHD will receive a lot of data but will not be able to forward it in time.
> log when OOM:
> {code:java}
> 17:52:25.195 [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded17:52:25.195
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doWriteCycle(Nio2Session.java:420)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startWriting(Nio2Session.java:404)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.finishWrite(Nio2Session.java:495)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleCompletedWriteCycle(Nio2Session.java:465)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:429)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:426)17:52:25.639
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-6] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33530, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at java.security.AccessController.doPrivileged(Native Method) at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
>
[jira] [Commented] (SSHD-1070) OutOfMemoryError when use port forwarding
[
https://issues.apache.org/jira/browse/SSHD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192396#comment-17192396
]
Thomas Wolf commented on SSHD-1070:
---
That's rather nice. Indeed it works well. (y)
> OutOfMemoryError when use port forwarding
> -
>
> Key: SSHD-1070
> URL: https://issues.apache.org/jira/browse/SSHD-1070
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hi [~gnodet], I found this commit implemented asynchronous port forwarding:
> [https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-33823b8546f71d77bb1d653358ecde70]
> However, when a large amount of data is returned from upstream application,
> it is possible to cause an OOM in SSHD.
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -L
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 120 -p 15678 -P 8 --reverse
> {code}
> *-R, --reverse run in reverse mode (server sends, client receives)*
> SSHD will receive a lot of data but will not be able to forward it in time.
> log when OOM:
> {code:java}
> 17:52:25.195 [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded17:52:25.195
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doWriteCycle(Nio2Session.java:420)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startWriting(Nio2Session.java:404)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.finishWrite(Nio2Session.java:495)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleCompletedWriteCycle(Nio2Session.java:465)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:429)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:426)17:52:25.639
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-6] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33530, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at java.security.AccessController.doPrivileged(Native Method) at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)17:52:26.045
>
[jira] [Commented] (SSHD-1069) SSHD stuck when parallel is greater than number of IO threads
[
https://issues.apache.org/jira/browse/SSHD-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191498#comment-17191498
]
Thomas Wolf commented on SSHD-1069:
---
Using a cached thread pool instead of the fixed thread pool provided by the
{{Nio2ServiceFactory}} resolves this. But is that the correct fix? I notice
that the {{MinaServiceFactory}} does use a cached thread pool, too.
> SSHD stuck when parallel is greater than number of IO threads
> -
>
> Key: SSHD-1069
> URL: https://issues.apache.org/jira/browse/SSHD-1069
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
>
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> // PropertyResolverUtils.updateProperty(sshd, FactoryManager.NIO_WORKERS,
> 32);
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -R
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 20 -p 15678 -P 16
> {code}
> -P, --parallel # number of parallel client streams to run
> The problem can be reliably reproduced when -P is greater than the number of
> IO threads (the default is CPU cores +1).
> The problem disappears by turning up the FactoryManager.NIO_WORKERS:
> {code:java}
> PropertyResolverUtils.updateProperty(sshd, FactoryManager.NIO_WORKERS, 32);
> {code}
> jstack when SSHD is stuck:
> {code:java}
> "sshd-SshServer[467aecef](port=12133)-nio2-thread-5" #16 daemon prio=5
> os_prio=0 tid=0x7f7c70010800 nid=0x181cb in Object.wait()
> [0x7f7cb950]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0005d058d5b0> (a
> org.apache.sshd.common.channel.Window)
> at
> org.apache.sshd.common.channel.Window.waitForCondition(Window.java:294)
> at org.apache.sshd.common.channel.Window.waitForSpace(Window.java:255)
> - locked <0x0005d058d5b0> (a
> org.apache.sshd.common.channel.Window)
> at
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:197)
> - locked <0x0005d058cf98> (a
> org.apache.sshd.common.channel.ChannelOutputStream)
> at
> org.apache.sshd.client.channel.ClientChannelPendingMessagesQueue.writeMessage(ClientChannelPendingMessagesQueue.java:175)
> at
> org.apache.sshd.client.channel.ClientChannelPendingMessagesQueue.handleIncomingMessage(ClientChannelPendingMessagesQueue.java:150)
> - locked <0x0005d058d098> (a java.util.LinkedList)
> at
> org.apache.sshd.common.forward.DefaultForwardingFilter$StaticIoHandler.messageReceived(DefaultForwardingFilter.java:1151)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:356)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:334)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:331)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$35/1285889028.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
> at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157)
> at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implRead(UnixAsynchronousSocketChannelImpl.java:553)
> at
>
[jira] [Commented] (SSHD-1069) SSHD stuck when parallel is greater than number of IO threads
[
https://issues.apache.org/jira/browse/SSHD-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17191476#comment-17191476
]
Thomas Wolf commented on SSHD-1069:
---
Are _all_ NIO threads blocked on {{waitForSpace()}}? If so, it looks like the
readers starve writers. Which thread would eventually request the window adjust?
> SSHD stuck when parallel is greater than number of IO threads
> -
>
> Key: SSHD-1069
> URL: https://issues.apache.org/jira/browse/SSHD-1069
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
>
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> // PropertyResolverUtils.updateProperty(sshd, FactoryManager.NIO_WORKERS,
> 32);
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -R
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 20 -p 15678 -P 16
> {code}
> -P, --parallel # number of parallel client streams to run
> The problem can be reliably reproduced when -P is greater than the number of
> IO threads (the default is CPU cores +1).
> The problem disappears by turning up the FactoryManager.NIO_WORKERS:
> {code:java}
> PropertyResolverUtils.updateProperty(sshd, FactoryManager.NIO_WORKERS, 32);
> {code}
> jstack when SSHD is stuck:
> {code:java}
> "sshd-SshServer[467aecef](port=12133)-nio2-thread-5" #16 daemon prio=5
> os_prio=0 tid=0x7f7c70010800 nid=0x181cb in Object.wait()
> [0x7f7cb950]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0005d058d5b0> (a
> org.apache.sshd.common.channel.Window)
> at
> org.apache.sshd.common.channel.Window.waitForCondition(Window.java:294)
> at org.apache.sshd.common.channel.Window.waitForSpace(Window.java:255)
> - locked <0x0005d058d5b0> (a
> org.apache.sshd.common.channel.Window)
> at
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:197)
> - locked <0x0005d058cf98> (a
> org.apache.sshd.common.channel.ChannelOutputStream)
> at
> org.apache.sshd.client.channel.ClientChannelPendingMessagesQueue.writeMessage(ClientChannelPendingMessagesQueue.java:175)
> at
> org.apache.sshd.client.channel.ClientChannelPendingMessagesQueue.handleIncomingMessage(ClientChannelPendingMessagesQueue.java:150)
> - locked <0x0005d058d098> (a java.util.LinkedList)
> at
> org.apache.sshd.common.forward.DefaultForwardingFilter$StaticIoHandler.messageReceived(DefaultForwardingFilter.java:1151)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:356)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:334)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:331)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$35/1285889028.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
> at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157)
> at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implRead(UnixAsynchronousSocketChannelImpl.java:553)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.read(AsynchronousSocketChannelImpl.java:276)
> at
>
[jira] [Commented] (SSHD-1079) Async mode on the local port forwarder
[ https://issues.apache.org/jira/browse/SSHD-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196296#comment-17196296 ] Thomas Wolf commented on SSHD-1079: --- Can you still reproduce SSHD-1069 with [PR-166|https://github.com/apache/mina-sshd/pull/166] applied? I can't. > Async mode on the local port forwarder > -- > > Key: SSHD-1079 > URL: https://issues.apache.org/jira/browse/SSHD-1079 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Feng Jiajie >Priority: Major > > Avoiding SSHD-1069 deadlock problems with async mode. > [~gnodet] has provided a patch to implement this feature in the SSHD-1070 > comments. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-1076) Make creation of the AuthFuture in ClientUserAuthService configurable/overrideable
Thomas Wolf created SSHD-1076:
-
Summary: Make creation of the AuthFuture in ClientUserAuthService
configurable/overrideable
Key: SSHD-1076
URL: https://issues.apache.org/jira/browse/SSHD-1076
Project: MINA SSHD
Issue Type: New Feature
Affects Versions: 2.5.1
Reporter: Thomas Wolf
I have a need to have my own {{AuthFuture}} implementation. With the current
implementation, the authentication timeout keeps running even while the client
is asking the user for input, such as for a passphrase for an encrypted private
key. If the user doesn't supply the information quickly enough, the session
gets closed behind his back when the timeout expires.
So I need an {{AuthFuture}} that I can _pause_ while my client program is
requesting user input. I do have that actually, but currently I need to
subclass {{ClientUserAuthService}} (because
{{AbstractClientSession.getUserAuthService()}} has it as return type) _and_
copy all its code because the creation of the {{AuthFuture}} is hard-coded as
{{new DefaultAuthFuture(...)}} in {{ClientUserAuthService.auth()}}.
Factoring this out into a separate method {{protected AuthFuture
createAuthFuture(String serviceName, Object lock)}} would be one way (then I
could override without having to copy all the code), but maybe there is a
better way, such as a separately configurable AuthFutureFactory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-1076) Make creation of the AuthFuture in ClientUserAuthService configurable/overrideable
[
https://issues.apache.org/jira/browse/SSHD-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf closed SSHD-1076.
-
Resolution: Invalid
> Make creation of the AuthFuture in ClientUserAuthService
> configurable/overrideable
> --
>
> Key: SSHD-1076
> URL: https://issues.apache.org/jira/browse/SSHD-1076
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.5.1
>Reporter: Thomas Wolf
>Priority: Major
>
> I have a need to have my own {{AuthFuture}} implementation. With the current
> implementation, the authentication timeout keeps running even while the
> client is asking the user for input, such as for a passphrase for an
> encrypted private key. If the user doesn't supply the information quickly
> enough, the session gets closed behind his back when the timeout expires.
> So I need an {{AuthFuture}} that I can _pause_ while my client program is
> requesting user input. I do have that actually, but currently I need to
> subclass {{ClientUserAuthService}} (because
> {{AbstractClientSession.getUserAuthService()}} has it as return type) _and_
> copy all its code because the creation of the {{AuthFuture}} is hard-coded as
> {{new DefaultAuthFuture(...)}} in {{ClientUserAuthService.auth()}}.
> Factoring this out into a separate method {{protected AuthFuture
> createAuthFuture(String serviceName, Object lock)}} would be one way (then I
> could override without having to copy all the code), but maybe there is a
> better way, such as a separately configurable AuthFutureFactory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1076) Make creation of the AuthFuture in ClientUserAuthService configurable/overrideable
[
https://issues.apache.org/jira/browse/SSHD-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195064#comment-17195064
]
Thomas Wolf commented on SSHD-1076:
---
Forget it. There's no way to send heartbeats during the authentication; that
comes only later. Even if some heartbeats were sent at protocol level, an
OpenSSH server wouldn't make them extend the LoginGraceTime – that sets a
global limit (by default 120 seconds), and if auth hasn't succeeded by then,
the connection is closed no matter what.
So it's not worth trying to handle a user distracted by a phone call or some
such. If he didn't enter the password within the default timeout, he'll just
get an exception.
Guess my need to have my own AuthFuture has just gone away.
> Make creation of the AuthFuture in ClientUserAuthService
> configurable/overrideable
> --
>
> Key: SSHD-1076
> URL: https://issues.apache.org/jira/browse/SSHD-1076
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.5.1
>Reporter: Thomas Wolf
>Priority: Major
>
> I have a need to have my own {{AuthFuture}} implementation. With the current
> implementation, the authentication timeout keeps running even while the
> client is asking the user for input, such as for a passphrase for an
> encrypted private key. If the user doesn't supply the information quickly
> enough, the session gets closed behind his back when the timeout expires.
> So I need an {{AuthFuture}} that I can _pause_ while my client program is
> requesting user input. I do have that actually, but currently I need to
> subclass {{ClientUserAuthService}} (because
> {{AbstractClientSession.getUserAuthService()}} has it as return type) _and_
> copy all its code because the creation of the {{AuthFuture}} is hard-coded as
> {{new DefaultAuthFuture(...)}} in {{ClientUserAuthService.auth()}}.
> Factoring this out into a separate method {{protected AuthFuture
> createAuthFuture(String serviceName, Object lock)}} would be one way (then I
> could override without having to copy all the code), but maybe there is a
> better way, such as a separately configurable AuthFutureFactory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1070) OutOfMemoryError when use port forwarding
[
https://issues.apache.org/jira/browse/SSHD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192639#comment-17192639
]
Thomas Wolf commented on SSHD-1070:
---
{quote}
I think your implementation PR #163 has the minimal overall impact and is more
suitable for a quick fix to the problem.
{quote}
I'm not sure. I actually closed/abandoned that PR after having tried your
change. I did observe that with my change, I consistently did run into into
SSHD-1069 with the iperf3 test you suggested here (with -P 8; my machine has 4
cores and thus 5 NIO threads), but with yours, it just worked fine even with -P
8, and the throughputs for -P 1 and -P 2 were identical for both approaches.
Also, if I understand your change right, it is specific for the forwarding
case, whereas mine has the risk of affecting other uses of the
{{BufferedIoOutputstream}}. But forwarding should be the only scenario where a
server would encounter such speed differences between the two ends. (Or are
there other cases?) So probably your approach is less risky.
> OutOfMemoryError when use port forwarding
> -
>
> Key: SSHD-1070
> URL: https://issues.apache.org/jira/browse/SSHD-1070
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hi [~gnodet], I found this commit implemented asynchronous port forwarding:
> [https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-33823b8546f71d77bb1d653358ecde70]
> However, when a large amount of data is returned from upstream application,
> it is possible to cause an OOM in SSHD.
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -L
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 120 -p 15678 -P 8 --reverse
> {code}
> *-R, --reverse run in reverse mode (server sends, client receives)*
> SSHD will receive a lot of data but will not be able to forward it in time.
> log when OOM:
> {code:java}
> 17:52:25.195 [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded17:52:25.195
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
> org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126) at
> sun.nio.ch.Invoker.invokeDirect(Invoker.java:157) at
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
> at
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.doWriteCycle(Nio2Session.java:420)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.startWriting(Nio2Session.java:404)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.finishWrite(Nio2Session.java:495)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleCompletedWriteCycle(Nio2Session.java:465)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$2.onCompleted(Nio2Session.java:429)
> at
>
[jira] [Comment Edited] (SSHD-1070) OutOfMemoryError when use port forwarding
[
https://issues.apache.org/jira/browse/SSHD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192639#comment-17192639
]
Thomas Wolf edited comment on SSHD-1070 at 9/9/20, 5:53 AM:
{quote}I think your implementation PR #163 has the minimal overall impact and
is more suitable for a quick fix to the problem.
{quote}
I'm not sure. I actually closed/abandoned that PR after having tried your
change. I did observe that with my change, I consistently did run into
SSHD-1069 with the iperf3 test you suggested here (with -P 8; my machine has 4
cores and thus 5 NIO threads), but with yours, it just worked fine even with -P
8, and the throughputs for -P 1 and -P 2 were identical for both approaches.
Also, if I understand your change right, it is specific for the forwarding
case, whereas mine has the risk of affecting other uses of the
{{BufferedIoOutputStream}}. But forwarding should be the only scenario where a
server would encounter such speed differences between the two ends. (Or are
there other cases?) So probably your approach is less risky.
was (Author: wolft):
{quote}
I think your implementation PR #163 has the minimal overall impact and is more
suitable for a quick fix to the problem.
{quote}
I'm not sure. I actually closed/abandoned that PR after having tried your
change. I did observe that with my change, I consistently did run into into
SSHD-1069 with the iperf3 test you suggested here (with -P 8; my machine has 4
cores and thus 5 NIO threads), but with yours, it just worked fine even with -P
8, and the throughputs for -P 1 and -P 2 were identical for both approaches.
Also, if I understand your change right, it is specific for the forwarding
case, whereas mine has the risk of affecting other uses of the
{{BufferedIoOutputstream}}. But forwarding should be the only scenario where a
server would encounter such speed differences between the two ends. (Or are
there other cases?) So probably your approach is less risky.
> OutOfMemoryError when use port forwarding
> -
>
> Key: SSHD-1070
> URL: https://issues.apache.org/jira/browse/SSHD-1070
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hi [~gnodet], I found this commit implemented asynchronous port forwarding:
> [https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-33823b8546f71d77bb1d653358ecde70]
> However, when a large amount of data is returned from upstream application,
> it is possible to cause an OOM in SSHD.
> Step1. SSHD server:
> {code:java}
> import org.apache.sshd.common.FactoryManager;
> import org.apache.sshd.common.PropertyResolverUtils;
> import org.apache.sshd.common.util.security.SecurityUtils;
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.io.IOException;
> import java.nio.file.Paths;
> public class TestSshd2 {
> public static void main(String[] args) throws IOException,
> InterruptedException {
> SecurityUtils.setAPrioriDisabledProvider("BC", true);
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/aa.key")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1);
> }
> }
> {code}
> Step2. start ssh client and iperf3 server:
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -p 12133 -f -x -N -T -L
> 0.0.0.0:15678:127.0.0.1:12345 test5@127.0.0.1
> iperf3 -s -p 12345
> {code}
> Step3. run iperf3 client:
> {code:java}
> iperf3 -c 127.0.0.1 -i 1 -t 120 -p 15678 -P 8 --reverse
> {code}
> *-R, --reverse run in reverse mode (server sends, client receives)*
> SSHD will receive a lot of data but will not be able to forward it in time.
> log when OOM:
> {code:java}
> 17:52:25.195 [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded17:52:25.195
> [sshd-SshServer[5bcea91b](port=12133)-nio2-thread-1] WARN
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:33524, remote=/127.0.0.1:12345])
> Exception handler threw OutOfMemoryError, closing the session: GC overhead
> limit exceeded at
>
[jira] [Commented] (SSHD-1008) Proxy & socks5 use in client server communication
[ https://issues.apache.org/jira/browse/SSHD-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17121296#comment-17121296 ] Thomas Wolf commented on SSHD-1008: --- [~ssmali1505]: Lyor's answer is for making the server support SOCKS5. If you want to have the _client_ connect through a SOCKS5 or HTTP CONNECT proxy, a bit more work is needed. It's a bit complicated because the framework starts reading messages only once the ClientSessionImpl creator has returned, but that creator already initiates the proxy protocol, and also sends the SSH identification and possibly the KEX init. You might want to take a look at [how we did that in JGit|https://git.eclipse.org/r/plugins/gitiles/jgit/jgit/+/master/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/internal/transport/sshd]: basically we install a ClientProxyConnector that tells the session to divert all messages received to the proxy connector until the proxy protocol is finished. We buffer the initial identification and KEX init messages, and send them only once the proxy protocol has established the proxy connection. > Proxy & socks5 use in client server communication > - > > Key: SSHD-1008 > URL: https://issues.apache.org/jira/browse/SSHD-1008 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep >Priority: Major > > We have client and server both written in SSHD mina and now customer want to > add proxy, socks5 feature in current client & server communication. So all > traffic should go via proxy. > > Also point to be consider as proxy may have authentication. > Please let me know can we give support for such scenarios. If yes do we have > some reference class or test scrips? > > In sort am finding replacement for > [https://www.javatips.net/api/j2ssh-maverick-master/j2ssh-maverick/src/main/java/com/sshtools/net/SocksProxyTransport.java#] > and > [https://www.javatips.net/api/j2ssh-maverick-master/j2ssh-maverick/src/main/java/com/sshtools/net/SocksProxyTransport.java#] > for this two mavericks class. > [~lgoldstein] can you please help me to identify right classes or any > pointers? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-1050) Race condition between early exceptions and AuthFuture
Thomas Wolf created SSHD-1050:
-
Summary: Race condition between early exceptions and AuthFuture
Key: SSHD-1050
URL: https://issues.apache.org/jira/browse/SSHD-1050
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.4.0, 2.6.0
Reporter: Thomas Wolf
It appears that sometimes exceptions that occur early in connection setup are
not reported on the AuthFuture. When that happens, AuthFuture.verify(timeout)
will spend the whole timeout waiting and then report a timeout. The earlier
exception is lost and nowhere to be seen.
I stumbled over this when analyzing [Eclipse bug
565394|https://bugs.eclipse.org/bugs/show_bug.cgi?id=565394].
It's not easy to reproduce, but with the below client test I can manage to make
the test fail from time to time if run repeatedly. (That test uses a large
preamble before the server identification to provoke an early exception. Using
publickey auth instead of password auth increases the chances to get a failure.
Running in a debugger increases the chances even more. It's clearly
timing-related.)
{code:java}
private String longPreamble() {
StringBuilder b = new StringBuilder();
for (int i = 0; i < 250; i++) {
b.append('a');
}
String line = b.toString();
b = new StringBuilder(line);
int limit = CoreModuleProperties.MAX_IDENTIFICATION_SIZE.get(sshd)
.orElse(Integer.valueOf(16 * 1024)).intValue();
limit = limit / 250 + 1;
for (int i = 0; i < limit; i++) {
b.append(CoreModuleProperties.SERVER_EXTRA_IDENT_LINES_SEPARATOR)
.append(line);
}
return b.toString();
}
@Test
public void testAuthGetsNotifiedOnLongPreamble() throws Exception {
CoreModuleProperties.SERVER_EXTRA_IDENTIFICATION_LINES.set(sshd,
longPreamble());
sshd.setPasswordAuthenticator(RejectAllPasswordAuthenticator.INSTANCE);
sshd.setKeyboardInteractiveAuthenticator(KeyboardInteractiveAuthenticator.NONE);
client.setUserAuthFactories(
Collections.singletonList(UserAuthPublicKeyFactory.INSTANCE));
client.start();
try (ClientSession session =
client.connect(getCurrentTestName(), TEST_LOCALHOST, port)
.verify(CONNECT_TIMEOUT).getSession()) {
KeyPairProvider keys = createTestHostKeyProvider();
session.addPublicKeyIdentity(
keys.loadKey(session,
CommonTestSupportUtils.DEFAULT_TEST_HOST_KEY_TYPE));
// This auth should fail because the server sends too many lines before
// the server identification. However, the auth must not time out! There's
// an exception raised early on when the identification is read, but
// frequently this exception gets not reported on the auth future that
// we are waiting on here, and then we wait for the whole timeout.
//
// There's a race condition somewhere. The test succeeds frequently, and is
// hard to make fail, but if run enough times it will usually fail. Running
// this in a debugger increases the chances of it failing.
Throwable e = assertThrows(Throwable.class,
() -> session.auth().verify(AUTH_TIMEOUT));
assertFalse(e.getMessage().contains("timeout"));
assertFalse(session.isAuthenticated());
} finally {
client.stop();
}
}
{code}
Perhaps the connect future should be fulfilled only once the initial KEX is
done? OpenSSH's ConnectTimeout does include the time until after the initial
KEX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1050) Race condition between early exceptions and AuthFuture
[
https://issues.apache.org/jira/browse/SSHD-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170592#comment-17170592
]
Thomas Wolf commented on SSHD-1050:
---
Right. I shouldn't post spur-of-the-moment ideas :). This needs some other way
to resolve the race condition.
What's the reason for the always false AuthFuture created in the
ClientSessionImpl constructor?
BTW, I think the auth timeout encompasses also user interactions like entering
passwords or key passphrases. That's also a bit weird. Is that the reason for
the high default timeout of 120 seconds?
In the Eclipse bug linked in the description, the race condition means that the
SSH connection initiation just hangs for two minutes before reporting "time
out", even if no user input is needed or asked for.
> Race condition between early exceptions and AuthFuture
> --
>
> Key: SSHD-1050
> URL: https://issues.apache.org/jira/browse/SSHD-1050
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0, 2.6.0
>Reporter: Thomas Wolf
>Priority: Major
>
> It appears that sometimes exceptions that occur early in connection setup are
> not reported on the AuthFuture. When that happens, AuthFuture.verify(timeout)
> will spend the whole timeout waiting and then report a timeout. The earlier
> exception is lost and nowhere to be seen.
> I stumbled over this when analyzing [Eclipse bug
> 565394|https://bugs.eclipse.org/bugs/show_bug.cgi?id=565394].
> It's not easy to reproduce, but with the below client test I can manage to
> make the test fail from time to time if run repeatedly. (That test uses a
> large preamble before the server identification to provoke an early
> exception. Using publickey auth instead of password auth increases the
> chances to get a failure. Running in a debugger increases the chances even
> more. It's clearly timing-related.)
> {code:java}
> private String longPreamble() {
>StringBuilder b = new StringBuilder();
>for (int i = 0; i < 250; i++) {
> b.append('a');
>}
>String line = b.toString();
>b = new StringBuilder(line);
>int limit = CoreModuleProperties.MAX_IDENTIFICATION_SIZE.get(sshd)
>.orElse(Integer.valueOf(16 * 1024)).intValue();
>limit = limit / 250 + 1;
>for (int i = 0; i < limit; i++) {
> b.append(CoreModuleProperties.SERVER_EXTRA_IDENT_LINES_SEPARATOR)
> .append(line);
>}
>return b.toString();
> }
> @Test
> public void testAuthGetsNotifiedOnLongPreamble() throws Exception {
>CoreModuleProperties.SERVER_EXTRA_IDENTIFICATION_LINES.set(sshd,
>longPreamble());
>sshd.setPasswordAuthenticator(RejectAllPasswordAuthenticator.INSTANCE);
>
> sshd.setKeyboardInteractiveAuthenticator(KeyboardInteractiveAuthenticator.NONE);
>client.setUserAuthFactories(
>Collections.singletonList(UserAuthPublicKeyFactory.INSTANCE));
>client.start();
>try (ClientSession session =
>client.connect(getCurrentTestName(), TEST_LOCALHOST, port)
>.verify(CONNECT_TIMEOUT).getSession()) {
> KeyPairProvider keys = createTestHostKeyProvider();
> session.addPublicKeyIdentity(
> keys.loadKey(session,
> CommonTestSupportUtils.DEFAULT_TEST_HOST_KEY_TYPE));
> // This auth should fail because the server sends too many lines before
> // the server identification. However, the auth must not time out!
> There's
> // an exception raised early on when the identification is read, but
> // frequently this exception gets not reported on the auth future that
> // we are waiting on here, and then we wait for the whole timeout.
> //
> // There's a race condition somewhere. The test succeeds frequently, and
> is
> // hard to make fail, but if run enough times it will usually fail.
> Running
> // this in a debugger increases the chances of it failing.
> Throwable e = assertThrows(Throwable.class,
> () -> session.auth().verify(AUTH_TIMEOUT));
> assertFalse(e.getMessage().contains("timeout"));
> assertFalse(session.isAuthenticated());
>} finally {
> client.stop();
>}
> }
> {code}
> Perhaps the connect future should be fulfilled only once the initial KEX is
> done? OpenSSH's ConnectTimeout does include the time until after the initial
> KEX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1050) Race condition between early exceptions and AuthFuture
[
https://issues.apache.org/jira/browse/SSHD-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170615#comment-17170615
]
Thomas Wolf commented on SSHD-1050:
---
{quote}If an exception occurs while the old instance is still in effect, then
it is not "transferred" to the new instance{quote}
Well, if the old instance was still in effect, there isn't anything to
"transfer" since any exception will just be ignored because of that initial
{{setAuth(false)}}.
> Race condition between early exceptions and AuthFuture
> --
>
> Key: SSHD-1050
> URL: https://issues.apache.org/jira/browse/SSHD-1050
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0, 2.6.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Major
>
> It appears that sometimes exceptions that occur early in connection setup are
> not reported on the AuthFuture. When that happens, AuthFuture.verify(timeout)
> will spend the whole timeout waiting and then report a timeout. The earlier
> exception is lost and nowhere to be seen.
> I stumbled over this when analyzing [Eclipse bug
> 565394|https://bugs.eclipse.org/bugs/show_bug.cgi?id=565394].
> It's not easy to reproduce, but with the below client test I can manage to
> make the test fail from time to time if run repeatedly. (That test uses a
> large preamble before the server identification to provoke an early
> exception. Using publickey auth instead of password auth increases the
> chances to get a failure. Running in a debugger increases the chances even
> more. It's clearly timing-related.)
> {code:java}
> private String longPreamble() {
>StringBuilder b = new StringBuilder();
>for (int i = 0; i < 250; i++) {
> b.append('a');
>}
>String line = b.toString();
>b = new StringBuilder(line);
>int limit = CoreModuleProperties.MAX_IDENTIFICATION_SIZE.get(sshd)
>.orElse(Integer.valueOf(16 * 1024)).intValue();
>limit = limit / 250 + 1;
>for (int i = 0; i < limit; i++) {
> b.append(CoreModuleProperties.SERVER_EXTRA_IDENT_LINES_SEPARATOR)
> .append(line);
>}
>return b.toString();
> }
> @Test
> public void testAuthGetsNotifiedOnLongPreamble() throws Exception {
>CoreModuleProperties.SERVER_EXTRA_IDENTIFICATION_LINES.set(sshd,
>longPreamble());
>sshd.setPasswordAuthenticator(RejectAllPasswordAuthenticator.INSTANCE);
>
> sshd.setKeyboardInteractiveAuthenticator(KeyboardInteractiveAuthenticator.NONE);
>client.setUserAuthFactories(
>Collections.singletonList(UserAuthPublicKeyFactory.INSTANCE));
>client.start();
>try (ClientSession session =
>client.connect(getCurrentTestName(), TEST_LOCALHOST, port)
>.verify(CONNECT_TIMEOUT).getSession()) {
> KeyPairProvider keys = createTestHostKeyProvider();
> session.addPublicKeyIdentity(
> keys.loadKey(session,
> CommonTestSupportUtils.DEFAULT_TEST_HOST_KEY_TYPE));
> // This auth should fail because the server sends too many lines before
> // the server identification. However, the auth must not time out!
> There's
> // an exception raised early on when the identification is read, but
> // frequently this exception gets not reported on the auth future that
> // we are waiting on here, and then we wait for the whole timeout.
> //
> // There's a race condition somewhere. The test succeeds frequently, and
> is
> // hard to make fail, but if run enough times it will usually fail.
> Running
> // this in a debugger increases the chances of it failing.
> Throwable e = assertThrows(Throwable.class,
> () -> session.auth().verify(AUTH_TIMEOUT));
> assertFalse(e.getMessage().contains("timeout"));
> assertFalse(session.isAuthenticated());
>} finally {
> client.stop();
>}
> }
> {code}
> Perhaps the connect future should be fulfilled only once the initial KEX is
> done? OpenSSH's ConnectTimeout does include the time until after the initial
> KEX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1028) SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed: 64"
[
https://issues.apache.org/jira/browse/SSHD-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151904#comment-17151904
]
Thomas Wolf commented on SSHD-1028:
---
[~gnodet], why was the {{close(true)}} removed from
{{Nio2Session.handleReadCycleCompletion()}}? When and where should server-side
session be closed then? I also notice that the debug logging there still says
"closing IoSession now"...
> SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed:
> 64"
>
>
> Key: SSHD-1028
> URL: https://issues.apache.org/jira/browse/SSHD-1028
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: bazel test
> //javatests/com/google/gerrit/acceptance/git:SshPushForReviewIT
>Reporter: David Ostrovsky
>Priority: Major
>
> I'm trying to migrate Gerrit to 2.5.0 and seeing this exception:
> {code}
> 80)
> pushCommitsWithSameTreeNoChanges(com.google.gerrit.acceptance.git.SshPushForReviewIT)
> com.jcraft.jsch.JSchException: SSH_MSG_DISCONNECT: 12 Too many concurrent
> connections (64) - max. allowed: 64
> at com.jcraft.jsch.Session.read(Session.java:1004)
> at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:198)
> at com.jcraft.jsch.Session.connect(Session.java:470)
> at com.jcraft.jsch.Session.connect(Session.java:183)
> at
> com.google.gerrit.acceptance.SshSession.getSession(SshSession.java:111)
> at com.google.gerrit.acceptance.SshSession.open(SshSession.java:46)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.initSsh(AbstractDaemonTest.java:541)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.beforeTest(AbstractDaemonTest.java:456)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest$1$1.evaluate(AbstractDaemonTest.java:230)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> com.google.testing.junit.runner.internal.junit4.CancellableRequestFactory$CancellableRunner.run(CancellableRequestFactory.java:108)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> com.google.testing.junit.runner.junit4.JUnit4Runner.run(JUnit4Runner.java:116)
> at
> com.google.testing.junit.runner.BazelTestRunner.runTestsInSuite(BazelTestRunner.java:159)
> at
> com.google.testing.junit.runner.BazelTestRunner.main(BazelTestRunner.java:85)
> {code}
> Reproducer is here: [1].
> [1]
[jira] [Commented] (SSHD-1028) SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed: 64"
[
https://issues.apache.org/jira/browse/SSHD-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151101#comment-17151101
]
Thomas Wolf commented on SSHD-1028:
---
Very simple [reproducer in the JGit
tests|https://git.eclipse.org/r/c/jgit/jgit/+/165814/1/org.eclipse.jgit.ssh.apache.test/tst/org/eclipse/jgit/transport/sshd/ApacheSshTest.java]:
sets the server's MAX_CONCURRENT_SESSIONS to 2, clones and then fetches twice:
each is 1 ssh server session; the third one (i.e., the second explicit fetch)
fails.
Looks like the server does not close its server-side session when a client
disconnects.
> SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed:
> 64"
>
>
> Key: SSHD-1028
> URL: https://issues.apache.org/jira/browse/SSHD-1028
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: bazel test
> //javatests/com/google/gerrit/acceptance/git:SshPushForReviewIT
>Reporter: David Ostrovsky
>Priority: Major
>
> I'm trying to migrate Gerrit to 2.5.0 and seeing this exception:
> {code}
> 80)
> pushCommitsWithSameTreeNoChanges(com.google.gerrit.acceptance.git.SshPushForReviewIT)
> com.jcraft.jsch.JSchException: SSH_MSG_DISCONNECT: 12 Too many concurrent
> connections (64) - max. allowed: 64
> at com.jcraft.jsch.Session.read(Session.java:1004)
> at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:198)
> at com.jcraft.jsch.Session.connect(Session.java:470)
> at com.jcraft.jsch.Session.connect(Session.java:183)
> at
> com.google.gerrit.acceptance.SshSession.getSession(SshSession.java:111)
> at com.google.gerrit.acceptance.SshSession.open(SshSession.java:46)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.initSsh(AbstractDaemonTest.java:541)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.beforeTest(AbstractDaemonTest.java:456)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest$1$1.evaluate(AbstractDaemonTest.java:230)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> com.google.testing.junit.runner.internal.junit4.CancellableRequestFactory$CancellableRunner.run(CancellableRequestFactory.java:108)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> com.google.testing.junit.runner.junit4.JUnit4Runner.run(JUnit4Runner.java:116)
> at
>
[jira] [Comment Edited] (SSHD-1028) SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed: 64"
[
https://issues.apache.org/jira/browse/SSHD-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151050#comment-17151050
]
Thomas Wolf edited comment on SSHD-1028 at 7/3/20, 4:20 PM:
Has the behavior of session closing changed?
When I log server-side session creation (in
{{Nio2Acceptor.AcceptCompletionHandler.onCompleted()}}) and unmapping (in
{{Nio2Service.unmapSession()}}) and then run
{{org.apache.sshd.common.forward.ApacheServerJschClientTest}}, I do see all
server sessions being closed, but most of them only after the last test. Thus
if you do more than 64 (sequential) tests, it's possible that the session map
in {{Nio2Service}} contains 64 or more old sessions. If those are still in the
map when {{AbstractServerSession#getActiveSessionCountForUser()}} is called
they'll count against the limit.
If I set
{{server.getProperties().put(ServerFactoryManager.MAX_CONCURRENT_SESSIONS,
4);}} in {{ApacheServerJschClientTest.startServer()}}, the last two tests fail
with that same error message: "com.jcraft.jsch.JSchException:
SSH_MSG_DISCONNECT: 12 Too many concurrent connections (4) - max. allowed: 4".
It's not related to JSch being used for the client – I can provoke the same
kind of failure also with the {{ApacheServerApacheClientTest}} if I set
MAX_CONCURRENT_SESSIONS to 4.
was (Author: wolft):
Has the behavior of session closing changed?
When I log server-side session creation (in
{{Nio2Acceptor.AcceptCompletionHandler.onCompleted()}}) and unmapping (in
{{Nio2Service.unmapSession()}}) and the run
{{org.apache.sshd.common.forward.ApacheServerJschClientTest}}, I do see all
server sessions being closed, but most of them only after the last test. Thus
if you do more than 64 (sequential) tests, it's possible that the session map
in {{Nio2Service}} contains 64 or more old sessions. If those are still in the
map when {{AbstractServerSession#getActiveSessionCountForUser()}} is called
they'll count against the limit.
If I set
{{server.getProperties().put(ServerFactoryManager.MAX_CONCURRENT_SESSIONS,
4);}} in {{ApacheServerJschClientTest.startServer()}}, the last two tests fail
with that same error message: "com.jcraft.jsch.JSchException:
SSH_MSG_DISCONNECT: 12 Too many concurrent connections (4) - max. allowed: 4".
It's not related to JSch being used for the client – I can provoke the same
kind of failure also with the {{ApacheServerApacheClientTest}} if I set
MAX_CONCURRENT_SESSIONS to 4.
> SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed:
> 64"
>
>
> Key: SSHD-1028
> URL: https://issues.apache.org/jira/browse/SSHD-1028
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: bazel test
> //javatests/com/google/gerrit/acceptance/git:SshPushForReviewIT
>Reporter: David Ostrovsky
>Priority: Major
>
> I'm trying to migrate Gerrit to 2.5.0 and seeing this exception:
> {code}
> 80)
> pushCommitsWithSameTreeNoChanges(com.google.gerrit.acceptance.git.SshPushForReviewIT)
> com.jcraft.jsch.JSchException: SSH_MSG_DISCONNECT: 12 Too many concurrent
> connections (64) - max. allowed: 64
> at com.jcraft.jsch.Session.read(Session.java:1004)
> at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:198)
> at com.jcraft.jsch.Session.connect(Session.java:470)
> at com.jcraft.jsch.Session.connect(Session.java:183)
> at
> com.google.gerrit.acceptance.SshSession.getSession(SshSession.java:111)
> at com.google.gerrit.acceptance.SshSession.open(SshSession.java:46)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.initSsh(AbstractDaemonTest.java:541)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.beforeTest(AbstractDaemonTest.java:456)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest$1$1.evaluate(AbstractDaemonTest.java:230)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at
[jira] [Comment Edited] (SSHD-1028) SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed: 64"
[
https://issues.apache.org/jira/browse/SSHD-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151101#comment-17151101
]
Thomas Wolf edited comment on SSHD-1028 at 7/3/20, 7:14 PM:
Very simple [reproducer in the JGit
tests|https://git.eclipse.org/r/c/jgit/jgit/+/165814/1/org.eclipse.jgit.ssh.apache.test/tst/org/eclipse/jgit/transport/sshd/ApacheSshTest.java]:
sets the server's MAX_CONCURRENT_SESSIONS to 2, clones and then fetches twice:
each is 1 ssh server session; the third one (i.e., the second explicit fetch)
fails with 2.5.1. Works with 2.4.0.
Looks like the server does not close its server-side session when a client
disconnects.
was (Author: wolft):
Very simple [reproducer in the JGit
tests|https://git.eclipse.org/r/c/jgit/jgit/+/165814/1/org.eclipse.jgit.ssh.apache.test/tst/org/eclipse/jgit/transport/sshd/ApacheSshTest.java]:
sets the server's MAX_CONCURRENT_SESSIONS to 2, clones and then fetches twice:
each is 1 ssh server session; the third one (i.e., the second explicit fetch)
fails.
Looks like the server does not close its server-side session when a client
disconnects.
> SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed:
> 64"
>
>
> Key: SSHD-1028
> URL: https://issues.apache.org/jira/browse/SSHD-1028
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: bazel test
> //javatests/com/google/gerrit/acceptance/git:SshPushForReviewIT
>Reporter: David Ostrovsky
>Priority: Major
>
> I'm trying to migrate Gerrit to 2.5.0 and seeing this exception:
> {code}
> 80)
> pushCommitsWithSameTreeNoChanges(com.google.gerrit.acceptance.git.SshPushForReviewIT)
> com.jcraft.jsch.JSchException: SSH_MSG_DISCONNECT: 12 Too many concurrent
> connections (64) - max. allowed: 64
> at com.jcraft.jsch.Session.read(Session.java:1004)
> at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:198)
> at com.jcraft.jsch.Session.connect(Session.java:470)
> at com.jcraft.jsch.Session.connect(Session.java:183)
> at
> com.google.gerrit.acceptance.SshSession.getSession(SshSession.java:111)
> at com.google.gerrit.acceptance.SshSession.open(SshSession.java:46)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.initSsh(AbstractDaemonTest.java:541)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.beforeTest(AbstractDaemonTest.java:456)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest$1$1.evaluate(AbstractDaemonTest.java:230)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at
[jira] [Commented] (SSHD-1028) SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed: 64"
[
https://issues.apache.org/jira/browse/SSHD-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151050#comment-17151050
]
Thomas Wolf commented on SSHD-1028:
---
Has the behavior of session closing changed?
When I log server-side session creation (in
{{Nio2Acceptor.AcceptCompletionHandler.onCompleted()}}) and unmapping (in
{{Nio2Service.unmapSession()}}) and the run
{{org.apache.sshd.common.forward.ApacheServerJschClientTest}}, I do see all
server sessions being closed, but most of them only after the last test. Thus
if you do more than 64 (sequential) tests, it's possible that the session map
in {{Nio2Service}} contains 64 or more old sessions. If those are still in the
map when {{AbstractServerSession#getActiveSessionCountForUser()}} is called
they'll count against the limit.
If I set
{{server.getProperties().put(ServerFactoryManager.MAX_CONCURRENT_SESSIONS,
4);}} in {{ApacheServerJschClientTest.startServer()}}, the last two tests fail
with that same error message: "com.jcraft.jsch.JSchException:
SSH_MSG_DISCONNECT: 12 Too many concurrent connections (4) - max. allowed: 4".
It's not related to JSch being used for the client – I can provoke the same
kind of failure also with the {{ApacheServerApacheClientTest}} if I set
MAX_CONCURRENT_SESSIONS to 4.
> SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed:
> 64"
>
>
> Key: SSHD-1028
> URL: https://issues.apache.org/jira/browse/SSHD-1028
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: bazel test
> //javatests/com/google/gerrit/acceptance/git:SshPushForReviewIT
>Reporter: David Ostrovsky
>Priority: Major
>
> I'm trying to migrate Gerrit to 2.5.0 and seeing this exception:
> {code}
> 80)
> pushCommitsWithSameTreeNoChanges(com.google.gerrit.acceptance.git.SshPushForReviewIT)
> com.jcraft.jsch.JSchException: SSH_MSG_DISCONNECT: 12 Too many concurrent
> connections (64) - max. allowed: 64
> at com.jcraft.jsch.Session.read(Session.java:1004)
> at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:198)
> at com.jcraft.jsch.Session.connect(Session.java:470)
> at com.jcraft.jsch.Session.connect(Session.java:183)
> at
> com.google.gerrit.acceptance.SshSession.getSession(SshSession.java:111)
> at com.google.gerrit.acceptance.SshSession.open(SshSession.java:46)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.initSsh(AbstractDaemonTest.java:541)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.beforeTest(AbstractDaemonTest.java:456)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest$1$1.evaluate(AbstractDaemonTest.java:230)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at
[jira] [Commented] (SSHD-1028) SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed: 64"
[
https://issues.apache.org/jira/browse/SSHD-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151059#comment-17151059
]
Thomas Wolf commented on SSHD-1028:
---
Appears to be caused by
[https://github.com/apache/mina-sshd/commit/45f84aab59b2e11d72942cffe9d810e37ab64959#diff-0923b58bc72c7eeda0b7c65559d3ead5L371]
. This is the first commit on which I can reproduce the problem; on earlier
commits, {{ApacheServerApacheClientTest}} succeeds even with
MAX_CONCURRENT_SESSIONS == 4.
> SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed:
> 64"
>
>
> Key: SSHD-1028
> URL: https://issues.apache.org/jira/browse/SSHD-1028
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: bazel test
> //javatests/com/google/gerrit/acceptance/git:SshPushForReviewIT
>Reporter: David Ostrovsky
>Priority: Major
>
> I'm trying to migrate Gerrit to 2.5.0 and seeing this exception:
> {code}
> 80)
> pushCommitsWithSameTreeNoChanges(com.google.gerrit.acceptance.git.SshPushForReviewIT)
> com.jcraft.jsch.JSchException: SSH_MSG_DISCONNECT: 12 Too many concurrent
> connections (64) - max. allowed: 64
> at com.jcraft.jsch.Session.read(Session.java:1004)
> at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:198)
> at com.jcraft.jsch.Session.connect(Session.java:470)
> at com.jcraft.jsch.Session.connect(Session.java:183)
> at
> com.google.gerrit.acceptance.SshSession.getSession(SshSession.java:111)
> at com.google.gerrit.acceptance.SshSession.open(SshSession.java:46)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.initSsh(AbstractDaemonTest.java:541)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.beforeTest(AbstractDaemonTest.java:456)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest$1$1.evaluate(AbstractDaemonTest.java:230)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> com.google.testing.junit.runner.internal.junit4.CancellableRequestFactory$CancellableRunner.run(CancellableRequestFactory.java:108)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> com.google.testing.junit.runner.junit4.JUnit4Runner.run(JUnit4Runner.java:116)
> at
> com.google.testing.junit.runner.BazelTestRunner.runTestsInSuite(BazelTestRunner.java:159)
> at
>
[jira] [Commented] (SSHD-1022) NPE in SftpOutputStreamAsync.flush()
[
https://issues.apache.org/jira/browse/SSHD-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146103#comment-17146103
]
Thomas Wolf commented on SSHD-1022:
---
This bug cannot be worked around in client code since {{write(byte[], int,
int)}} calls {{flush()}} internally when the buffer is full. This means SFTP
file uploads may fail at any time. Would this warrant a bug-fix release 2.5.1
of at least sshd-sftp?
> NPE in SftpOutputStreamAsync.flush()
> -
>
> Key: SSHD-1022
> URL: https://issues.apache.org/jira/browse/SSHD-1022
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.6.0
>
>
> {{SftpOutputStreamAsync.flush()}} sets the internal buffer to {{null}}. Code
> invoking {{flush()}} without having written anything since the last flush
> will get an NPE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1022) NPE in SftpOutputStreamAsync.flush()
[
https://issues.apache.org/jira/browse/SSHD-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146179#comment-17146179
]
Thomas Wolf commented on SSHD-1022:
---
I'm not subscribed to the dev mailing list, so I can't reply there, but in any
case I can confirm that this bug is indeed fixed in the [staged 2.5.1 release
candidate|https://repository.apache.org/content/repositories/orgapachemina-1050].
JGit tests for ssh/sftp transports work with that 2.5.1.
> NPE in SftpOutputStreamAsync.flush()
> -
>
> Key: SSHD-1022
> URL: https://issues.apache.org/jira/browse/SSHD-1022
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.5.1
>
>
> {{SftpOutputStreamAsync.flush()}} sets the internal buffer to {{null}}. Code
> invoking {{flush()}} without having written anything since the last flush
> will get an NPE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1022) NPE in SftpOutputStreamAsync.flush()
[
https://issues.apache.org/jira/browse/SSHD-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146110#comment-17146110
]
Thomas Wolf commented on SSHD-1022:
---
BTW, are there any tests for this? Such as an SFTP upload by code that calls
{{flush()}} explicitly after {{write()}}?
> NPE in SftpOutputStreamAsync.flush()
> -
>
> Key: SSHD-1022
> URL: https://issues.apache.org/jira/browse/SSHD-1022
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.6.0
>
>
> {{SftpOutputStreamAsync.flush()}} sets the internal buffer to {{null}}. Code
> invoking {{flush()}} without having written anything since the last flush
> will get an NPE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-1037) private openssh key parsing error
[
https://issues.apache.org/jira/browse/SSHD-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160185#comment-17160185
]
Thomas Wolf edited comment on SSHD-1037 at 7/17/20, 8:17 PM:
-
This key is invalid; OpenSSH cannot parse it either:
{code:bash}
$ ssh-keygen -y -f testkey > testkey.pub
Load key "testkey": invalid format
$
{code}
was (Author: wolft):
This key is invalid; OpenSSH cannot parse it either:
{code:bash}
$ ssh-keygen -y -f testkey > testkey.pub
Load key "testkey2": invalid format
$
{code}
> private openssh key parsing error
> -
>
> Key: SSHD-1037
> URL: https://issues.apache.org/jira/browse/SSHD-1037
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Sandeep
>Priority: Major
> Attachments: console_log, parsing_java_method
>
>
> Hi Team,
> I am not able to parse openssh key with the help of
> *OpenSSHKeyPairResourceParser* class
> Java code and log is attached.
> Passwork of key is : RoldWtzuRB089Dztx7MmsIxe799c2MIL
> Key is as follows,
> -BEGIN OPENSSH PRIVATE KEY-
> b3BlbnNzaC1rZXktdjEACmFlczEyOC1jYmMGYmNyeXB0GBAM
> JEJgXHPG6QrP1OWVzu6TEAEAAACXB3NzaC1yc2EDAQAB
> gQCqpdnaIOxhfmKQbiM3TtJPOofzCeQ0tC5jUyB/jEo2BLg8FZ0I/LNm0gSVD9DP
> o/EJbFsHHGtX8iSB2t2mdszaJd1PX3e/5qEFm7P0tbqhp4sI+dgV+X3wvjADYBND
> 6PS44vTgd9MY8zyB24wDoj5gRM/w/FW67EtgwTdYzmExtwAAAfFLV4x18tC9tXX1
> 5nBqQuHpZezdrY3z2MS5cq8eb8o/+CdHvlBtjvcob8Stm8+3QXx7HMRDhoZhn+Pa
> EufIsRZ5Ta4XseJ2ukDeEzVZSa7hRrR56B3UUGhvKPEyMcQu33xH0/wsqoO8cmBs
> GxqDKSRBw26lj7OFZT7cIgsv/zAr67Q+ycX7OpXa8TlKZw3qrO1HZXNkZtY4ooO/
> nDuDfmOKVlbZ4HWcPXpcbojI6r0LLOhte4czLv3sQskEkJkzlnG62oLA2zrpvGlw
> 7u/uOtvuWNTwwFxJfQwwpiZRuACJIpyEJsTA+156SG0X+AIpAy8b6l3cOTLo00EP
> JbW20l8K+DdMvT0RWr895KaI7vcs30JeFmysm8eMKTUdVDgu2Sy8Qd/1GMhi1AZy
> peUWzvQNjauSwDoyJka5go0gUOa1biCl9o67Oy07estHnfeoK8NGcjmv14U1BP2a
> 0KzazesOxvbalr6hlgq1DAVTvpSRw1vAAx4xE1RrVA3qNMcFf3W8tOf7WQCO9J5m
> +o31L5Wiuh9uvPGN7tLbR1eOuwYMH7ICz0Ydvfkg5UFaFIYz8pUInLFFFle/YUMw
> KEtFrJKYItON25XcpqciorilWXJw0BdK7w/aeHoOVxOQer2PSj36J/jn0oC64guP
> g6SHko7U4Q==
> -END OPENSSH PRIVATE KEY-
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1037) private openssh key parsing error
[
https://issues.apache.org/jira/browse/SSHD-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160185#comment-17160185
]
Thomas Wolf commented on SSHD-1037:
---
This key is invalid; OpenSSH cannot parse it either:
{code:bash}
$ ssh-keygen -y -f testkey > testkey.pub
Load key "testkey2": invalid format
$
{code}
> private openssh key parsing error
> -
>
> Key: SSHD-1037
> URL: https://issues.apache.org/jira/browse/SSHD-1037
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Sandeep
>Priority: Major
> Attachments: console_log, parsing_java_method
>
>
> Hi Team,
> I am not able to parse openssh key with the help of
> *OpenSSHKeyPairResourceParser* class
> Java code and log is attached.
> Passwork of key is : RoldWtzuRB089Dztx7MmsIxe799c2MIL
> Key is as follows,
> -BEGIN OPENSSH PRIVATE KEY-
> b3BlbnNzaC1rZXktdjEACmFlczEyOC1jYmMGYmNyeXB0GBAM
> JEJgXHPG6QrP1OWVzu6TEAEAAACXB3NzaC1yc2EDAQAB
> gQCqpdnaIOxhfmKQbiM3TtJPOofzCeQ0tC5jUyB/jEo2BLg8FZ0I/LNm0gSVD9DP
> o/EJbFsHHGtX8iSB2t2mdszaJd1PX3e/5qEFm7P0tbqhp4sI+dgV+X3wvjADYBND
> 6PS44vTgd9MY8zyB24wDoj5gRM/w/FW67EtgwTdYzmExtwAAAfFLV4x18tC9tXX1
> 5nBqQuHpZezdrY3z2MS5cq8eb8o/+CdHvlBtjvcob8Stm8+3QXx7HMRDhoZhn+Pa
> EufIsRZ5Ta4XseJ2ukDeEzVZSa7hRrR56B3UUGhvKPEyMcQu33xH0/wsqoO8cmBs
> GxqDKSRBw26lj7OFZT7cIgsv/zAr67Q+ycX7OpXa8TlKZw3qrO1HZXNkZtY4ooO/
> nDuDfmOKVlbZ4HWcPXpcbojI6r0LLOhte4czLv3sQskEkJkzlnG62oLA2zrpvGlw
> 7u/uOtvuWNTwwFxJfQwwpiZRuACJIpyEJsTA+156SG0X+AIpAy8b6l3cOTLo00EP
> JbW20l8K+DdMvT0RWr895KaI7vcs30JeFmysm8eMKTUdVDgu2Sy8Qd/1GMhi1AZy
> peUWzvQNjauSwDoyJka5go0gUOa1biCl9o67Oy07estHnfeoK8NGcjmv14U1BP2a
> 0KzazesOxvbalr6hlgq1DAVTvpSRw1vAAx4xE1RrVA3qNMcFf3W8tOf7WQCO9J5m
> +o31L5Wiuh9uvPGN7tLbR1eOuwYMH7ICz0Ydvfkg5UFaFIYz8pUInLFFFle/YUMw
> KEtFrJKYItON25XcpqciorilWXJw0BdK7w/aeHoOVxOQer2PSj36J/jn0oC64guP
> g6SHko7U4Q==
> -END OPENSSH PRIVATE KEY-
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1042) Command Limiting Policy SSH_FXP_READDIR closing connection
[
https://issues.apache.org/jira/browse/SSHD-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165630#comment-17165630
]
Thomas Wolf commented on SSHD-1042:
---
[~shahbazsbaig], please don't post log excerpts as images; post the logs as
text.
The "Command Limiting Policy" appears to be a [feature of the IBM Sterling B2B
Integrator|https://www.ibm.com/support/knowledgecenter/SS3JSW_6.0.1/integrating/integrating/integrator/CommandLimitPolicy.html].
Probably the same as OpenSSH's {{internal-sftp -P readdir}}, combined with a
{{Match}} directive. "NativeFilesystemProviderBase" appears to be a class from
that SB2Bi sftp server that check this "Command Limiting Policy".
It looks like there's a team that tries to replace maverick by Apache MINA sshd
inside SB2Bi. It also looks like this is a problem inside that SB2Bi; somehow
the maverick implementation appears to be wired up such that it doesn't close
the server-side session, while with sshd it gets closed. I _do_ notice that
maverick has its own {{PermissionDeniedException}} which is _not_ an
{{IOException}}. Perhaps that explains why that NativeFilesystemProviderBase
doesn't close the session with maverick.
In any case I think the reporter [~shahbazsbaig] will need to debug this more
closely in their application. It doesn't look like a problem of Apache sshd but
of how it's used by that application.
> Command Limiting Policy SSH_FXP_READDIR closing connection
> --
>
> Key: SSHD-1042
> URL: https://issues.apache.org/jira/browse/SSHD-1042
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Shahbaz
>Priority: Major
> Attachments: apache rmdir.PNG, maverick filesystem.PNG
>
>
> *This are the below commands which prevent the execution of process for the
> user at instance level relating to permission of open, read, write, opendir,
> readdir, remove, rename, makedir, removedir respectively.*
> *SSH_FXP_OPEN*
> *SSH_FXP_READ*
> *SSH_FXP_WRITE*
> *SSH_FXP_OPENDIR*
> *SSH_FXP_READDIR*
> *SSH_FXP_REMOVE*
> *SSH_FXP_RENAME*
> *SSH_FXP_MKDIR*
> *SSH_FXP_RMDIR*
> *But the command for* *SSH_FXP_READDIR is not executed as it directly closes
> the connection. This connection is closed because while throwing the
> exception it directly calls destroy method from filesystem. Is there any
> workaround to inhibit its execution when we extend sftpsubsytem class where
> exception is thrown.***
> *While reading the directory when SH_FXP_READDIR is applied, the operation is
> interrupted, as it evokes the destroy function to close the connection
> directly when an IOException is thrown. The issue is how can we make sure the
> destroy function is not called, when exception is thrown in a class which
> extends SFTPSubsystem.*
>
>
>
> *Below attached are the images which shows how destroy is invoked in both
> maverick and apache case.*
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1042) Command Limiting Policy SSH_FXP_READDIR closing connection
[
https://issues.apache.org/jira/browse/SSHD-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165711#comment-17165711
]
Thomas Wolf commented on SSHD-1042:
---
As I don't know your implementation I cannot answer this question.
If I had to debug this, I'd set breakpoints at {{SftpSubsystem.destroy()}} and
at the end of {{SftpSubsystem.doReadDir()}} at the {{sendStatus()}} call. Also
in your application at {{NativeFilesystemProviderBase.endSession()}} and at
{{NativeFilesystemProviderBase.checkCommandAllowed()}}. And I'd run the
application with a logger configured to produce full debug logging from Apache
sshd.
> Command Limiting Policy SSH_FXP_READDIR closing connection
> --
>
> Key: SSHD-1042
> URL: https://issues.apache.org/jira/browse/SSHD-1042
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Shahbaz
>Priority: Major
> Attachments: apache rmdir.PNG, maverick filesystem.PNG
>
>
> *This are the below commands which prevent the execution of process for the
> user at instance level relating to permission of open, read, write, opendir,
> readdir, remove, rename, makedir, removedir respectively.*
> *SSH_FXP_OPEN*
> *SSH_FXP_READ*
> *SSH_FXP_WRITE*
> *SSH_FXP_OPENDIR*
> *SSH_FXP_READDIR*
> *SSH_FXP_REMOVE*
> *SSH_FXP_RENAME*
> *SSH_FXP_MKDIR*
> *SSH_FXP_RMDIR*
> *But the command for* *SSH_FXP_READDIR is not executed as it directly closes
> the connection. This connection is closed because while throwing the
> exception it directly calls destroy method from filesystem. Is there any
> workaround to inhibit its execution when we extend sftpsubsytem class where
> exception is thrown.***
> *While reading the directory when SH_FXP_READDIR is applied, the operation is
> interrupted, as it evokes the destroy function to close the connection
> directly when an IOException is thrown. The issue is how can we make sure the
> destroy function is not called, when exception is thrown in a class which
> extends SFTPSubsystem.*
>
> *Exact working scenarios of the above issue:*
> We have our implementation of Command Limiting Policy to prevent specific IP
> addresses or users from executing
> certain commands on an SFTP server.
> After validation of the policy, we don't want user to perform the operation
> based on the command which is applied on the policy.
> For example: When the SSH_FXP_OPENDIR is invoked, the user is restricted
> from open directory operation.
> Our issue is related to command SSH_FXP_READDIR command.
> Expected Behaviour : Prevent user from reading the directory when sftp ls
> command is executed, by giving the message like "Unable to read the
> directory".
> But we see that, though we throw AcessDeniedException on validating the
> policy, the connection is getting closed, and we get an error as "Connection
> closed".
> We have the same implementation for validating the policy and we throw
> AcessDeniedException in case of all the sftp commands(if we need to prevent
> the user/ip)
> We find that all the sftp commands work as expected, except SSH_FXP_READDIR.
> The difference we find is that destroy() method in SFTP Subsystem is getting
> invoked after our policy validation in SSH_FXP_READDIR. In case of all other
> commands, we dont see destro() getting invoked.
>
> Is there any specific thing that needs to be handled in our implementation to
> prevent destroy() from getting invoked and connection getting closed. We are
> unable to find why destroy() is invoked in case of SSH_FXP_READDIR command,
> even though AcessDeniedException is thrown from our implementation.
>
>
>
> *Below attached are the images which shows how destroy is invoked in both
> maverick and apache case.*
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1042) Command Limiting Policy SSH_FXP_READDIR closing connection
[
https://issues.apache.org/jira/browse/SSHD-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165789#comment-17165789
]
Thomas Wolf commented on SSHD-1042:
---
[~lgoldstein]: BTW, the constructor of {{DirectoryHandle}} doesn't call
{{signalHandleOpening()}}. I think it should.
> Command Limiting Policy SSH_FXP_READDIR closing connection
> --
>
> Key: SSHD-1042
> URL: https://issues.apache.org/jira/browse/SSHD-1042
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Shahbaz
>Priority: Major
> Attachments: apache rmdir.PNG, maverick filesystem.PNG
>
>
> *This are the below commands which prevent the execution of process for the
> user at instance level relating to permission of open, read, write, opendir,
> readdir, remove, rename, makedir, removedir respectively.*
> *SSH_FXP_OPEN*
> *SSH_FXP_READ*
> *SSH_FXP_WRITE*
> *SSH_FXP_OPENDIR*
> *SSH_FXP_READDIR*
> *SSH_FXP_REMOVE*
> *SSH_FXP_RENAME*
> *SSH_FXP_MKDIR*
> *SSH_FXP_RMDIR*
> *But the command for* *SSH_FXP_READDIR is not executed as it directly closes
> the connection. This connection is closed because while throwing the
> exception it directly calls destroy method from filesystem. Is there any
> workaround to inhibit its execution when we extend sftpsubsytem class where
> exception is thrown.***
> *While reading the directory when SH_FXP_READDIR is applied, the operation is
> interrupted, as it evokes the destroy function to close the connection
> directly when an IOException is thrown. The issue is how can we make sure the
> destroy function is not called, when exception is thrown in a class which
> extends SFTPSubsystem.*
>
> *Exact working scenarios of the above issue:*
> We have our implementation of Command Limiting Policy to prevent specific IP
> addresses or users from executing
> certain commands on an SFTP server.
> After validation of the policy, we don't want user to perform the operation
> based on the command which is applied on the policy.
> For example: When the SSH_FXP_OPENDIR is invoked, the user is restricted
> from open directory operation.
> Our issue is related to command SSH_FXP_READDIR command.
> Expected Behaviour : Prevent user from reading the directory when sftp ls
> command is executed, by giving the message like "Unable to read the
> directory".
> But we see that, though we throw AcessDeniedException on validating the
> policy, the connection is getting closed, and we get an error as "Connection
> closed".
> We have the same implementation for validating the policy and we throw
> AcessDeniedException in case of all the sftp commands(if we need to prevent
> the user/ip)
> We find that all the sftp commands work as expected, except SSH_FXP_READDIR.
> The difference we find is that destroy() method in SFTP Subsystem is getting
> invoked after our policy validation in SSH_FXP_READDIR. In case of all other
> commands, we dont see destro() getting invoked.
>
> Is there any specific thing that needs to be handled in our implementation to
> prevent destroy() from getting invoked and connection getting closed. We are
> unable to find why destroy() is invoked in case of SSH_FXP_READDIR command,
> even though AcessDeniedException is thrown from our implementation.
>
>
>
> *Below attached are the images which shows how destroy is invoked in both
> maverick and apache case.*
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1042) Command Limiting Policy SSH_FXP_READDIR closing connection
[
https://issues.apache.org/jira/browse/SSHD-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165780#comment-17165780
]
Thomas Wolf commented on SSHD-1042:
---
One thing I notice (from code inspection only): if they throw
{{AccessDeniedException}} before the try-catch block inside
{{SftpSubsystem.doReadDir()}}, this will exit the loop in
{{SftpSubsystem.run()}} and the {{exitCallback}} will then close the
{{ChannelSession}}. If that's a case: clearly not an Apache sshd bug but wrong
usage.
Using an {{SftpEventListener}} throwing the exception from {{open()}} when the
handle is a {{DirectoryHandle}} would throw the exception at the right place,
but it would actually already have accessed the file system. The abstraction
logic of this "Command Limiting Policy" (or OpenSSH's {{internal-sftp -P
}}) is at the SFTP request level, and logically one would want to
forbid disabled SFTP commands as early as possible, so it might be more
appropriate to indeed override {{AbstractSftpSubsystemHelper.doProcess(Buffer,
int, int, int)}}, but not making it throw an exception but send back a status
of {{SSH_FX_PERMISSION_DENIED}}.
> Command Limiting Policy SSH_FXP_READDIR closing connection
> --
>
> Key: SSHD-1042
> URL: https://issues.apache.org/jira/browse/SSHD-1042
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Shahbaz
>Priority: Major
> Attachments: apache rmdir.PNG, maverick filesystem.PNG
>
>
> *This are the below commands which prevent the execution of process for the
> user at instance level relating to permission of open, read, write, opendir,
> readdir, remove, rename, makedir, removedir respectively.*
> *SSH_FXP_OPEN*
> *SSH_FXP_READ*
> *SSH_FXP_WRITE*
> *SSH_FXP_OPENDIR*
> *SSH_FXP_READDIR*
> *SSH_FXP_REMOVE*
> *SSH_FXP_RENAME*
> *SSH_FXP_MKDIR*
> *SSH_FXP_RMDIR*
> *But the command for* *SSH_FXP_READDIR is not executed as it directly closes
> the connection. This connection is closed because while throwing the
> exception it directly calls destroy method from filesystem. Is there any
> workaround to inhibit its execution when we extend sftpsubsytem class where
> exception is thrown.***
> *While reading the directory when SH_FXP_READDIR is applied, the operation is
> interrupted, as it evokes the destroy function to close the connection
> directly when an IOException is thrown. The issue is how can we make sure the
> destroy function is not called, when exception is thrown in a class which
> extends SFTPSubsystem.*
>
> *Exact working scenarios of the above issue:*
> We have our implementation of Command Limiting Policy to prevent specific IP
> addresses or users from executing
> certain commands on an SFTP server.
> After validation of the policy, we don't want user to perform the operation
> based on the command which is applied on the policy.
> For example: When the SSH_FXP_OPENDIR is invoked, the user is restricted
> from open directory operation.
> Our issue is related to command SSH_FXP_READDIR command.
> Expected Behaviour : Prevent user from reading the directory when sftp ls
> command is executed, by giving the message like "Unable to read the
> directory".
> But we see that, though we throw AcessDeniedException on validating the
> policy, the connection is getting closed, and we get an error as "Connection
> closed".
> We have the same implementation for validating the policy and we throw
> AcessDeniedException in case of all the sftp commands(if we need to prevent
> the user/ip)
> We find that all the sftp commands work as expected, except SSH_FXP_READDIR.
> The difference we find is that destroy() method in SFTP Subsystem is getting
> invoked after our policy validation in SSH_FXP_READDIR. In case of all other
> commands, we dont see destro() getting invoked.
>
> Is there any specific thing that needs to be handled in our implementation to
> prevent destroy() from getting invoked and connection getting closed. We are
> unable to find why destroy() is invoked in case of SSH_FXP_READDIR command,
> even though AcessDeniedException is thrown from our implementation.
>
>
>
> *Below attached are the images which shows how destroy is invoked in both
> maverick and apache case.*
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1042) Command Limiting Policy SSH_FXP_READDIR closing connection
[
https://issues.apache.org/jira/browse/SSHD-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165938#comment-17165938
]
Thomas Wolf commented on SSHD-1042:
---
Something like https://github.com/apache/mina-sshd/pull/151 might enable
implementing this via an {{SftpEventListener}}.
> Command Limiting Policy SSH_FXP_READDIR closing connection
> --
>
> Key: SSHD-1042
> URL: https://issues.apache.org/jira/browse/SSHD-1042
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Shahbaz
>Priority: Major
> Attachments: apache rmdir.PNG, maverick filesystem.PNG
>
>
> *This are the below commands which prevent the execution of process for the
> user at instance level relating to permission of open, read, write, opendir,
> readdir, remove, rename, makedir, removedir respectively.*
> *SSH_FXP_OPEN*
> *SSH_FXP_READ*
> *SSH_FXP_WRITE*
> *SSH_FXP_OPENDIR*
> *SSH_FXP_READDIR*
> *SSH_FXP_REMOVE*
> *SSH_FXP_RENAME*
> *SSH_FXP_MKDIR*
> *SSH_FXP_RMDIR*
> *But the command for* *SSH_FXP_READDIR is not executed as it directly closes
> the connection. This connection is closed because while throwing the
> exception it directly calls destroy method from filesystem. Is there any
> workaround to inhibit its execution when we extend sftpsubsytem class where
> exception is thrown.***
> *While reading the directory when SH_FXP_READDIR is applied, the operation is
> interrupted, as it evokes the destroy function to close the connection
> directly when an IOException is thrown. The issue is how can we make sure the
> destroy function is not called, when exception is thrown in a class which
> extends SFTPSubsystem.*
>
> *Exact working scenarios of the above issue:*
> We have our implementation of Command Limiting Policy to prevent specific IP
> addresses or users from executing
> certain commands on an SFTP server.
> After validation of the policy, we don't want user to perform the operation
> based on the command which is applied on the policy.
> For example: When the SSH_FXP_OPENDIR is invoked, the user is restricted
> from open directory operation.
> Our issue is related to command SSH_FXP_READDIR command.
> Expected Behaviour : Prevent user from reading the directory when sftp ls
> command is executed, by giving the message like "Unable to read the
> directory".
> But we see that, though we throw AcessDeniedException on validating the
> policy, the connection is getting closed, and we get an error as "Connection
> closed".
> We have the same implementation for validating the policy and we throw
> AcessDeniedException in case of all the sftp commands(if we need to prevent
> the user/ip)
> We find that all the sftp commands work as expected, except SSH_FXP_READDIR.
> The difference we find is that destroy() method in SFTP Subsystem is getting
> invoked after our policy validation in SSH_FXP_READDIR. In case of all other
> commands, we dont see destro() getting invoked.
>
> Is there any specific thing that needs to be handled in our implementation to
> prevent destroy() from getting invoked and connection getting closed. We are
> unable to find why destroy() is invoked in case of SSH_FXP_READDIR command,
> even though AcessDeniedException is thrown from our implementation.
>
>
>
> *Below attached are the images which shows how destroy is invoked in both
> maverick and apache case.*
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1037) private openssh key parsing error
[ https://issues.apache.org/jira/browse/SSHD-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160788#comment-17160788 ] Thomas Wolf commented on SSHD-1037: --- [~ssmali1505], this is a bug in the library you're using, which appears to be maverick-common 2.0.4. The key file they write is not a valid OpenSSH modern format key file. As Lyor has pointed out several times, maverick does not pad the private key. Apache MINA sshd and OpenSSH are correctly refusing to extract a key from that invalid file. > private openssh key parsing error > - > > Key: SSHD-1037 > URL: https://issues.apache.org/jira/browse/SSHD-1037 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep >Priority: Major > Attachments: KeyGenerationTest.java, console_log, junit_test_output, > parsing_java_method > > > Hi Team, > I am not able to parse openssh key with the help of > *OpenSSHKeyPairResourceParser* class > Java code and log is attached. > Passwork of key is : RoldWtzuRB089Dztx7MmsIxe799c2MIL > Key is as follows, > -BEGIN OPENSSH PRIVATE KEY- > b3BlbnNzaC1rZXktdjEACmFlczEyOC1jYmMGYmNyeXB0GBAM > JEJgXHPG6QrP1OWVzu6TEAEAAACXB3NzaC1yc2EDAQAB > gQCqpdnaIOxhfmKQbiM3TtJPOofzCeQ0tC5jUyB/jEo2BLg8FZ0I/LNm0gSVD9DP > o/EJbFsHHGtX8iSB2t2mdszaJd1PX3e/5qEFm7P0tbqhp4sI+dgV+X3wvjADYBND > 6PS44vTgd9MY8zyB24wDoj5gRM/w/FW67EtgwTdYzmExtwAAAfFLV4x18tC9tXX1 > 5nBqQuHpZezdrY3z2MS5cq8eb8o/+CdHvlBtjvcob8Stm8+3QXx7HMRDhoZhn+Pa > EufIsRZ5Ta4XseJ2ukDeEzVZSa7hRrR56B3UUGhvKPEyMcQu33xH0/wsqoO8cmBs > GxqDKSRBw26lj7OFZT7cIgsv/zAr67Q+ycX7OpXa8TlKZw3qrO1HZXNkZtY4ooO/ > nDuDfmOKVlbZ4HWcPXpcbojI6r0LLOhte4czLv3sQskEkJkzlnG62oLA2zrpvGlw > 7u/uOtvuWNTwwFxJfQwwpiZRuACJIpyEJsTA+156SG0X+AIpAy8b6l3cOTLo00EP > JbW20l8K+DdMvT0RWr895KaI7vcs30JeFmysm8eMKTUdVDgu2Sy8Qd/1GMhi1AZy > peUWzvQNjauSwDoyJka5go0gUOa1biCl9o67Oy07estHnfeoK8NGcjmv14U1BP2a > 0KzazesOxvbalr6hlgq1DAVTvpSRw1vAAx4xE1RrVA3qNMcFf3W8tOf7WQCO9J5m > +o31L5Wiuh9uvPGN7tLbR1eOuwYMH7ICz0Ydvfkg5UFaFIYz8pUInLFFFle/YUMw > KEtFrJKYItON25XcpqciorilWXJw0BdK7w/aeHoOVxOQer2PSj36J/jn0oC64guP > g6SHko7U4Q== > -END OPENSSH PRIVATE KEY- > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1115) after client send FIN message, server failed excute close, leads to server under CLOSE_WAIT status
[ https://issues.apache.org/jira/browse/SSHD-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf resolved SSHD-1115. --- Fix Version/s: 2.6.0 Resolution: Duplicate This is the same as SSHD-1028, which is fixed in 2.6.0. 2.6.0 should come out really soon. > after client send FIN message, server failed excute close, leads to server > under CLOSE_WAIT status > --- > > Key: SSHD-1115 > URL: https://issues.apache.org/jira/browse/SSHD-1115 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 >Reporter: fanjie >Priority: Blocker > Fix For: 2.6.0 > > Attachments: image-2020-12-29-15-54-00-859.png > > > In 2.5.1, Nio2 Session, handleReadCycleCompletion lacks this.close(true), > which exists in 2.4.0. > !image-2020-12-29-15-54-00-859.png! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
