[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