[jira] [Created] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
Pavel Pohner created SSHD-1173:
--
Summary: SFTP worker threads got stuck while processing PUT
methods against one specific SFTP server
Key: SSHD-1173
URL: https://issues.apache.org/jira/browse/SSHD-1173
Project: MINA SSHD
Issue Type: Question
Affects Versions: 2.6.0
Reporter: Pavel Pohner
Hey guys,
Recently I've encountered one remote SFTP server, that causes SFTP worker
threads to enter TIMED_WAITING state, from which they do not recover. Please,
take a look into this thread dump:
{code:java}
SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting on
at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
- waiting to re-lock in wait() <0x0006e3bbc420> (a
org.apache.sshd.common.channel.IoWriteFutureImpl) at
org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
at
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
com.mono.mina.command.Put.replyInto(Put.java:55) at
com.mono.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
at
com.mono.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
at
com.mono.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
Source) at
java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
at java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
{code}
Seems like the thread is waiting for lock in
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
I'm currently not sure what thread holds the lock and why it's not ever
released.
Also, I'm not able to reproduce this, but it constantly happens to all the PUT
methods targeting one specific remote server (which I don't own), so I suppose
there would be something odd with the remote server, but it doesn't mean, that
we shouldn't be able to deal with that.
Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
verify() in
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
is called without any timeout, which then defaults to LONG.MAX here: at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
shouldn't we have confirugable timeout here? or what's the point of default
timeout? what are we really waiting for in at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
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-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pohner updated SSHD-1173:
---
Description:
Hey guys,
Recently I've encountered one remote SFTP server, that causes SFTP worker
threads to enter TIMED_WAITING state, from which they do not recover. Please,
take a look into this thread dump:
{code:java}
SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting on
at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
- waiting to re-lock in wait() <0x0006e3bbc420> (a
org.apache.sshd.common.channel.IoWriteFutureImpl) at
org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
at
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
com.mono.mina.command.Put.replyInto(Put.java:55) at
com.mono.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
at
com.mono.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
at
com.mono.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
Source) at
java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
at java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
{code}
{{Seems like the thread is waiting for lock in
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
I'm currently not sure what thread holds the lock and why it's not ever
released.}}
Also, I'm not able to reproduce this, but it constantly happens to all the PUT
methods targeting one specific remote server (which I don't own), so I suppose
there would be something odd with the remote server, but it doesn't mean, that
we shouldn't be able to deal with that.
Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
verify() in
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
is called without any timeout, which then defaults to LONG.MAX here: at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
shouldn't we have confirugable timeout here? or what's the point of default
timeout? what are we really waiting for in at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
was:
Hey guys,
Recently I've encountered one remote SFTP server, that causes SFTP worker
threads to enter TIMED_WAITING state, from which they do not recover. Please,
take a look into this thread dump:
{code:java}
SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting on
at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
- waiting to re-lock in wait() <0x0006e3bbc420> (a
org.apache.sshd.common.channel.IoWriteFutureImpl) at
org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
at
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
at
org.apache.sshd.sftp.client.impl.SftpOutputStrea
[jira] [Updated] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pohner updated SSHD-1173:
---
Description:
Hey guys,
Recently I've encountered one remote SFTP server, that causes SFTP worker
threads to enter TIMED_WAITING state, from which they do not recover. Please,
take a look into this thread dump:
{code:java}
SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting on
at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
- waiting to re-lock in wait() <0x0006e3bbc420> (a
org.apache.sshd.common.channel.IoWriteFutureImpl) at
org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
at
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
com.mono.mina.command.Put.replyInto(Put.java:55) at
com.mono.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
at
com.mono.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
at
com.mono.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
Source) at
java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
at java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
{code}
Seems like the thread is waiting for lock in
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
I'm currently not sure what thread holds the lock and why it's not ever
released.
Also, I'm not able to reproduce this, but it constantly happens to all the PUT
methods targeting one specific remote server (which I don't own), so I suppose
there would be something odd with the remote server, but it doesn't mean, that
we shouldn't be able to deal with that.
Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
verify() in
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
is called without any timeout, which then defaults to LONG.MAX here: at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
shouldn't we have configurable timeout here? or what's the point of default
timeout? what are we really waiting for in at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
was:
Hey guys,
Recently I've encountered one remote SFTP server, that causes SFTP worker
threads to enter TIMED_WAITING state, from which they do not recover. Please,
take a look into this thread dump:
{code:java}
SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting on
at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
- waiting to re-lock in wait() <0x0006e3bbc420> (a
org.apache.sshd.common.channel.IoWriteFutureImpl) at
org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
at
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsy
[jira] [Updated] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pohner updated SSHD-1173:
---
Description:
Hey guys,
Recently I've encountered one remote SFTP server, that causes SFTP worker
threads to enter TIMED_WAITING state, from which they do not recover. Please,
take a look into this thread dump:
{code:java}
SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting on
at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
- waiting to re-lock in wait() <0x0006e3bbc420> (a
org.apache.sshd.common.channel.IoWriteFutureImpl) at
org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
at
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
com.mina.command.Put.replyInto(Put.java:55) at
com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251) at
com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
Source) at
java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
at java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
{code}
Seems like the thread is waiting for lock in
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
I'm currently not sure what thread holds the lock and why it's not ever
released.
Also, I'm not able to reproduce this, but it constantly happens to all the PUT
methods targeting one specific remote server (which I don't own), so I suppose
there would be something odd with the remote server, but it doesn't mean, that
we shouldn't be able to deal with that.
Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
verify() in
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
is called without any timeout, which then defaults to LONG.MAX here: at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
shouldn't we have configurable timeout here? or what's the point of default
timeout? what are we really waiting for in at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
was:
Hey guys,
Recently I've encountered one remote SFTP server, that causes SFTP worker
threads to enter TIMED_WAITING state, from which they do not recover. Please,
take a look into this thread dump:
{code:java}
SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
[0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting on
at
org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
- waiting to re-lock in wait() <0x0006e3bbc420> (a
org.apache.sshd.common.channel.IoWriteFutureImpl) at
org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
at
org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
at
org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
at
org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStr
[jira] [Commented] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17354912#comment-17354912
]
Pavel Pohner commented on SSHD-1173:
It might be the cause indeed! Thanks for your suggestion, I don't think I'm
able to verify it directly though, as I have no access to the target server
(it's owned by third party and used through our software which implements Mina,
so I don't have credentials and if I understand correctly window size is
negotiated after the authentication is done), but I will definitely try to look
into it. Are there any "less probable" causes than this one, that are worth to
check?
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Critical
> Labels: SFTP, mina, sshd
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have configurable timeout here? or what's the point of default
> timeout? what are we really waiting for in at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
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-1181) SFTP Get downloads empty file from servers which supports EOF indication after data
Pavel Pohner created SSHD-1181:
--
Summary: SFTP Get downloads empty file from servers which supports
EOF indication after data
Key: SSHD-1181
URL: https://issues.apache.org/jira/browse/SSHD-1181
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.6.0
Reporter: Pavel Pohner
So, apparently there's a bug in Mina implementation when downloading the file,
which is smaller than Mina's buffer (meaning it gets read in one iteration),
from servers, which send EOF indicator at the end of data
(https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#[section-9.3|https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-9.3]).
The bug seems to be in setting up EOF indicator in
{noformat}
org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#pollBuffer{noformat}
prematurely (one iteration sooner), trace with me this example situation -
download of the small file (14 B):
At some point we arrive to mentioned function _pollBuffer()_, note that
_this.pendingReads_ is set to 2. In first call of _pollBuffer()_ we go through
this code on receiving SSH_FXP_DATA
{code:java}
if (type == SftpConstants.SSH_FXP_DATA) {
int dlen = buf.getInt();
int rpos = buf.rpos();
buf.rpos(rpos + dlen);
Boolean b = SftpHelper.getEndOfFileIndicatorValue(buf, client.getVersion());
if ((b != null) && b.booleanValue()) {
eofIndicator = true;
}{code}
Here, consider this situation, we're downloading file with 14B, remote server
adds EOF indicator to the end of the data, so it makes 15B, let's add some
necessary overhead (size etc.) which is, according to my experience, 13B, so we
receive 15 + 13 = 28B into initial buffer.
Now, if we populate these variables, _dlen_ = 14B (file size), _rpos_ = 13
(overhead), and we set _buf.rpos_ to 27 (14 + 13), but _wpos_ is at the moment
equal to 28B, as that's what we received. (We're not taking EOF into account
here)
Then the _SftpHelper.getEndOfFileIndicatorValue_ is called, which in it's
implementation looks like this:
{code:java}
public static Boolean getEndOfFileIndicatorValue(Buffer buffer, int version) {
return (version < SftpConstants.SFTP_V6) || (buffer.available() < 1) ? null
: buffer.getBoolean();
}
{code}
Pay attention to the _buffer.available()_ function as it's implemented like
this:
{code:java}
public int available() {
return wpos - rpos;
}
{code}
therefore returning 1 (28 - 27), condition is then resolved in
_SftpHelper.getEndOfFileIndicatorValue_ as a true and true is also returned to
the _pollBuffer_ and _eofIndicator_ is set to true.
If you'd keep tracing further, you'd find out that the buffer is then never
read and returned from _SftpInputStreamAsync_ class, just because
_eofIndicator_ was set sooner than it should have been.
--
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-1181) SFTP Get downloads empty file from servers which supports EOF indication after data
[
https://issues.apache.org/jira/browse/SSHD-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363532#comment-17363532
]
Pavel Pohner commented on SSHD-1181:
[~gnodet] any ETA on 2.7.1 release?
> SFTP Get downloads empty file from servers which supports EOF indication
> after data
> ---
>
> Key: SSHD-1181
> URL: https://issues.apache.org/jira/browse/SSHD-1181
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: SFTP, mina, sshd
> Fix For: 2.7.1
>
>
> So, apparently there's a bug in Mina implementation when downloading the
> file, which is smaller than Mina's buffer (meaning it gets read in one
> iteration), from servers, which send EOF indicator at the end of data
> (https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#[section-9.3|https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-9.3]).
> The bug seems to be in setting up EOF indicator in
> {noformat}
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#pollBuffer{noformat}
> prematurely (one iteration sooner), trace with me this example situation -
> download of the small file (14 B):
> At some point we arrive to mentioned function _pollBuffer()_, note that
> _this.pendingReads_ is set to 2. In first call of _pollBuffer()_ we go
> through this code on receiving SSH_FXP_DATA
> {code:java}
> if (type == SftpConstants.SSH_FXP_DATA) {
> int dlen = buf.getInt();
> int rpos = buf.rpos();
> buf.rpos(rpos + dlen);
> Boolean b = SftpHelper.getEndOfFileIndicatorValue(buf,
> client.getVersion());
> if ((b != null) && b.booleanValue()) {
> eofIndicator = true;
> }{code}
> Here, consider this situation, we're downloading file with 14B, remote server
> adds EOF indicator to the end of the data, so it makes 15B, let's add some
> necessary overhead (size etc.) which is, according to my experience, 13B, so
> we receive 15 + 13 = 28B into initial buffer.
> Now, if we populate these variables, _dlen_ = 14B (file size), _rpos_ = 13
> (overhead), and we set _buf.rpos_ to 27 (14 + 13), but _wpos_ is at the
> moment equal to 28B, as that's what we received. (We're not taking EOF into
> account here)
> Then the _SftpHelper.getEndOfFileIndicatorValue_ is called, which in it's
> implementation looks like this:
> {code:java}
> public static Boolean getEndOfFileIndicatorValue(Buffer buffer, int version) {
> return (version < SftpConstants.SFTP_V6) || (buffer.available() < 1) ?
> null : buffer.getBoolean();
> }
> {code}
> Pay attention to the _buffer.available()_ function as it's implemented like
> this:
> {code:java}
> public int available() {
> return wpos - rpos;
> }
> {code}
> therefore returning 1 (28 - 27), condition is then resolved in
> _SftpHelper.getEndOfFileIndicatorValue_ as a true and true is also returned
> to the _pollBuffer_ and _eofIndicator_ is set to true.
> If you'd keep tracing further, you'd find out that the buffer is then never
> read and returned from _SftpInputStreamAsync_ class, just because
> _eofIndicator_ was set sooner than it should have been.
>
>
--
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-1196) sendChunkIfRemoteWindowIsSmallerThanPacketSize flag in ChannelAsyncOutputStream constructor configurable from outside using variable/config file
Pavel Pohner created SSHD-1196: -- Summary: sendChunkIfRemoteWindowIsSmallerThanPacketSize flag in ChannelAsyncOutputStream constructor configurable from outside using variable/config file Key: SSHD-1196 URL: https://issues.apache.org/jira/browse/SSHD-1196 Project: MINA SSHD Issue Type: Improvement Affects Versions: 2.7.0 Reporter: Pavel Pohner Based on this ticket: https://issues.apache.org/jira/browse/SSHD-1123 we got in version 2.7.0 this sendChunkIfRemoteWindowIsSmallerThanPacketSize flag, which can be passed into ChannelAsyncOutputStream constructor, to indicate, that chunk of the data should be send in case there's less than packetSize space left in remote window. I'd really like to have this value passed from some config or property resolver file in a similar way like the timeouts are passed, so I wouldn't need to create my own SftpClient and SftpClientFactory just to override ChannelAsyncOutputStream constructor call and set the flag to true. Adding this would significantly simplify my implementation, as I don't need to have my own implementation of SftpClient, because I'm okey with the Default one. -- 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-1331) SSH Algorithm negotiation
[
https://issues.apache.org/jira/browse/SSHD-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pohner updated SSHD-1331:
---
Description:
Hello,
I'm facing a weird issue with SSH signature algorithm negotiation:
Signature algorithms for RSA are sorted like this in my implementation:
{code:java}
List RSA_SIGNATURES = List.of(
BuiltinSignatures.rsa,
BuiltinSignatures.rsaSHA512_cert,
BuiltinSignatures.rsaSHA256_cert,
BuiltinSignatures.rsaSHA512,
BuiltinSignatures.rsaSHA256 {code}
when establishing connection with server that offers following lists of
algorithms, the connection is established without any issue:
{code:java}
ssh-rsa
rsa-sha2-512
rsa-sha2-256 {code}
but, when server with list of algorithms in following order is encountered:
{code:java}
rsa-sha2-512
rsa-sha2-256
ssh-rsa {code}
the connection fails with following exception: *KeyExchange signature
verification failed for key type=ssh-rsa*
Based on SSH RFC my current understanding is, that in the second scenario,
algorithm guessing happens, where my implementation (client), guesses the
*ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
that case the guess is not successful and there's defined algorithm that must
be followed (basically, client iterating over the common list of algorithms
until finding the correct match) -
[https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
This seems to not be the case though as the exception says that the signature
verification failed for *ssh-rsa,* I would expect the implementation to iterate
to the {*}{*}{*}rsa-sha2-512{*} and match the server's guessed algorithm.
How is this handled in Mina SSHD implementation? Is this something I can
override/handle in my own implementation? Can someone point me in the right
direction please?
was:
Hello,
I'm facing a weird issue with SSH signature algorithm negotiation:
Signature algorithms for RSA are sorted like this in my implementation:
{code:java}
List RSA_SIGNATURES = List.of(
BuiltinSignatures.rsa,
BuiltinSignatures.rsaSHA512_cert,
BuiltinSignatures.rsaSHA256_cert,
BuiltinSignatures.rsaSHA512,
BuiltinSignatures.rsaSHA256 {code}
when establishing connection with server that offers following lists of
algorithms, the connection is established without any issue:
{code:java}
ssh-rsa
rsa-sha2-512
rsa-sha2-256 {code}
but, when server with list of algorithms in following order is encountered:
{code:java}
rsa-sha2-512
rsa-sha2-256
ssh-rsa {code}
the connection fails with following exception: *KeyExchange signature
verification failed for key type=ssh-rsa*
Based on SSH RFC my current understanding is, that in the second scenario,
algorithm guessing happens, where my implementation (client), guesses the
*ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
that case the guess is not successful and there's defined algorithm that must
be followed (basically, client iterating over the common list of algorithms
until finding the correct match) -
[https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
This seems to not be the case though as the exception says that the signature
verification failed for *ssh-rsa,* I would expect the implementation to iterate
to the {*}{*}{*}rsa-sha2-512{*} and match the server's guessed algorithm.
How is this handled in Mina SSHD implementation? Is this something I can
override/handle in my own implementation? Can someone point me in the right
direction please?
> SSH Algorithm negotiation
> --
>
> Key: SSHD-1331
> URL: https://issues.apache.org/jira/browse/SSHD-1331
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.9.2
>Reporter: Pavel Pohner
>Priority: Major
>
> Hello,
> I'm facing a weird issue with SSH signature algorithm negotiation:
> Signature algorithms for RSA are sorted like this in my implementation:
>
> {code:java}
> List RSA_SIGNATURES = List.of(
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsaSHA512_cert,
> BuiltinSignatures.rsaSHA256_cert,
> BuiltinSignatures.rsaSHA512,
> BuiltinSignatures.rsaSHA256 {code}
> when establishing connection with server that offers following lists of
> algorithms, the connection is established without any issue:
>
>
> {code:java}
> ssh-rsa
> rsa-sha2-512
> rsa-sha2-256 {code}
> but, when server with list of algorithms in following order is encountered:
> {code:java}
> rsa-sha2-512
> rsa-sha2-256
> ssh-rsa {code}
> the connection fails with following exception: *KeyExchange signature
> verification failed for key type=ssh-rsa*
> Based on SSH RFC my current understanding is, that in the second scenario,
> algorithm guessing happens, where my implementation (client), guesses the
> *ssh-rsa* algorithm, mea
[jira] [Updated] (SSHD-1331) SSH Algorithm negotiation
[
https://issues.apache.org/jira/browse/SSHD-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pohner updated SSHD-1331:
---
Description:
Hello,
I'm facing a weird issue with SSH signature algorithm negotiation:
Signature algorithms for RSA are sorted like this in my implementation:
{code:java}
List RSA_SIGNATURES = List.of(
BuiltinSignatures.rsa,
BuiltinSignatures.rsaSHA512_cert,
BuiltinSignatures.rsaSHA256_cert,
BuiltinSignatures.rsaSHA512,
BuiltinSignatures.rsaSHA256 {code}
when establishing connection with server that offers following lists of
algorithms, the connection is established without any issue:
{code:java}
ssh-rsa
rsa-sha2-512
rsa-sha2-256 {code}
but, when server with list of algorithms in following order is encountered:
{code:java}
rsa-sha2-512
rsa-sha2-256
ssh-rsa {code}
the connection fails with following exception: *KeyExchange signature
verification failed for key type=ssh-rsa*
Based on SSH RFC my current understanding is, that in the second scenario,
algorithm guessing happens, where my implementation (client), guesses the
*ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
that case the guess is not successful and there's defined algorithm that must
be followed (basically, client iterating over the common list of algorithms
until finding the correct match) -
[https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
This seems to not be the case though as the exception says that the signature
verification failed for *ssh-rsa,* I would expect the implementation to iterate
to the *rsa-sha2-512* and match the server's guessed algorithm.
How is this handled in Mina SSHD implementation? Is this something I can
override/handle in my own implementation? Can someone point me in the right
direction please?
was:
Hello,
I'm facing a weird issue with SSH signature algorithm negotiation:
Signature algorithms for RSA are sorted like this in my implementation:
{code:java}
List RSA_SIGNATURES = List.of(
BuiltinSignatures.rsa,
BuiltinSignatures.rsaSHA512_cert,
BuiltinSignatures.rsaSHA256_cert,
BuiltinSignatures.rsaSHA512,
BuiltinSignatures.rsaSHA256 {code}
when establishing connection with server that offers following lists of
algorithms, the connection is established without any issue:
{code:java}
ssh-rsa
rsa-sha2-512
rsa-sha2-256 {code}
but, when server with list of algorithms in following order is encountered:
{code:java}
rsa-sha2-512
rsa-sha2-256
ssh-rsa {code}
the connection fails with following exception: *KeyExchange signature
verification failed for key type=ssh-rsa*
Based on SSH RFC my current understanding is, that in the second scenario,
algorithm guessing happens, where my implementation (client), guesses the
*ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
that case the guess is not successful and there's defined algorithm that must
be followed (basically, client iterating over the common list of algorithms
until finding the correct match) -
[https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
This seems to not be the case though as the exception says that the signature
verification failed for *ssh-rsa,* I would expect the implementation to iterate
to the {*}{*}{*}rsa-sha2-512{*} and match the server's guessed algorithm.
How is this handled in Mina SSHD implementation? Is this something I can
override/handle in my own implementation? Can someone point me in the right
direction please?
> SSH Algorithm negotiation
> --
>
> Key: SSHD-1331
> URL: https://issues.apache.org/jira/browse/SSHD-1331
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.9.2
>Reporter: Pavel Pohner
>Priority: Major
>
> Hello,
> I'm facing a weird issue with SSH signature algorithm negotiation:
> Signature algorithms for RSA are sorted like this in my implementation:
>
> {code:java}
> List RSA_SIGNATURES = List.of(
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsaSHA512_cert,
> BuiltinSignatures.rsaSHA256_cert,
> BuiltinSignatures.rsaSHA512,
> BuiltinSignatures.rsaSHA256 {code}
> when establishing connection with server that offers following lists of
> algorithms, the connection is established without any issue:
>
>
> {code:java}
> ssh-rsa
> rsa-sha2-512
> rsa-sha2-256 {code}
> but, when server with list of algorithms in following order is encountered:
> {code:java}
> rsa-sha2-512
> rsa-sha2-256
> ssh-rsa {code}
> the connection fails with following exception: *KeyExchange signature
> verification failed for key type=ssh-rsa*
> Based on SSH RFC my current understanding is, that in the second scenario,
> algorithm guessing happens, where my implementation (client), guesses the
> *ssh-rsa* algorithm, meanwhile the
[jira] [Created] (SSHD-1331) SSH Algorithm negotiation
Pavel Pohner created SSHD-1331:
--
Summary: SSH Algorithm negotiation
Key: SSHD-1331
URL: https://issues.apache.org/jira/browse/SSHD-1331
Project: MINA SSHD
Issue Type: Question
Affects Versions: 2.9.2
Reporter: Pavel Pohner
Hello,
I'm facing a weird issue with SSH signature algorithm negotiation:
Signature algorithms for RSA are sorted like this in my implementation:
{code:java}
List RSA_SIGNATURES = List.of(
BuiltinSignatures.rsa,
BuiltinSignatures.rsaSHA512_cert,
BuiltinSignatures.rsaSHA256_cert,
BuiltinSignatures.rsaSHA512,
BuiltinSignatures.rsaSHA256 {code}
when establishing connection with server that offers following lists of
algorithms, the connection is established without any issue:
{code:java}
ssh-rsa
rsa-sha2-512
rsa-sha2-256 {code}
but, when server with list of algorithms in following order is encountered:
{code:java}
rsa-sha2-512
rsa-sha2-256
ssh-rsa {code}
the connection fails with following exception: *KeyExchange signature
verification failed for key type=ssh-rsa*
Based on SSH RFC my current understanding is, that in the second scenario,
algorithm guessing happens, where my implementation (client), guesses the
*ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
that case the guess is not successful and there's defined algorithm that must
be followed (basically, client iterating over the common list of algorithms
until finding the correct match) -
[https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
This seems to not be the case though as the exception says that the signature
verification failed for *ssh-rsa,* I would expect the implementation to iterate
to the {*}{*}{*}rsa-sha2-512{*} and match the server's guessed algorithm.
How is this handled in Mina SSHD implementation? Is this something I can
override/handle in my own implementation? Can someone point me in the right
direction please?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1331) SSH Algorithm negotiation
[
https://issues.apache.org/jira/browse/SSHD-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pohner updated SSHD-1331:
---
Description:
Hello,
I'm facing a weird issue with SSH signature algorithm negotiation:
Signature algorithms for RSA are sorted like this in my implementation:
{code:java}
List RSA_SIGNATURES = List.of(
BuiltinSignatures.rsa,
BuiltinSignatures.rsaSHA512_cert,
BuiltinSignatures.rsaSHA256_cert,
BuiltinSignatures.rsaSHA512,
BuiltinSignatures.rsaSHA256 {code}
when establishing connection with server that offers following lists of
algorithms, the connection is established without any issue:
{code:java}
ssh-rsa
rsa-sha2-512
rsa-sha2-256 {code}
but, when server with list of algorithms in following order is encountered:
{code:java}
rsa-sha2-512
rsa-sha2-256
ssh-rsa {code}
the connection fails with following exception: *KeyExchange signature
verification failed for key type=ssh-rsa*
Based on SSH RFC my current understanding is, that in the second scenario,
algorithm guessing happens, where my implementation (client), guesses the
*ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
that case the guess is not successful and there's defined algorithm that must
be followed (basically, client iterating over the common list of algorithms
until finding the correct match) -
[https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
This seems to not be the case though as the exception says that the signature
verification failed for *ssh-rsa,* I would expect the implementation to iterate
to the *rsa-sha2-512* and match the server's guessed algorithm.
How is this handled in Mina SSHD implementation? Is this something I can
override/handle in my own implementation? Can someone point me in the right
direction please?
was:
Hello,
I'm facing a weird issue with SSH signature algorithm negotiation:
Signature algorithms for RSA are sorted like this in my implementation:
{code:java}
List RSA_SIGNATURES = List.of(
BuiltinSignatures.rsa,
BuiltinSignatures.rsaSHA512_cert,
BuiltinSignatures.rsaSHA256_cert,
BuiltinSignatures.rsaSHA512,
BuiltinSignatures.rsaSHA256 {code}
when establishing connection with server that offers following lists of
algorithms, the connection is established without any issue:
{code:java}
ssh-rsa
rsa-sha2-512
rsa-sha2-256 {code}
but, when server with list of algorithms in following order is encountered:
{code:java}
rsa-sha2-512
rsa-sha2-256
ssh-rsa {code}
the connection fails with following exception: *KeyExchange signature
verification failed for key type=ssh-rsa*
Based on SSH RFC my current understanding is, that in the second scenario,
algorithm guessing happens, where my implementation (client), guesses the
*ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
that case the guess is not successful and there's defined algorithm that must
be followed (basically, client iterating over the common list of algorithms
until finding the correct match) -
[https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
This seems to not be the case though as the exception says that the signature
verification failed for *ssh-rsa,* I would expect the implementation to iterate
to the *rsa-sha2-512* and match the server's guessed algorithm.
How is this handled in Mina SSHD implementation? Is this something I can
override/handle in my own implementation? Can someone point me in the right
direction please?
> SSH Algorithm negotiation
> --
>
> Key: SSHD-1331
> URL: https://issues.apache.org/jira/browse/SSHD-1331
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.9.2
>Reporter: Pavel Pohner
>Priority: Major
>
> Hello,
> I'm facing a weird issue with SSH signature algorithm negotiation:
> Signature algorithms for RSA are sorted like this in my implementation:
>
> {code:java}
> List RSA_SIGNATURES = List.of(
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsaSHA512_cert,
> BuiltinSignatures.rsaSHA256_cert,
> BuiltinSignatures.rsaSHA512,
> BuiltinSignatures.rsaSHA256 {code}
> when establishing connection with server that offers following lists of
> algorithms, the connection is established without any issue:
> {code:java}
> ssh-rsa
> rsa-sha2-512
> rsa-sha2-256 {code}
> but, when server with list of algorithms in following order is encountered:
> {code:java}
> rsa-sha2-512
> rsa-sha2-256
> ssh-rsa {code}
> the connection fails with following exception: *KeyExchange signature
> verification failed for key type=ssh-rsa*
> Based on SSH RFC my current understanding is, that in the second scenario,
> algorithm guessing happens, where my implementation (client), guesses the
> *ssh-rsa* algorithm, meanwhile the server guesses the {*}rs
[jira] [Resolved] (SSHD-1331) SSH Algorithm negotiation
[
https://issues.apache.org/jira/browse/SSHD-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pohner resolved SSHD-1331.
Resolution: Information Provided
Thanks a lot, [~twolf], I suppose that makes more sense. I'll try reordering
the signature algorithms then.
> SSH Algorithm negotiation
> --
>
> Key: SSHD-1331
> URL: https://issues.apache.org/jira/browse/SSHD-1331
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.9.2
>Reporter: Pavel Pohner
>Priority: Major
>
> Hello,
> I'm facing a weird issue with SSH signature algorithm negotiation:
> Signature algorithms for RSA are sorted like this in my implementation:
>
> {code:java}
> List RSA_SIGNATURES = List.of(
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsaSHA512_cert,
> BuiltinSignatures.rsaSHA256_cert,
> BuiltinSignatures.rsaSHA512,
> BuiltinSignatures.rsaSHA256 {code}
> when establishing connection with server that offers following lists of
> algorithms, the connection is established without any issue:
> {code:java}
> ssh-rsa
> rsa-sha2-512
> rsa-sha2-256 {code}
> but, when server with list of algorithms in following order is encountered:
> {code:java}
> rsa-sha2-512
> rsa-sha2-256
> ssh-rsa {code}
> the connection fails with following exception: *KeyExchange signature
> verification failed for key type=ssh-rsa*
> Based on SSH RFC my current understanding is, that in the second scenario,
> algorithm guessing happens, where my implementation (client), guesses the
> *ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
> that case the guess is not successful and there's defined algorithm that must
> be followed (basically, client iterating over the common list of algorithms
> until finding the correct match) -
> [https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
> This seems to not be the case though as the exception says that the signature
> verification failed for *ssh-rsa,* I would expect the implementation to
> iterate to the *rsa-sha2-512* and match the server's guessed algorithm.
> How is this handled in Mina SSHD implementation? Is this something I can
> override/handle in my own implementation? Can someone point me in the right
> direction please?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
