[jira] [Commented] (SSHD-957) See if need to add code to support ProxyJump mode
[
https://issues.apache.org/jira/browse/SSHD-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990959#comment-16990959
]
Lyor Goldstein commented on SSHD-957:
-
Seems that {{port_open_helper}} is called with the channel that was initialized
for "stdio-forwarding" purposes
> See if need to add code to support ProxyJump mode
> -
>
> Key: SSHD-957
> URL: https://issues.apache.org/jira/browse/SSHD-957
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Lyor Goldstein
>Priority: Minor
>
> According to
> [channels.c|https://github.com/openssh/openssh-portable/blob/master/channels.c]
> and [ssh.c|https://github.com/openssh/openssh-portable/blob/master/ssh.c]
> using the _-J_ flag one can open a "jump" from one server to another. This is
> done by
> {quote}
> This connects stdio on the client to a single port forward on the server.
> This allows, for example, using ssh as a ProxyCommand to route connections
> via intermediate servers.
> {quote}
> This seems to involve opening a "stdio-forward" channel - though the details
> on the client/server are a bit sketchy:
> * Is it a new kind of channel ?
> * What does "connecting stdio to port forward" mean ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-957) See if need to add code to support ProxyJump mode
[
https://issues.apache.org/jira/browse/SSHD-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990959#comment-16990959
]
Lyor Goldstein edited comment on SSHD-957 at 12/8/19 6:54 PM:
--
Seems that {{port_open_helper("direct-tcpip")}} is called with the channel that
was initialized for "stdio-forwarding" purposes
was (Author: lgoldstein):
Seems that {{port_open_helper}} is called with the channel that was initialized
for "stdio-forwarding" purposes
> See if need to add code to support ProxyJump mode
> -
>
> Key: SSHD-957
> URL: https://issues.apache.org/jira/browse/SSHD-957
> Project: MINA SSHD
> Issue Type: Improvement
> Affects Versions: 2.3.0
>Reporter: Lyor Goldstein
>Priority: Minor
>
> According to
> [channels.c|https://github.com/openssh/openssh-portable/blob/master/channels.c]
> and [ssh.c|https://github.com/openssh/openssh-portable/blob/master/ssh.c]
> using the _-J_ flag one can open a "jump" from one server to another. This is
> done by
> {quote}
> This connects stdio on the client to a single port forward on the server.
> This allows, for example, using ssh as a ProxyCommand to route connections
> via intermediate servers.
> {quote}
> This seems to involve opening a "stdio-forward" channel - though the details
> on the client/server are a bit sketchy:
> * Is it a new kind of channel ?
> * What does "connecting stdio to port forward" mean ?
--
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-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036360#comment-17036360
]
Lyor Goldstein commented on SSHD-966:
-
Thanks - I'll see when I can get to it - meanwhile you did gain something - you
upgraded to the latest version of SSHD...
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
> Assignee: Lyor Goldstein
>Priority: Major
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:646)
>
> java.util.concu
[jira] [Commented] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042993#comment-17042993
]
Lyor Goldstein commented on SSHD-968:
-
Have you tried using the
[SSH_MSG_IGNORE|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic]
mechanism instead of global requests ?
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043001#comment-17043001
]
Lyor Goldstein commented on SSHD-968:
-
{quote}
This is true, but the server is netopeer-server, used by a lot of people,
replying with "sorry this is a server issue", is not an option for us. Further,
the bug is not in netopeer itself, but in libssh, which is one of the most
common ssh libraries for linux (openssh works just fine though). I must assume
this is fixed in the latest release, but I suppose there are thousands of
servers out there not yet upgraded.
{quote}
I understand and empathize - but our R resources are extremely scarce - so we
have to invest them where the vast majority of users are, I am not sure how
many "used by a lot of people" is in this case since this is the 1st time we
encountered this request. Perhaps in a specific niche netopeer-server is very
popular, but in the server world OpenSSH is most widely used, and we interact
with it smoothly.
{quote}
One of your comments is lost now, but knowing what message returning
SSH_MSG_UNIMPLEMENTED can be done using the message ID. The
SSH_MSG_UNIMPLEMENTED will return the message ID for the message it sent
SSH_MSG_UNIMPLEMENTED for.
{quote}
Seems an avenue for a fix, but it's not as simple as that since the sent
message ID of the {{SSH_MSG_GLOBAL_REQUEST}} is not exposed for the heartbeat
code. Furthermore, some non-trivial tracking logic is required as well,
Bottom line - I will look into it (in the very little spare time I have) but I
doubt very much that an easy/quick solution is available. I know it's not
much, but we welcome contributions and you are welcome to write a solution if
you can afford the R effort. Let me warn you though that the code flow is
not trivial to follow - even for us who maintain it.
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
> Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
This message was sent
[jira] [Commented] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043003#comment-17043003
]
Lyor Goldstein commented on SSHD-968:
-
I am afraid I don't have good news - I have examined the code in the hopes that
we can somehow expose the sequence number of the sent message. While it is
technically possible it poses many challenges especially to the encode/decode
loops - which are at the very heart of the packets management mechanism. I am
not sure the benefit is worth the risk at this time...
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044705#comment-17044705
]
Lyor Goldstein commented on SSHD-968:
-
Sorry - I take it back - I think it won't work. The reason is that
{{writePacket}} might actually write out 2 packets instead of one due to
"message stuffing" using {{SSH_MSG_IDLE}} (part of the security
recommendations). If you want to capture the real outgoing sequence number it
must occur in {{encode(Buffer)}}.
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Guillaume Nodet
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044658#comment-17044658
]
Lyor Goldstein edited comment on SSHD-968 at 2/25/20 5:51 PM:
--
Very elegant - 2 small remarks though (see comment in the commit). [~patrikek]
can you test this fix ?
was (Author: lgoldstein):
Very elegant - one small remark though (see comment in the commit). [~patrikek]
can you test this fix ?
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Guillaume Nodet
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044658#comment-17044658
]
Lyor Goldstein commented on SSHD-968:
-
Very elegant - one small remark though (see comment in the commit). [~patrikek]
can you test this fix ?
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Guillaume Nodet
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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] [Work started] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-968 started by Lyor Goldstein.
---
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-970) transferTo function of SftpRemotePathChannel will loop if count parameter is greater than file size
[
https://issues.apache.org/jira/browse/SSHD-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein closed SSHD-970.
---
Fix Version/s: 2.4.1
Assignee: Lyor Goldstein (was: Guillaume Nodet)
Resolution: Duplicate
Duplicate of SSHD-967 - already fixed
> transferTo function of SftpRemotePathChannel will loop if count parameter is
> greater than file size
> ---
>
> Key: SSHD-970
> URL: https://issues.apache.org/jira/browse/SSHD-970
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.1
>Reporter: Michele Milesi
> Assignee: Lyor Goldstein
>Priority: Major
> Labels: patch
> Fix For: 2.4.1
>
> Attachments: SftpRemotePathChannel.patch
>
>
> The method {{transferTo}} of {{SftpRemotePathChannel}} does not checks
> {{eof}} condition.
> * The exit condition from the reading loop is that totalRead variable is not
> less than count parameter.
> * At eof the value the method does not increment the totalRead variable
> * If {{count}} parameter value is greater than source file size the value of
> {{totalRead}} will never reach the {{count}} value
> In order to exit from the loop we need to check the eof condition.
> The attached patch contains:
> * A junit test (added to SftpRemotePathChannelTest.java)
> * A simple fix to the exit condition
> The problem was found on:
> * 2.4.0 released version
> * current git head
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046340#comment-17046340
]
Lyor Goldstein commented on SSHD-968:
-
I am using the test you wrote to make sure the problem is fixed (BTW, it had a
slight error since it did not restore the {{HEARTBEAT_REPLY_WAIT}} value in
the {{tearDown}} method, thus causing some other tests to fail if it ran before
them.
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-970) transferTo function of SftpRemotePathChannel will loop if count parameter is greater than file size
[
https://issues.apache.org/jira/browse/SSHD-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046374#comment-17046374
]
Lyor Goldstein commented on SSHD-970:
-
Yes - I believe you are right - good catch...
> transferTo function of SftpRemotePathChannel will loop if count parameter is
> greater than file size
> ---
>
> Key: SSHD-970
> URL: https://issues.apache.org/jira/browse/SSHD-970
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.1
>Reporter: Michele Milesi
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: patch
> Fix For: 2.4.1
>
> Attachments: SftpRemotePathChannel.patch
>
>
> The method {{transferTo}} of {{SftpRemotePathChannel}} does not checks
> {{eof}} condition.
> * The exit condition from the reading loop is that totalRead variable is not
> less than count parameter.
> * At eof the value the method does not increment the totalRead variable
> * If {{count}} parameter value is greater than source file size the value of
> {{totalRead}} will never reach the {{count}} value
> In order to exit from the loop we need to check the eof condition.
> The attached patch contains:
> * A junit test (added to SftpRemotePathChannelTest.java)
> * A simple fix to the exit condition
> The problem was found on:
> * 2.4.0 released version
> * current git head
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046313#comment-17046313
]
Lyor Goldstein commented on SSHD-968:
-
The suggested fix seems to involve too many methods changes - not mention the
fact that the extra argument is very specific to this issue. What if future
fixes require more argument ? However, your fix has given me an idea I would
like to explore that may provide (IMO) a better solution. Be patient for 1-2
days and I might have something.
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Guillaume Nodet
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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] [Assigned] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-968:
---
Assignee: Lyor Goldstein (was: Guillaume Nodet)
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-967) transferTo function of SftpRemotePathChannel always add some extra bytes in the end of file
[ https://issues.apache.org/jira/browse/SSHD-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-967. - Resolution: Fixed [~nitinranjan] you have not answered, so I am merging it in based on the unit tests I have written to cover this use-case > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > --- > > Key: SSHD-967 > URL: https://issues.apache.org/jira/browse/SSHD-967 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Nitin Ranjan > Assignee: Lyor Goldstein >Priority: Major > Fix For: 2.4.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > > I have tried to transfer gz file from sftp server after transfer when I tried > to decompress it it was giving warning > *decompression ok trailing garbage ignored* > > When I checked the file I found some extra bytes appended to the file > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-970) transferTo function of SftpRemotePathChannel will loop if count parameter is greater than file size
[
https://issues.apache.org/jira/browse/SSHD-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046374#comment-17046374
]
Lyor Goldstein edited comment on SSHD-970 at 2/27/20 9:17 AM:
--
Yes - I believe you are right - good catch... but this seems to relate to line
358 - are we looking at the same code ? Have you fetched the latest _master_
version ?
was (Author: lgoldstein):
Yes - I believe you are right - good catch...
> transferTo function of SftpRemotePathChannel will loop if count parameter is
> greater than file size
> ---
>
> Key: SSHD-970
> URL: https://issues.apache.org/jira/browse/SSHD-970
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.1
>Reporter: Michele Milesi
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: patch
> Fix For: 2.4.1
>
> Attachments: SftpRemotePathChannel.patch
>
>
> The method {{transferTo}} of {{SftpRemotePathChannel}} does not checks
> {{eof}} condition.
> * The exit condition from the reading loop is that totalRead variable is not
> less than count parameter.
> * At eof the value the method does not increment the totalRead variable
> * If {{count}} parameter value is greater than source file size the value of
> {{totalRead}} will never reach the {{count}} value
> In order to exit from the loop we need to check the eof condition.
> The attached patch contains:
> * A junit test (added to SftpRemotePathChannelTest.java)
> * A simple fix to the exit condition
> The problem was found on:
> * 2.4.0 released version
> * current git head
--
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-971) Add authorized_keys/verification support for OpenSSH "security key" key types
Lyor Goldstein created SSHD-971: --- Summary: Add authorized_keys/verification support for OpenSSH "security key" key types Key: SSHD-971 URL: https://issues.apache.org/jira/browse/SSHD-971 Project: MINA SSHD Issue Type: New Feature Reporter: Lyor Goldstein Assignee: Lyor Goldstein See [https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f] -- 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] [Work started] (SSHD-971) Add authorized_keys/verification support for OpenSSH "security key" key types
[ https://issues.apache.org/jira/browse/SSHD-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-971 started by Lyor Goldstein. --- > Add authorized_keys/verification support for OpenSSH "security key" key types > - > > Key: SSHD-971 > URL: https://issues.apache.org/jira/browse/SSHD-971 > Project: MINA SSHD > Issue Type: New Feature > Reporter: Lyor Goldstein >Assignee: Lyor Goldstein >Priority: Major > > See [https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f] -- 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] [Work started] (SSHD-972) Add support for peers using OpenSSH "security key" key types
[ https://issues.apache.org/jira/browse/SSHD-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-972 started by Lyor Goldstein. --- > Add support for peers using OpenSSH "security key" key types > > > Key: SSHD-972 > URL: https://issues.apache.org/jira/browse/SSHD-972 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Ian Haken >Assignee: Lyor Goldstein >Priority: Major > > The latest OpenSSH release adds support for new key types which enable use of > hardware security keys. Details of the new key types are available > [here|https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f]. > It would be helpeful for SSHD to support authorized_keys files with the key > types and clients using public key authentication with these key types. > A PR has been opened to add support for these key types > [here|https://github.com/apache/mina-sshd/pull/116]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-971) Add authorized_keys/verification support for OpenSSH "security key" key types
[ https://issues.apache.org/jira/browse/SSHD-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-971. --- Resolution: Duplicate Duplicates SSHD-972 > Add authorized_keys/verification support for OpenSSH "security key" key types > - > > Key: SSHD-971 > URL: https://issues.apache.org/jira/browse/SSHD-971 > Project: MINA SSHD > Issue Type: New Feature > Reporter: Lyor Goldstein >Assignee: Lyor Goldstein >Priority: Major > > See [https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f] -- 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] [Assigned] (SSHD-972) Add support for peers using OpenSSH "security key" key types
[ https://issues.apache.org/jira/browse/SSHD-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-972: --- Assignee: Lyor Goldstein > Add support for peers using OpenSSH "security key" key types > > > Key: SSHD-972 > URL: https://issues.apache.org/jira/browse/SSHD-972 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Ian Haken >Assignee: Lyor Goldstein >Priority: Major > > The latest OpenSSH release adds support for new key types which enable use of > hardware security keys. Details of the new key types are available > [here|https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f]. > It would be helpeful for SSHD to support authorized_keys files with the key > types and clients using public key authentication with these key types. > A PR has been opened to add support for these key types > [here|https://github.com/apache/mina-sshd/pull/116]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-972) Add support for peers using OpenSSH "security key" key types
[ https://issues.apache.org/jira/browse/SSHD-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-972. - Fix Version/s: 2.4.1 Resolution: Fixed > Add support for peers using OpenSSH "security key" key types > > > Key: SSHD-972 > URL: https://issues.apache.org/jira/browse/SSHD-972 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Ian Haken >Assignee: Lyor Goldstein >Priority: Major > Fix For: 2.4.1 > > > The latest OpenSSH release adds support for new key types which enable use of > hardware security keys. Details of the new key types are available > [here|https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f]. > It would be helpeful for SSHD to support authorized_keys files with the key > types and clients using public key authentication with these key types. > A PR has been opened to add support for these key types > [here|https://github.com/apache/mina-sshd/pull/116]. -- 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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[ https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020431#comment-17020431 ] Lyor Goldstein commented on SSHD-964: - Thanks [~roberto.deandrea] I will consider this change - as well as maybe some other options. This may take some time though since I am extremely busy and I would like to award this issue some thorough thinking... > SSH_MSG_CHANNEL_EOF never sent or received for local and remote port > forwarding > --- > > Key: SSHD-964 > URL: https://issues.apache.org/jira/browse/SSHD-964 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.3.0, 2.3.1 >Reporter: Roberto Deandrea > Assignee: Lyor Goldstein >Priority: Major > > We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for > local and remote port forwarding connections. > We found probably the issue and we changed the code locally in a couple of > java classes to fix this issue. > Let me know if we can commit our changes in a pull request (into a specific > Apache SSHD branch) so that you can peer review the changes and decide if > you can accept them... > > Kind Regards > Roberto Deandrea > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-969) compatibility problem with cisco-2.0 ssh on ios-xr
[
https://issues.apache.org/jira/browse/SSHD-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046686#comment-17046686
]
Lyor Goldstein edited comment on SSHD-969 at 2/27/20 2:42 PM:
--
{quote}
I noticed that Mina SSH sends msg 50 (SSH_MSG_USERAUTH_REQUEST) before key
exchange completes
{quote}
I cannot figure out what scenario can lead to this - authentication messages
are exchanged +after+ keys have been exchanged - never over insecure channel.
We have such checks in code:
{code:java}
@Override
public Boolean doAuth(Buffer buffer, boolean init) throws Exception {
ValidateUtils.checkTrue(init, "Instance not initialized");
ServerSession session = getServerSession();
if (!UserAuthMethodFactory.isSecureAuthenticationTransport(session)) {
if (log.isDebugEnabled()) {
log.debug("doAuth({}) session is not secure", session);
}
return false;
}
{code}
Note that even by your own log, the {{SSH_MSG_USERAUTH_REQUEST}} is not sent -
it is +enqueued +to be sent when KEX completed:
{quote}
2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG
o.a.s.c.session.ClientSessionImpl:808 -
writePacket(ClientSessionImpl[cisco@/10.90.10.193:22])[SSH_MSG_USERAUTH_REQUEST]
Start flagging packets as pending until key exchange is done
{quote}
It may be the case that the server has some kind of race condition and has not
yet updated its internal state that KEX is completed when
{{SSH_MSG_USERAUTH_REQUEST}} arrives. Anyway, you have not mentioned what MINA
SSHD version you are using. Please try the latest one.
Another thing to notice is that some servers behave in a special way and expect
flows that are not always standard. To that effect, try and activate the
"delayed KEX" option in our code (see [this
link|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#configuring-the-protocol-exchange-phase]).
This option delays KEX from the client side until the server has sent its
identification first. I suspect this is the real culprit - anyway, it might not
fix this issue entirely, but perhaps it may introduce enough of a delay to
overcome the suspected race condition in the server.
was (Author: lgoldstein):
{quote}
I noticed that Mina SSH sends msg 50 (SSH_MSG_USERAUTH_REQUEST) before key
exchange completes
{quote}
I cannot figure out what scenario can lead to this - authentication messages
are exchanged +after+ keys have been exchanged - never over insecure channel.
We have such checks in code:
{code:java}
@Override
public Boolean doAuth(Buffer buffer, boolean init) throws Exception {
ValidateUtils.checkTrue(init, "Instance not initialized");
ServerSession session = getServerSession();
if (!UserAuthMethodFactory.isSecureAuthenticationTransport(session)) {
if (log.isDebugEnabled()) {
log.debug("doAuth({}) session is not secure", session);
}
return false;
}
{code}
Note that even by your own log, the {{SSH_MSG_USERAUTH_REQUEST}} is not sent -
it is +enqueued +to be sent when KEX completed:
{quote}
2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG
o.a.s.c.session.ClientSessionImpl:808 -
writePacket(ClientSessionImpl[cisco@/10.90.10.193:22])[SSH_MSG_USERAUTH_REQUEST]
Start flagging packets as pending until key exchange is done
{quote}
It may be the case that the server has some kind of race condition and has not
yet updated its internal state that KEX is completed when
{{SSH_MSG_USERAUTH_REQUEST}} arrives. Anyway, you have not mentioned what MINA
SSHD version you are using. Please try the latest one.
Another thing to notice is that some servers behave in a special way and expect
flows that are not always standard. To that effect, try and activate the
"delayed KEX" option in our code (see [this
link|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#configuring-the-protocol-exchange-phase]).
This option delays KEX from the client side until the server has sent its
identification first. It might fix this issue entirely, but perhaps it may
introduce enough of a delay to overcome the suspected race condition in the
server.
> compatibility problem with cisco-2.0 ssh on ios-xr
> ---
>
> Key: SSHD-969
> URL: https://issues.apache.org/jira/browse/SSHD-969
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Yuefeng
>Priority: Major
>
> When mina ssh library is used to connect with a Cisco IOS-XR device, the
> connection is consistently reset by IOS-XR, here's mina log
>
>
> {code:java}
> 2020-02-25 20:12:15.531Z [sshd-SshClient[468ca10d]-nio2-thread-1] DEBUG
&
[jira] [Comment Edited] (SSHD-969) compatibility problem with cisco-2.0 ssh on ios-xr
[
https://issues.apache.org/jira/browse/SSHD-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046686#comment-17046686
]
Lyor Goldstein edited comment on SSHD-969 at 2/27/20 2:41 PM:
--
{quote}
I noticed that Mina SSH sends msg 50 (SSH_MSG_USERAUTH_REQUEST) before key
exchange completes
{quote}
I cannot figure out what scenario can lead to this - authentication messages
are exchanged +after+ keys have been exchanged - never over insecure channel.
We have such checks in code:
{code:java}
@Override
public Boolean doAuth(Buffer buffer, boolean init) throws Exception {
ValidateUtils.checkTrue(init, "Instance not initialized");
ServerSession session = getServerSession();
if (!UserAuthMethodFactory.isSecureAuthenticationTransport(session)) {
if (log.isDebugEnabled()) {
log.debug("doAuth({}) session is not secure", session);
}
return false;
}
{code}
Note that even by your own log, the {{SSH_MSG_USERAUTH_REQUEST}} is not sent -
it is +enqueued +to be sent when KEX completed:
{quote}
2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG
o.a.s.c.session.ClientSessionImpl:808 -
writePacket(ClientSessionImpl[cisco@/10.90.10.193:22])[SSH_MSG_USERAUTH_REQUEST]
Start flagging packets as pending until key exchange is done
{quote}
It may be the case that the server has some kind of race condition and has not
yet updated its internal state that KEX is completed when
{{SSH_MSG_USERAUTH_REQUEST}} arrives. Anyway, you have not mentioned what MINA
SSHD version you are using. Please try the latest one.
Another thing to notice is that some servers behave in a special way and expect
flows that are not always standard. To that effect, try and activate the
"delayed KEX" option in our code (see [this
link|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#configuring-the-protocol-exchange-phase]).
This option delays KEX from the client side until the server has sent its
identification first. It might fix this issue entirely, but perhaps it may
introduce enough of a delay to overcome the suspected race condition in the
server.
was (Author: lgoldstein):
{quote}
I noticed that Mina SSH sends msg 50 (SSH_MSG_USERAUTH_REQUEST) before key
exchange completes
{quote}
I cannot figure out what scenario can lead to this - authentication messages
are exchanged +after+ keys have been exchanged - never over insecure channel.
We have such checks in code:
{code:java}
@Override
public Boolean doAuth(Buffer buffer, boolean init) throws Exception {
ValidateUtils.checkTrue(init, "Instance not initialized");
ServerSession session = getServerSession();
if (!UserAuthMethodFactory.isSecureAuthenticationTransport(session)) {
if (log.isDebugEnabled()) {
log.debug("doAuth({}) session is not secure", session);
}
return false;
}
{code}
It may be the case that the server has some kind of race condition and has not
yet updated its internal state that KEX is completed when
{{SSH_MSG_USERAUTH_REQUEST}} arrives. Anyway, you have not mentioned what MINA
SSHD version you are using. Please try the latest one.
Another thing to notice is that some servers behave in a special way and expect
flows that are not always standard. To that effect, try and activate the
"delayed KEX" option in our code (see [this
link|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#configuring-the-protocol-exchange-phase]).
This option delays KEX from the client side until the server has sent its
identification first. It might fix this issue entirely, but perhaps it may
introduce enough of a delay to overcome the suspected race condition in the
server.
> compatibility problem with cisco-2.0 ssh on ios-xr
> ---
>
> Key: SSHD-969
> URL: https://issues.apache.org/jira/browse/SSHD-969
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Yuefeng
>Priority: Major
>
> When mina ssh library is used to connect with a Cisco IOS-XR device, the
> connection is consistently reset by IOS-XR, here's mina log
>
>
> {code:java}
> 2020-02-25 20:12:15.531Z [sshd-SshClient[468ca10d]-nio2-thread-1] DEBUG
> o.a.s.c.session.ClientSessionImpl:271 -
> initializeProxyConnector(ClientSessionImpl[null@/10.90.10.193:22]) no proxy
> to initialize
> 2020-02-25 20:12:15.531Z [pool-171-thread-1] INFO
> com.forwardnetworks.client.a.f.a.d:20 - Connected to 'xrv9k'
> 2020-02-25 20:12:15.531Z [pool-171-thread-1] DEBUG
> o.a.s.c.session.ClientSessionImpl:204 -
> addPasswordIdentity(ClientSessionImpl[*@/10.90.10.1
[jira] [Commented] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046600#comment-17046600
]
Lyor Goldstein commented on SSHD-968:
-
[~gnodet] See https://github.com/apache/mina-sshd/pull/114 (code is available
at https://github.com/lgoldstein/mina-sshd/tree/SSHD-968). I adopted your
excellent idea + test, just implemented it in (IMO) a slightly more general way
that we can hopefully use in the future for other features/issues
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-969) compatibility problem with cisco-2.0 ssh on ios-xr
[
https://issues.apache.org/jira/browse/SSHD-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046686#comment-17046686
]
Lyor Goldstein commented on SSHD-969:
-
{quote}
I noticed that Mina SSH sends msg 50 (SSH_MSG_USERAUTH_REQUEST) before key
exchange completes
{quote}
I cannot figure out what scenario can lead to this - authentication messages
are exchanged +after+ keys have been exchanged - never over insecure channel.
We have such checks in code:
{code:java}
@Override
public Boolean doAuth(Buffer buffer, boolean init) throws Exception {
ValidateUtils.checkTrue(init, "Instance not initialized");
ServerSession session = getServerSession();
if (!UserAuthMethodFactory.isSecureAuthenticationTransport(session)) {
if (log.isDebugEnabled()) {
log.debug("doAuth({}) session is not secure", session);
}
return false;
}
{code}
It may be the case that the server has some kind of race condition and has not
yet updated its internal state that KEX is completed when
{{SSH_MSG_USERAUTH_REQUEST}} arrives. Anyway, you have not mentioned what MINA
SSHD version you are using. Please try the latest one.
Another thing to notice is that some servers behave in a special way and expect
flows that are not always standard. To that effect, try and activate the
"delayed KEX" option in our code (see [this
link|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#configuring-the-protocol-exchange-phase]).
This option delays KEX from the client side until the server has sent its
identification first. It might fix this issue entirely, but perhaps it may
introduce enough of a delay to overcome the suspected race condition in the
server.
> compatibility problem with cisco-2.0 ssh on ios-xr
> ---
>
> Key: SSHD-969
> URL: https://issues.apache.org/jira/browse/SSHD-969
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Yuefeng
>Priority: Major
>
> When mina ssh library is used to connect with a Cisco IOS-XR device, the
> connection is consistently reset by IOS-XR, here's mina log
>
>
> {code:java}
> 2020-02-25 20:12:15.531Z [sshd-SshClient[468ca10d]-nio2-thread-1] DEBUG
> o.a.s.c.session.ClientSessionImpl:271 -
> initializeProxyConnector(ClientSessionImpl[null@/10.90.10.193:22]) no proxy
> to initialize
> 2020-02-25 20:12:15.531Z [pool-171-thread-1] INFO
> com.forwardnetworks.client.a.f.a.d:20 - Connected to 'xrv9k'
> 2020-02-25 20:12:15.531Z [pool-171-thread-1] DEBUG
> o.a.s.c.session.ClientSessionImpl:204 -
> addPasswordIdentity(ClientSessionImpl[*@/10.90.10.193:22]) SHA256:**
> 2020-02-25 20:12:15.532Z [pool-171-thread-1] INFO
> com.forwardnetworks.client.a.f.a.d:28 - Authenticating client session to
> xrv9k for up to 1 seconds.
> 2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG
> o.a.s.c.s.ClientUserAuthService:162 -
> auth(ClientSessionImpl[cisco@/10.90.10.193:22])[ssh-connection] send
> SSH_MSG_USERAUTH_REQUEST for 'none'
> 2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG
> o.a.s.c.session.ClientSessionImpl:808 -
> writePacket(ClientSessionImpl[cisco@/10.90.10.193:22])[SSH_MSG_USERAUTH_REQUEST]
> Start flagging packets as pending until key exchange is done
> 2020-02-25 20:12:15.533Z [sshd-SshClient[468ca10d]-nio2-thread-5] DEBUG
> o.a.s.c.session.ClientSessionImpl:167 -
> signalAuthFailure(ClientSessionImpl[cisco@/10.90.10.193:22])
> type=IOException, signalled=true: Connection reset by peer
> {code}
>
> Ssh (openssh) successfully connects to the save device
> {code:java}
> fwd-collector@collector:/usr/local/fwd/logs$ ssh -vvv @10.90.10.193
> OpenSSH_7.2p2 Ubuntu-4ubuntu2.7, OpenSSL 1.0.2g 1 Mar 2016
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug2: resolving "10.90.10.193" port 22
> debug2: ssh_connect_direct: needpriv 0
> debug1: Connecting to 10.90.10.193 [10.90.10.193] port 22.
> debug1: Connection established.
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_rsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector
[jira] [Resolved] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-968.
-
Fix Version/s: 2.4.1
Resolution: Fixed
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.4.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047718#comment-17047718
]
Lyor Goldstein commented on SSHD-968:
-
{quote}
Sorry, but the git link in
https://github.com/lgoldstein/mina-sshd/tree/SSHD-968 is bad. When I download
it, I get to version 1.7.0
{quote}
I should have been clearer - the idea is to clone and then checkout branch
SSHD-968
{quote}
UPDATE: the zip seems to be ok. I will do the verification on the zip instead.
{quote}
Strange, since you claim the version is 1.7.0...
{quote}
Feel free to merge whenever you want. Thanks for the quick support.
{quote}
Good news - will do.
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-969) compatibility problem with cisco-2.0 ssh on ios-xr
[
https://issues.apache.org/jira/browse/SSHD-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047786#comment-17047786
]
Lyor Goldstein commented on SSHD-969:
-
There is one more thing you should verify - the KEX options being sent by the
MINA SSHD client (e.g., supported ciphers, MAC, etc.) - the server might have
problems with one of the options and thus close the connection. While this
behavior is a violation of the SSH protocol, some servers do mis-behave. See
also [SSHD-930|https://issues.apache.org/jira/browse/SSHD-930]
Finally, if there is any way to get a hold of the server side logs and view
them it might also help diagnose the issue.
> compatibility problem with cisco-2.0 ssh on ios-xr
> ---
>
> Key: SSHD-969
> URL: https://issues.apache.org/jira/browse/SSHD-969
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Yuefeng
>Priority: Major
>
> When mina ssh library is used to connect with a Cisco IOS-XR device, the
> connection is consistently reset by IOS-XR, here's mina log
>
>
> {code:java}
> 2020-02-25 20:12:15.531Z [sshd-SshClient[468ca10d]-nio2-thread-1] DEBUG
> o.a.s.c.session.ClientSessionImpl:271 -
> initializeProxyConnector(ClientSessionImpl[null@/10.90.10.193:22]) no proxy
> to initialize
> 2020-02-25 20:12:15.531Z [pool-171-thread-1] INFO
> com.forwardnetworks.client.a.f.a.d:20 - Connected to 'xrv9k'
> 2020-02-25 20:12:15.531Z [pool-171-thread-1] DEBUG
> o.a.s.c.session.ClientSessionImpl:204 -
> addPasswordIdentity(ClientSessionImpl[*@/10.90.10.193:22]) SHA256:**
> 2020-02-25 20:12:15.532Z [pool-171-thread-1] INFO
> com.forwardnetworks.client.a.f.a.d:28 - Authenticating client session to
> xrv9k for up to 1 seconds.
> 2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG
> o.a.s.c.s.ClientUserAuthService:162 -
> auth(ClientSessionImpl[cisco@/10.90.10.193:22])[ssh-connection] send
> SSH_MSG_USERAUTH_REQUEST for 'none'
> 2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG
> o.a.s.c.session.ClientSessionImpl:808 -
> writePacket(ClientSessionImpl[cisco@/10.90.10.193:22])[SSH_MSG_USERAUTH_REQUEST]
> Start flagging packets as pending until key exchange is done
> 2020-02-25 20:12:15.533Z [sshd-SshClient[468ca10d]-nio2-thread-5] DEBUG
> o.a.s.c.session.ClientSessionImpl:167 -
> signalAuthFailure(ClientSessionImpl[cisco@/10.90.10.193:22])
> type=IOException, signalled=true: Connection reset by peer
> {code}
>
> Ssh (openssh) successfully connects to the save device
> {code:java}
> fwd-collector@collector:/usr/local/fwd/logs$ ssh -vvv @10.90.10.193
> OpenSSH_7.2p2 Ubuntu-4ubuntu2.7, OpenSSL 1.0.2g 1 Mar 2016
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug2: resolving "10.90.10.193" port 22
> debug2: ssh_connect_direct: needpriv 0
> debug1: Connecting to 10.90.10.193 [10.90.10.193] port 22.
> debug1: Connection established.
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_rsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/fwd-collector/.ssh/id_ed25519-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.7
> debug1: Remote protocol version 2.0, remote software version Cisco-2.0
> debug1: no match: Cisco-2.0
> debug2: fd 3 setting O_NONBLOCK
> debug1: Authenticating to 10.90.10.193:22 as 'admin'
> debug3: hostkeys_foreach: reading file "/home/fwd-collector/.ssh/known_hosts"
> debug3: record_hostkey: found key type RSA in file
> /home/fwd-collector/.ssh/known_hosts:28
> debug3: load_hostkeys: loaded 1 keys from 10.90.10.193
> debug3: order_hostkeyalgs: prefer hostkeyalgs:
> ssh-rsa-cert-...@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
&g
[jira] [Updated] (SSHD-958) sshd (openssh5) closes connection on mina ssh client after pkt 50, but not ssh
[
https://issues.apache.org/jira/browse/SSHD-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-958:
Labels: need-more-info (was: )
> sshd (openssh5) closes connection on mina ssh client after pkt 50, but not ssh
> --
>
> Key: SSHD-958
> URL: https://issues.apache.org/jira/browse/SSHD-958
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Yuefeng
> Assignee: Lyor Goldstein
>Priority: Minor
> Labels: need-more-info
>
> Using mina ssh library to connect to a system, but the system always closes
> connection at the following stage:
> {code:java}
> 2019-12-09 21:03:08 Z [pool-123195-thread-1] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService:
> auth(ClientSessionImpl[])[ssh-connection] send
> SSH_MSG_USERAUTH_REQUEST for 'none'
> 2019-12-09 21:03:08 Z [pool-123195-thread-1] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl:
> writePacket(ClientSessionImpl[X])[SSH_MSG_USERAUTH_REQUEST] Start
> flagging packets as pending until key exchange is done
> 2019-12-09 21:03:09 Z [pool-123195-thread-1] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl:
> close(ClientSessionImpl[XX]) Closing immediately
> 2019-12-09 21:03:09 Z [pool-123195-thread-1] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl:
> signalAuthFailure(ClientSessionImpl[XX]) type=SshException,
> signalled=false: Session is being closed
> {code}
> when I tried ssh client from the same computer to the same destination, it
> works. "-vvv" shows that the destination system is
> {code:java}
> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
> debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c00
> {code}
> openssh lib shows the compat flag
> {code:java}
> { “OpenSSH_5*“, SSH_NEW_OPENSSH|SSH_BUG_DYNAMIC_RPORT| SSH_BUG_SIGTYPE},
> {code}
>
> while "SSH_NEW_OPENSSH" and "SSH_BUG_SIGTYPE" are common, flag
> SSH_BUG_DYNAMIC_RPORT is specific to OpenSSH_5, and not set anywhere else.
> Does mina ssh handle OpenSSH_5?
>
>
>
>
>
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046855#comment-17046855
]
Lyor Goldstein commented on SSHD-968:
-
[~patrikek] Please test https://github.com/lgoldstein/mina-sshd/tree/SSHD-968
code - I prefer delaying merging it to allow for some "field testing" besides
the unit test in place.
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027031#comment-17027031
]
Lyor Goldstein commented on SSHD-964:
-
Hi [~roberto.deandrea] sorry to bother you, but after reviewing the code for
{{sendEof}} I decided to make a slight adjustment to it - basically bypass the
regular {{writePacket}} which I reverted to allow sending channel messages only
if channel is open (see below). I am sure it did not damage this issue's
functionality, but I would feel better if you would be so kind as to run a
sanity test on it from your part.
Thanks
{code:java}
protected ... sendEof() {
Session s = getSession();
Buffer buffer = s.createBuffer(SshConstants.SSH_MSG_CHANNEL_EOF,
Short.SIZE);
buffer.putInt(getRecipient());
/*
* The default "writePacket" does not send packets if state
* is not open so we need to bypass it.
*/
return s.writePacket(buffer);
}
@Override
public IoWriteFuture writePacket(Buffer buffer) throws IOException {
if (!isClosing()) {
Session s = getSession();
return s.writePacket(buffer);
}
if (log.isDebugEnabled()) {
log.debug("writePacket({}) Discarding output packet because channel
state={}", this, state);
}
return new AbstractIoWriteFuture(toString(), null) {
{
setValue(new EOFException("Channel is being closed"));
}
};
}
{code}
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
> Reporter: Roberto Deandrea
>Assignee: Lyor Goldstein
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[ https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-964. - Fix Version/s: 2.4.1 Resolution: Fixed Thanks [~roberto.deandrea] - merged to master branch > SSH_MSG_CHANNEL_EOF never sent or received for local and remote port > forwarding > --- > > Key: SSHD-964 > URL: https://issues.apache.org/jira/browse/SSHD-964 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.3.0, 2.3.1 >Reporter: Roberto Deandrea > Assignee: Lyor Goldstein >Priority: Major > Fix For: 2.4.1 > > > We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for > local and remote port forwarding connections. > We found probably the issue and we changed the code locally in a couple of > java classes to fix this issue. > Let me know if we can commit our changes in a pull request (into a specific > Apache SSHD branch) so that you can peer review the changes and decide if > you can accept them... > > Kind Regards > Roberto Deandrea > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022311#comment-17022311
]
Lyor Goldstein edited comment on SSHD-964 at 1/23/20 5:52 PM:
--
{quote}I will try your suggested code changes into AbstractChannel class in
methods sendEof() and writePacket()
{quote}
Thanks [~roberto.deandrea]. On that note, I am having 2nd thoughts about this
piece of code:
{code:java|title=AbstractChannel#sendEof}
if (eofReceived.get()) {
return;
}
{code}
I am not sure why this is correct... I have re-read the relevant section in
RFC4254 and I cannot really find an interpretation that mandates this behavior.
What was the rationale behind it when you made your changes ?
{quote}NOT REMOVING shutdownOutputStream() method in TcpipClientChannel class
IS NOT ACCEPTABLE
{quote}
Like I said, I am not against removing it - but I need some more time to weigh
the consequences... I was able to trace its introduction to SSHD-902 - I would
appreciate it if you could also take a look at it and give me your opinion on
it.
was (Author: lgoldstein):
{quote}
I will try your suggested code changes into AbstractChannel class in methods
sendEof() and writePacket()
{quote}
Thanks [~roberto.deandrea]. On that note, I am having 2nd thoughts about this
piece of code:
{code:java|title=AbstractChannel#sendEof}
if (eofReceived.get()) {
return;
}
{code}
I am not sure why this is correct... I have re-read the relevant section in
RFC4254 and I cannot really find an interpretation that mandates this behavior.
What was the rationale behind it when you made your changes ?
{quote}
NOT REMOVING shutdownOutputStream() method in TcpipClientChannel class IS NOT
ACCEPTABLE
{quote}
Like I said, I am not against removing it - but I need some more time to weigh
the consequences...
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Roberto Deandrea
> Assignee: Lyor Goldstein
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022311#comment-17022311
]
Lyor Goldstein commented on SSHD-964:
-
{quote}
I will try your suggested code changes into AbstractChannel class in methods
sendEof() and writePacket()
{quote}
Thanks [~roberto.deandrea]. On that note, I am having 2nd thoughts about this
piece of code:
{code:java|title=AbstractChannel#sendEof}
if (eofReceived.get()) {
return;
}
{code}
I am not sure why this is correct... I have re-read the relevant section in
RFC4254 and I cannot really find an interpretation that mandates this behavior.
What was the rationale behind it when you made your changes ?
{quote}
NOT REMOVING shutdownOutputStream() method in TcpipClientChannel class IS NOT
ACCEPTABLE
{quote}
Like I said, I am not against removing it - but I need some more time to weigh
the consequences...
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Roberto Deandrea
> Assignee: Lyor Goldstein
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023163#comment-17023163
]
Lyor Goldstein commented on SSHD-964:
-
Thanks [~roberto.deandrea] for the valuable feedback.
{quote}
The rationale is that the SSH_MSG_CHANNEL_EOF message is not ackknoledged
according to the standard.
{quote}
True, but the code in question does not seem to be acknowledging anything - it
is sending an EOF independently. I am therefore inclined to remove it. Please
let me know if you think there is a compelling reason why it should be left
in
{quote}
think it's wrong shutdownOutputStream() when a client channel receives an EOF
from the other side of the connection, because in this case the socket
connection is always closed and I think it's not the right behavior. Maybe
shutdownOutputStream() is to be performed later when the channel is being
closed.
{quote}
I am inclined to agree with you - will make the necessary changes and let you
know soon
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Roberto Deandrea
> Assignee: Lyor Goldstein
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023612#comment-17023612
]
Lyor Goldstein commented on SSHD-964:
-
Hi [~roberto.deandrea] I have updated the code in the branch - note the
following
* I removed the call to {{shutdownOutputStream}}
* I have decided to send EOF even if one already received from peer
Please test the code and let me know.
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Roberto Deandrea
> Assignee: Lyor Goldstein
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[ https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025258#comment-17025258 ] Lyor Goldstein commented on SSHD-964: - Great - thanks [~roberto.deandrea] for the issue and its test > SSH_MSG_CHANNEL_EOF never sent or received for local and remote port > forwarding > --- > > Key: SSHD-964 > URL: https://issues.apache.org/jira/browse/SSHD-964 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.3.0, 2.3.1 >Reporter: Roberto Deandrea > Assignee: Lyor Goldstein >Priority: Major > > We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for > local and remote port forwarding connections. > We found probably the issue and we changed the code locally in a couple of > java classes to fix this issue. > Let me know if we can commit our changes in a pull request (into a specific > Apache SSHD branch) so that you can peer review the changes and decide if > you can accept them... > > Kind Regards > Roberto Deandrea > -- 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-967) transferTo function of SftpRemotePathChannel always add some extra bytes in the end of file
[ https://issues.apache.org/jira/browse/SSHD-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041761#comment-17041761 ] Lyor Goldstein commented on SSHD-967: - Thanks for diagnosing the issue and providing a patch - please see my comment on it. Try it and let me know if if provides the required fix. > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > --- > > Key: SSHD-967 > URL: https://issues.apache.org/jira/browse/SSHD-967 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Nitin Ranjan >Priority: Major > Fix For: 2.4.1 > > Time Spent: 20m > Remaining Estimate: 0h > > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > > I have tried to transfer gz file from sftp server after transfer when I tried > to decompress it it was giving warning > *decompression ok trailing garbage ignored* > > When I checked the file I found some extra bytes appended to the file > -- 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] [Assigned] (SSHD-967) transferTo function of SftpRemotePathChannel always add some extra bytes in the end of file
[ https://issues.apache.org/jira/browse/SSHD-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-967: --- Assignee: Lyor Goldstein > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > --- > > Key: SSHD-967 > URL: https://issues.apache.org/jira/browse/SSHD-967 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Nitin Ranjan > Assignee: Lyor Goldstein >Priority: Major > Fix For: 2.4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > > I have tried to transfer gz file from sftp server after transfer when I tried > to decompress it it was giving warning > *decompression ok trailing garbage ignored* > > When I checked the file I found some extra bytes appended to the file > -- 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] [Work started] (SSHD-967) transferTo function of SftpRemotePathChannel always add some extra bytes in the end of file
[ https://issues.apache.org/jira/browse/SSHD-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-967 started by Lyor Goldstein. --- > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > --- > > Key: SSHD-967 > URL: https://issues.apache.org/jira/browse/SSHD-967 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Nitin Ranjan > Assignee: Lyor Goldstein >Priority: Major > Fix For: 2.4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > > I have tried to transfer gz file from sftp server after transfer when I tried > to decompress it it was giving warning > *decompression ok trailing garbage ignored* > > When I checked the file I found some extra bytes appended to the file > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-967) transferTo function of SftpRemotePathChannel always add some extra bytes in the end of file
[ https://issues.apache.org/jira/browse/SSHD-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041806#comment-17041806 ] Lyor Goldstein edited comment on SSHD-967 at 2/21/20 1:19 PM: -- Please clone and test https://github.com/lgoldstein/mina-sshd/tree/SSHD-967 - done with it - will wait for your test... was (Author: lgoldstein): Please clone and test https://github.com/lgoldstein/mina-sshd/tree/SSHD-967 > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > --- > > Key: SSHD-967 > URL: https://issues.apache.org/jira/browse/SSHD-967 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Nitin Ranjan > Assignee: Lyor Goldstein >Priority: Major > Fix For: 2.4.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > > I have tried to transfer gz file from sftp server after transfer when I tried > to decompress it it was giving warning > *decompression ok trailing garbage ignored* > > When I checked the file I found some extra bytes appended to the file > -- 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-967) transferTo function of SftpRemotePathChannel always add some extra bytes in the end of file
[ https://issues.apache.org/jira/browse/SSHD-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041806#comment-17041806 ] Lyor Goldstein commented on SSHD-967: - Please clone and test https://github.com/lgoldstein/mina-sshd/tree/SSHD-967 > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > --- > > Key: SSHD-967 > URL: https://issues.apache.org/jira/browse/SSHD-967 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Nitin Ranjan > Assignee: Lyor Goldstein >Priority: Major > Fix For: 2.4.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > transferTo function of SftpRemotePathChannel always add some extra bytes in > the end of file > > I have tried to transfer gz file from sftp server after transfer when I tried > to decompress it it was giving warning > *decompression ok trailing garbage ignored* > > When I checked the file I found some extra bytes appended to the file > -- 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-965) Add support for S3 bridge - SFTP and/or SCP
[
https://issues.apache.org/jira/browse/SSHD-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033258#comment-17033258
]
Lyor Goldstein commented on SSHD-965:
-
See if there is a {{FileSystemProvider}} implementation over S3
> Add support for S3 bridge - SFTP and/or SCP
> ---
>
> Key: SSHD-965
> URL: https://issues.apache.org/jira/browse/SSHD-965
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.3.1
> Reporter: Lyor Goldstein
>Priority: Minor
>
--
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-965) Add support for S3 bridge - SFTP and/or SCP
Lyor Goldstein created SSHD-965: --- Summary: Add support for S3 bridge - SFTP and/or SCP Key: SSHD-965 URL: https://issues.apache.org/jira/browse/SSHD-965 Project: MINA SSHD Issue Type: New Feature Affects Versions: 2.3.1 Reporter: Lyor Goldstein -- 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] [Assigned] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-968:
---
Assignee: Lyor Goldstein
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Assignee: Lyor Goldstein
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replies with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042627#comment-17042627
]
Lyor Goldstein commented on SSHD-968:
-
{quote}
According to RFC 4253 sect. 11.4
(https://tools.ietf.org/html/rfc4253#section-11.4) the SSH_MSG_UNIMPLEMENTED is
meant to be ignored, but this makes little sense for a heartbeat, as even
SSH_MSG_UNIMPLEMENTED is good enough to count as a reply for this. This is for
example the case in OpenSSH, where SSH_MSG_UNIMPLEMENTED replies for heartbeat,
does not lead to a termination of the SSH session.
{quote}
I am not comfortable with violating the standard - but on the other hand, we
have to practical - so I'll think about it.
{quote}
There is a workaround released in 2.1.1, to use ReservedSessionMessagesHandler
for handling replies, but this does not allow access to the method
AbstractSession.requestFailure() (without using reflection so to say).
{quote}
Perhaps this is a better solution - I have no problem making
{{AbstractSession#requestFailure}} publicly accessible.
{quote}
The reason for this is SSH_MSG_UNIMPLEMENTED is only logged in...Further, the
heartbeat is ongoing in the background, so there is no good solution to this
problem from outside of the framework.
{quote}
Perhaps the fix would be to consider {{SSH_MSG_UNIMPLEMENTED}} a valid response
for heartbeat, but it raises an important issue - how do we know that
{{SSH_MSG_UNIMPLEMENTED}} was received because of the heartbeat and not
something else ? How can we tell that the reason is
{quote}
In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
keep-alive heartbeat times out.
{quote}
To summarize - this raises an important question, but will have to think a bit
about possible answers...
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replies
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-968:
Summary: SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST
is replied with SSH_MSG_UNSUPPORTED (was: SshClient times out during
keep-alive, when SSH_MSG_GLOBAL_REQUEST is replies with SSH_MSG_UNSUPPORTED)
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied with SSH_MSG_UNSUPPORTED
[
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042634#comment-17042634
]
Lyor Goldstein commented on SSHD-968:
-
Seems to me that servers that respond with {{SSH_MSG_UNIMPLEMENTED}} violate
[rfc4254 - section 4|https://tools.ietf.org/html/rfc4254#section-4] that states
that the response should be {{SSH_MSG_REQUEST_FAILURE}}.
> SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replied
> with SSH_MSG_UNSUPPORTED
> --
>
> Key: SSHD-968
> URL: https://issues.apache.org/jira/browse/SSHD-968
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
> Environment: Windows 10
>Reporter: Patrik Ek
>Priority: Major
>
> In case SSH_MSG_GLOBAL_REQUEST is not supported by the remote SSH server, the
> keep-alive heartbeat times out. The reason for this is SSH_MSG_UNIMPLEMENTED
> is only logged in
> {color:#172b4d}org.apache.sshd.common.session.helpers{color}.AbstractSession
> The method identifying the SSH_MSG_UNIMPLEMENTED is called
> AbstractSession.doHandleMessage()
> The consequense is that no reply is received and the heartbeat times out
> instead of calling AbstractSession.requestFailure(). Which in turn leads to
> the session terminates.
> According to RFC 4253 sect. 11.4
> ({color:#004000}https://tools.ietf.org/html/rfc4253#section-11.4{color}) the
> SSH_MSG_UNIMPLEMENTED is meant to be ignored, but this makes little sense for
> a heartbeat, as even SSH_MSG_UNIMPLEMENTED is good enough to count as a reply
> for this. This is for example the case in OpenSSH, where
> SSH_MSG_UNIMPLEMENTED replies for heartbeat, does not lead to a termination
> of the SSH session.
> There is a workaround released in 2.1.1, to use
> ReservedSessionMessagesHandler for handling replies, but this does not allow
> access to the method AbstractSession.requestFailure() (without using
> reflection so to say). Further, the heartbeat is ongoing in the background,
> so there is no good solution to this problem from outside of the framework.
> https://issues.apache.org/jira/browse/SSHD-887?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.1.1
> Would this be possible to fix? The reason I write it here is because the bug
> seems to existing up to some version of libssh, even for the SSHv2 protocol,
> so just writing a bug report on the particular server will not solve the
> problems for already existing implementations using libssh.
> The following config is used,
> SshClient client =
> SshClient.setUpDefaultClient(){color:#cc7832};{color}{color:#808080}
> {color} {color:#172b4d}PropertyResolverUtils.updateProperty(client,
> ClientFactoryManager.HEARTBEAT_INTERVAL, 15000);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REPLY_WAIT,
> 3);
>
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
> "keepal...@openssh.com");{color}
> {color:#cc7832}{color:#172b4d}BR{color}
> {color:#172b4d}Patrik{color}
> {color}
--
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] [Assigned] (SSHD-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-966:
---
Assignee: Lyor Goldstein
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
> Assignee: Lyor Goldstein
>Priority: Major
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:646)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> java.util.concu
[jira] [Commented] (SSHD-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033811#comment-17033811
]
Lyor Goldstein commented on SSHD-966:
-
Thanks for the detailed diagnosis - I'll look at it and try to follow it.
Meanwhile, can you try to reproduce the issue with the newly released version
2.4.0 ? We have made some changes to the locking mechanisms (though not
specifically to this one).
On an unrelated issue - why do you need Mina 2.0.17 if you are using the NIO
backend ?
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
> Assignee: Lyor Goldstein
>Priority: Major
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
> java.util.concurrent
[jira] [Commented] (SSHD-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[ https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019010#comment-17019010 ] Lyor Goldstein commented on SSHD-964: - I have looked at the code and indeed we are sending EOF for a variety of channel related actions, but not for tunnels (or X forwarding). I am still a bit curious as to whether this is mandated for ALL channels or not - especially since the tunneling code seems to work. Perhaps the peers are "lenient" since the RFC states that EOF "should be sent" and not "must be sent". Still, before making the necessary changes I would like to see the PR you mentioned. > SSH_MSG_CHANNEL_EOF never sent or received for local and remote port > forwarding > --- > > Key: SSHD-964 > URL: https://issues.apache.org/jira/browse/SSHD-964 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.3.0, 2.3.1 > Reporter: Roberto Deandrea >Assignee: Lyor Goldstein >Priority: Major > > We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for > local and remote port forwarding connections. > We found probably the issue and we changed the code locally in a couple of > java classes to fix this issue. > Let me know if we can commit our changes in a pull request (into a specific > Apache SSHD branch) so that you can peer review the changes and decide if > you can accept them... > > Kind Regards > Roberto Deandrea > -- 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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021250#comment-17021250
]
Lyor Goldstein commented on SSHD-964:
-
I have looked at the code and as far as sending EOF when state is _Open_ or
_Graceful_ instead of {{!isClosing()}} - this seems like an acceptable behavior
change. As far as removing {{shutdownOutputStreamCall()}} - I still need to
research this. I remember this was added for (at the time) a good reason...
I will prepare a candidate fix some time soon and let you know - so you can
test it.
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Roberto Deandrea
> Assignee: Lyor Goldstein
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021250#comment-17021250
]
Lyor Goldstein edited comment on SSHD-964 at 1/22/20 5:07 PM:
--
I have looked at the code and as far as sending EOF when state is _Open_ or
_Graceful_ instead of {{!isClosing()}} - this seems like an acceptable behavior
change. As far as removing {{shutdownOutputStream()}} call - I still need to
research this. I remember this was added for (at the time) a good reason...
I will prepare a candidate fix some time soon and let you know - so you can
test it.
was (Author: lgoldstein):
I have looked at the code and as far as sending EOF when state is _Open_ or
_Graceful_ instead of {{!isClosing()}} - this seems like an acceptable behavior
change. As far as removing {{shutdownOutputStreamCall()}} - I still need to
research this. I remember this was added for (at the time) a good reason...
I will prepare a candidate fix some time soon and let you know - so you can
test it.
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Roberto Deandrea
> Assignee: Lyor Goldstein
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021313#comment-17021313
]
Lyor Goldstein commented on SSHD-964:
-
Hi [~roberto.deandrea] please clone and try
https://github.com/lgoldstein/mina-sshd/tree/SSHD-964 (feel free to also see
the code changes). Note that it does not contain the removal of
{{shutdownOutputStream}} call in {{handleEof}} - like I said, I need to review
it further. Please let me know how it went...
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Roberto Deandrea
> Assignee: Lyor Goldstein
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
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] [Work started] (SSHD-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[ https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-964 started by Lyor Goldstein. --- > SSH_MSG_CHANNEL_EOF never sent or received for local and remote port > forwarding > --- > > Key: SSHD-964 > URL: https://issues.apache.org/jira/browse/SSHD-964 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.3.0, 2.3.1 >Reporter: Roberto Deandrea > Assignee: Lyor Goldstein >Priority: Major > > We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for > local and remote port forwarding connections. > We found probably the issue and we changed the code locally in a couple of > java classes to fix this issue. > Let me know if we can commit our changes in a pull request (into a specific > Apache SSHD branch) so that you can peer review the changes and decide if > you can accept them... > > Kind Regards > Roberto Deandrea > -- 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] [Assigned] (SSHD-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[ https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-964: --- Assignee: Lyor Goldstein > SSH_MSG_CHANNEL_EOF never sent or received for local and remote port > forwarding > --- > > Key: SSHD-964 > URL: https://issues.apache.org/jira/browse/SSHD-964 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.3.0, 2.3.1 >Reporter: Roberto Deandrea > Assignee: Lyor Goldstein >Priority: Major > > We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for > local and remote port forwarding connections. > We found probably the issue and we changed the code locally in a couple of > java classes to fix this issue. > Let me know if we can commit our changes in a pull request (into a specific > Apache SSHD branch) so that you can peer review the changes and decide if > you can accept them... > > Kind Regards > Roberto Deandrea > -- 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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017920#comment-17017920
]
Lyor Goldstein commented on SSHD-964:
-
{quote}
Let me know if we can commit our changes in a pull request (into a specific
Apache SSHD branch) so that you can peer review the changes and decide if you
can accept them...
{quote}
Gladly - we appreciate contributions from the community.
The port forwarding code is pretty old and seems to work just fine till now -
it is the first time we encounter this complaint. As things stand right now
please note that we are in the process of releasing a new version so even if
this PR makes it into the code you will have to wait for the next release,
since it does not seem like a major issue.
Can you also attach some reference to the RFC that specifies that these
messages must be sent for port forwarding (I will of course review the port
forwarding standard, but it would help to have some idea as to why you think
these messages are required). Also, can you provide the client/server
specification you are using so we can investigate if this is an omission on our
part in implementing the standard correctly or some "idiosyncrasy" of the
specific client/server.
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Roberto Deandrea
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[
https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018166#comment-17018166
]
Lyor Goldstein commented on SSHD-964:
-
{quote}
When a party will no longer send more data to a channel, it SHOULD
send SSH_MSG_CHANNEL_EOF.
byte SSH_MSG_CHANNEL_EOF
uint32 recipient channel
{quote}
We do that (I have double checked) - but perhaps for some reason not for port
forwarding - I will try to look into it. Would help if you posted a PR with
your recommended changes.
> SSH_MSG_CHANNEL_EOF never sent or received for local and remote port
> forwarding
> ---
>
> Key: SSHD-964
> URL: https://issues.apache.org/jira/browse/SSHD-964
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.3.1
>Reporter: Roberto Deandrea
> Assignee: Lyor Goldstein
>Priority: Major
>
> We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for
> local and remote port forwarding connections.
> We found probably the issue and we changed the code locally in a couple of
> java classes to fix this issue.
> Let me know if we can commit our changes in a pull request (into a specific
> Apache SSHD branch) so that you can peer review the changes and decide if
> you can accept them...
>
> Kind Regards
> Roberto Deandrea
>
--
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-964) SSH_MSG_CHANNEL_EOF never sent or received for local and remote port forwarding
[ https://issues.apache.org/jira/browse/SSHD-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019667#comment-17019667 ] Lyor Goldstein commented on SSHD-964: - [~roberto.deandrea] See my comments on the proposed change - can you provide some explanation as to the code flow analysis that led you to make these changes and why the solve the issue ? Thanks > SSH_MSG_CHANNEL_EOF never sent or received for local and remote port > forwarding > --- > > Key: SSHD-964 > URL: https://issues.apache.org/jira/browse/SSHD-964 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.3.0, 2.3.1 >Reporter: Roberto Deandrea > Assignee: Lyor Goldstein >Priority: Major > > We found that the message SSH_MSG_CHANNEL_EOF is never sent or received for > local and remote port forwarding connections. > We found probably the issue and we changed the code locally in a couple of > java classes to fix this issue. > Let me know if we can commit our changes in a pull request (into a specific > Apache SSHD branch) so that you can peer review the changes and decide if > you can accept them... > > Kind Regards > Roberto Deandrea > -- 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-951) Query on how to restart sshd server in single jboss session
[
https://issues.apache.org/jira/browse/SSHD-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006965#comment-17006965
]
Lyor Goldstein commented on SSHD-951:
-
Correct
> Query on how to restart sshd server in single jboss session
> ---
>
> Key: SSHD-951
> URL: https://issues.apache.org/jira/browse/SSHD-951
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.2.0
>Reporter: Sivanagarajup
>Priority: Major
>
> Hi Team,
> We are facing an issue with version *sshd-core-2.2.0*
> In the same session once we stoped ssh server we are not able to start the
> ssh server again.
> it is throwing exception below
> {code:java}
> Caused by: java.lang.IllegalStateException: Can not start the server again
> Caused by: java.lang.IllegalStateException: Can not start the server again at
> org.apache.sshd.server.SshServer.start(SshServer.java:293)
> {code}
> As per your code in *org.apache.sshd.server.SshServer -> start()*
> {code:java}
> public void start() throws IOException {
>if (isClosed()) {
> throw new IllegalStateException("Can not start the server again");
>}
> --
> --
> }{code}
> it is not allowing us to start sshd server again.
> Note: Once we restarted our jboss server then we are able to start sshd
> server.
> But we need to start/stop the ssh server multiple times in single session
> Could you please help us on above issue.
>
> Thanks
> Siva
--
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-961) Not all messages are correctly handled in port forwarding mode
[
https://issues.apache.org/jira/browse/SSHD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002417#comment-17002417
]
Lyor Goldstein commented on SSHD-961:
-
Hi [~fcava] - thanks for the PR - I will review it and most likely merge it
soon...
> Not all messages are correctly handled in port forwarding mode
> --
>
> Key: SSHD-961
> URL: https://issues.apache.org/jira/browse/SSHD-961
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.1
>Reporter: Fulvio Cavarretta
> Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some race conditions so that in port forwarding mode, not all
> messages are correctly managed during connections phase, leading to
> _NullPointerException_
>
> The problem is caused in
> {noformat}
> DefaultForwardingFilter.messageReceived{noformat}
> where
> {code:java}
> OpenFuture future = channel.getOpenFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
> {code}
> should be
> {code:java}
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
>
> OpenFuture future = messagesQueue.getCompletedFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> {code}
> Since the _ClientChannelPendingMessagesQueue_ is a listener of the channel's
> OpenFuture, this latter can be in open state but the
> ClientChannelPendingMessagesQueue's completed feature could be not, so that
> messages won't be correctly handled and a _null_ _errHandler_ is passed to
> _ClientChannelPendingMessagesQueue.handleIncomingMessage_
>
>
--
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] [Assigned] (SSHD-961) Not all messages are correctly handled in port forwarding mode
[
https://issues.apache.org/jira/browse/SSHD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-961:
---
Assignee: Lyor Goldstein
> Not all messages are correctly handled in port forwarding mode
> --
>
> Key: SSHD-961
> URL: https://issues.apache.org/jira/browse/SSHD-961
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.1
>Reporter: Fulvio Cavarretta
> Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some race conditions so that in port forwarding mode, not all
> messages are correctly managed during connections phase, leading to
> _NullPointerException_
>
> The problem is caused in
> {noformat}
> DefaultForwardingFilter.messageReceived{noformat}
> where
> {code:java}
> OpenFuture future = channel.getOpenFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
> {code}
> should be
> {code:java}
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
>
> OpenFuture future = messagesQueue.getCompletedFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> {code}
> Since the _ClientChannelPendingMessagesQueue_ is a listener of the channel's
> OpenFuture, this latter can be in open state but the
> ClientChannelPendingMessagesQueue's completed feature could be not, so that
> messages won't be correctly handled and a _null_ _errHandler_ is passed to
> _ClientChannelPendingMessagesQueue.handleIncomingMessage_
>
>
--
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] [Work started] (SSHD-961) Not all messages are correctly handled in port forwarding mode
[
https://issues.apache.org/jira/browse/SSHD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-961 started by Lyor Goldstein.
---
> Not all messages are correctly handled in port forwarding mode
> --
>
> Key: SSHD-961
> URL: https://issues.apache.org/jira/browse/SSHD-961
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.1
>Reporter: Fulvio Cavarretta
> Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some race conditions so that in port forwarding mode, not all
> messages are correctly managed during connections phase, leading to
> _NullPointerException_
>
> The problem is caused in
> {noformat}
> DefaultForwardingFilter.messageReceived{noformat}
> where
> {code:java}
> OpenFuture future = channel.getOpenFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
> {code}
> should be
> {code:java}
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
>
> OpenFuture future = messagesQueue.getCompletedFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> {code}
> Since the _ClientChannelPendingMessagesQueue_ is a listener of the channel's
> OpenFuture, this latter can be in open state but the
> ClientChannelPendingMessagesQueue's completed feature could be not, so that
> messages won't be correctly handled and a _null_ _errHandler_ is passed to
> _ClientChannelPendingMessagesQueue.handleIncomingMessage_
>
>
--
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-951) Query on how to restart sshd server in single jboss session
[
https://issues.apache.org/jira/browse/SSHD-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006454#comment-17006454
]
Lyor Goldstein commented on SSHD-951:
-
The supported standards are pretty much the same - see
https://github.com/apache/mina-sshd/blob/master/docs/changes/2.3.0.md for any
extra supported features that were introduced only in 2.3.0
> Query on how to restart sshd server in single jboss session
> ---
>
> Key: SSHD-951
> URL: https://issues.apache.org/jira/browse/SSHD-951
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.2.0
>Reporter: Sivanagarajup
>Priority: Major
>
> Hi Team,
> We are facing an issue with version *sshd-core-2.2.0*
> In the same session once we stoped ssh server we are not able to start the
> ssh server again.
> it is throwing exception below
> {code:java}
> Caused by: java.lang.IllegalStateException: Can not start the server again
> Caused by: java.lang.IllegalStateException: Can not start the server again at
> org.apache.sshd.server.SshServer.start(SshServer.java:293)
> {code}
> As per your code in *org.apache.sshd.server.SshServer -> start()*
> {code:java}
> public void start() throws IOException {
>if (isClosed()) {
> throw new IllegalStateException("Can not start the server again");
>}
> --
> --
> }{code}
> it is not allowing us to start sshd server again.
> Note: Once we restarted our jboss server then we are able to start sshd
> server.
> But we need to start/stop the ssh server multiple times in single session
> Could you please help us on above issue.
>
> Thanks
> Siva
--
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-961) Not all messages are correctly handled in port forwarding mode
[
https://issues.apache.org/jira/browse/SSHD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-961:
Affects Version/s: (was: 2.3.1)
2.3.0
> Not all messages are correctly handled in port forwarding mode
> --
>
> Key: SSHD-961
> URL: https://issues.apache.org/jira/browse/SSHD-961
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Fulvio Cavarretta
> Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some race conditions so that in port forwarding mode, not all
> messages are correctly managed during connections phase, leading to
> _NullPointerException_
>
> The problem is caused in
> {noformat}
> DefaultForwardingFilter.messageReceived{noformat}
> where
> {code:java}
> OpenFuture future = channel.getOpenFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
> {code}
> should be
> {code:java}
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
>
> OpenFuture future = messagesQueue.getCompletedFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> {code}
> Since the _ClientChannelPendingMessagesQueue_ is a listener of the channel's
> OpenFuture, this latter can be in open state but the
> ClientChannelPendingMessagesQueue's completed feature could be not, so that
> messages won't be correctly handled and a _null_ _errHandler_ is passed to
> _ClientChannelPendingMessagesQueue.handleIncomingMessage_
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-961) Not all messages are correctly handled in port forwarding mode
[
https://issues.apache.org/jira/browse/SSHD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-961.
-
Fix Version/s: 2.3.1
Resolution: Fixed
Merged in with thanks + acknowledgement - see
[commit|https://github.com/apache/mina-sshd/commit/3eeaa03a20b849da8c6e59bfa97534f6bb15bebb]
> Not all messages are correctly handled in port forwarding mode
> --
>
> Key: SSHD-961
> URL: https://issues.apache.org/jira/browse/SSHD-961
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.1
>Reporter: Fulvio Cavarretta
> Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some race conditions so that in port forwarding mode, not all
> messages are correctly managed during connections phase, leading to
> _NullPointerException_
>
> The problem is caused in
> {noformat}
> DefaultForwardingFilter.messageReceived{noformat}
> where
> {code:java}
> OpenFuture future = channel.getOpenFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
> {code}
> should be
> {code:java}
> ClientChannelPendingMessagesQueue messagesQueue =
> channel.getPendingMessagesQueue();
>
> OpenFuture future = messagesQueue.getCompletedFuture();
> Consumer errHandler = future.isOpened() ? null : e -> {
> try {
> exceptionCaught(session, e);
> } catch (Exception err) {
> log.warn("messageReceived({}) failed ({}) to signal
> {}[{}] on channel={}: {}",
> session, err.getClass().getSimpleName(),
> e.getClass().getSimpleName(),
> e.getMessage(), channel, err.getMessage());
> }
> };
> {code}
> Since the _ClientChannelPendingMessagesQueue_ is a listener of the channel's
> OpenFuture, this latter can be in open state but the
> ClientChannelPendingMessagesQueue's completed feature could be not, so that
> messages won't be correctly handled and a _null_ _errHandler_ is passed to
> _ClientChannelPendingMessagesQueue.handleIncomingMessage_
>
>
--
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] [Assigned] (SSHD-963) Uploading a file with filezilla,preserve timestamps of transferred files， but setting fileAttributes failed
[ https://issues.apache.org/jira/browse/SSHD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-963: --- Assignee: Lyor Goldstein > Uploading a file with filezilla,preserve timestamps of transferred files， but > setting fileAttributes failed > --- > > Key: SSHD-963 > URL: https://issues.apache.org/jira/browse/SSHD-963 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: barry-gq > Assignee: Lyor Goldstein >Priority: Blocker > Fix For: 1.7.0 > > Attachments: 1.png, 2.png > > > *background:* > I have a project to process some data with apache sshd-sftp > > *Operation ：* > I use filezilla to upload a file and turn on the option to preserve the > timestamp of the transferred file，but modifytime is not set correctly > > *java code description：* > After uploading a file, the server code can receive the accesstime and > modifytime normally, but when the client processes version V3, there is only > one flags parameter, which makes it impossible to set modifytime > correctly.The two codes of the picture are: pciture > 1:AbstractSftpSubsystemHelper :: setFileAttributes, pciture > 2:AbstractSftpClient :: writeAttributes > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-963) Uploading a file with filezilla,preserve timestamps of transferred files， but setting fileAttributes failed
[ https://issues.apache.org/jira/browse/SSHD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-963. - Fix Version/s: (was: 1.7.0) Resolution: Won't Fix After reviewing the code I believe there is no bug - if you look closely at the code, you will see that for SFTP v3 the flag implies *both* access time +and+ modify time. Therefore when we build the attributes mask to send we need to make sure +both+ flags are available - thus the way the code is written. Please upgrade to version 2.3.0 and retry your code. If you still believe there is bug then, please re-open and provide clarification as to how you think the code should behave > Uploading a file with filezilla,preserve timestamps of transferred files， but > setting fileAttributes failed > --- > > Key: SSHD-963 > URL: https://issues.apache.org/jira/browse/SSHD-963 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: barry-gq > Assignee: Lyor Goldstein >Priority: Blocker > Attachments: 1.png, 2.png > > > *background:* > I have a project to process some data with apache sshd-sftp > > *Operation ：* > I use filezilla to upload a file and turn on the option to preserve the > timestamp of the transferred file，but modifytime is not set correctly > > *java code description：* > After uploading a file, the server code can receive the accesstime and > modifytime normally, but when the client processes version V3, there is only > one flags parameter, which makes it impossible to set modifytime > correctly.The two codes of the picture are: pciture > 1:AbstractSftpSubsystemHelper :: setFileAttributes, pciture > 2:AbstractSftpClient :: writeAttributes > > -- 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] [Work started] (SSHD-963) Uploading a file with filezilla,preserve timestamps of transferred files， but setting fileAttributes failed
[ https://issues.apache.org/jira/browse/SSHD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-963 started by Lyor Goldstein. --- > Uploading a file with filezilla,preserve timestamps of transferred files， but > setting fileAttributes failed > --- > > Key: SSHD-963 > URL: https://issues.apache.org/jira/browse/SSHD-963 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.7.0 >Reporter: barry-gq > Assignee: Lyor Goldstein >Priority: Blocker > Fix For: 1.7.0 > > Attachments: 1.png, 2.png > > > *background:* > I have a project to process some data with apache sshd-sftp > > *Operation ：* > I use filezilla to upload a file and turn on the option to preserve the > timestamp of the transferred file，but modifytime is not set correctly > > *java code description：* > After uploading a file, the server code can receive the accesstime and > modifytime normally, but when the client processes version V3, there is only > one flags parameter, which makes it impossible to set modifytime > correctly.The two codes of the picture are: pciture > 1:AbstractSftpSubsystemHelper :: setFileAttributes, pciture > 2:AbstractSftpClient :: writeAttributes > > -- 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-963) Uploading a file with filezilla,preserve timestamps of transferred files， but setting fileAttributes failed
[
https://issues.apache.org/jira/browse/SSHD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003704#comment-17003704
]
Lyor Goldstein commented on SSHD-963:
-
The version you refer to in this issue (1.7.0) is very old. Due to extremely
limited resources we do not provide fixes for released version (unless
extremely critical bugs - in which case we release a *new* version - never a
back fix). That being said, the bug you mention now seems to exist only in the
{{AbstractSftpClient#writeAttributes}} method
({{AbstractSftpSubsystemHelper#setFileAttributes}} has been re-written and now
behaves correctly IMO). That being said, I will fix
{{AbstractSftpClient#writeAttributes}}, and it will be available when we
release 2.3.1 (or maybe it will be called 2.4) - I believe some time in Jan.
2020...
> Uploading a file with filezilla,preserve timestamps of transferred files， but
> setting fileAttributes failed
> ---
>
> Key: SSHD-963
> URL: https://issues.apache.org/jira/browse/SSHD-963
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: barry-gq
> Assignee: Lyor Goldstein
>Priority: Blocker
> Fix For: 1.7.0
>
> Attachments: 1.png, 2.png
>
>
> *background:*
> I have a project to process some data with apache sshd-sftp
>
> *Operation ：*
> I use filezilla to upload a file and turn on the option to preserve the
> timestamp of the transferred file，but modifytime is not set correctly
>
> *java code description：*
> After uploading a file, the server code can receive the accesstime and
> modifytime normally, but when the client processes version V3, there is only
> one flags parameter, which makes it impossible to set modifytime
> correctly.The two codes of the picture are: pciture
> 1:AbstractSftpSubsystemHelper :: setFileAttributes, pciture
> 2:AbstractSftpClient :: writeAttributes
>
>
--
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-963) Uploading a file with filezilla,preserve timestamps of transferred files， but setting fileAttributes failed
[
https://issues.apache.org/jira/browse/SSHD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004038#comment-17004038
]
Lyor Goldstein commented on SSHD-963:
-
[~barry-gq] {quote}but in fact they are separated{quote} - please examine the
code *carefully* - they are separated, but each checks the existence of the
*other* one - in other words, the code is making sure that *both* are set, and
only then adds the relevant mask. According to [SFTP
v3|https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-5] if the
{{SSH_FILEXFER_ATTR_ACMODTIME}} is set then *both* times are available - and
this is what the code ensures.
{quote}look forward to your updates in subsequent versions{quote} I don't
foresee updates on this issue on subsequent releases since it feels like what
you are asking is to violate the standard - which I am reluctant to do since it
may break compatibility with existing clients.
{quote}I will try to modify it myself to temporarily fix this problem{quote}
What I can suggest is the following: upgrade to the latest version and see if
the problem persists - especially with +other clients+ such as WinSCP and
OpenSSH. Perhaps FileZilla is trying to do something non-standard - it isn't
the first time we've had issues open that turned out to be violations of the
standard by various clients that were assuming that they were talking with a
proprietary server of their own who was tolerating the non-standard behavior.
If the problem persists (even if it does only for FileZilla), try to debug the
code sequence and try to figure out what *exactly* is causing problems - making
sure especially that it is not something that only FileZilla does. Once that is
done, please update the issue and describe it. If indeed it is a
mis-interpretation on our part we will gladly fix it. If not, I am willing to
entertain adding a +special+ configuration property that can tell our client to
"mis-behave" (default of course will be _false_).
> Uploading a file with filezilla,preserve timestamps of transferred files， but
> setting fileAttributes failed
> ---
>
> Key: SSHD-963
> URL: https://issues.apache.org/jira/browse/SSHD-963
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: barry-gq
>Assignee: Lyor Goldstein
>Priority: Blocker
> Attachments: 1.png, 2.png
>
>
> *background:*
> I have a project to process some data with apache sshd-sftp
>
> *Operation ：*
> I use filezilla to upload a file and turn on the option to preserve the
> timestamp of the transferred file，but modifytime is not set correctly
>
> *java code description：*
> After uploading a file, the server code can receive the accesstime and
> modifytime normally, but when the client processes version V3, there is only
> one flags parameter, which makes it impossible to set modifytime
> correctly.The two codes of the picture are: pciture
> 1:AbstractSftpSubsystemHelper :: setFileAttributes, pciture
> 2:AbstractSftpClient :: writeAttributes
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-963) Uploading a file with filezilla,preserve timestamps of transferred files， but setting fileAttributes failed
[
https://issues.apache.org/jira/browse/SSHD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004038#comment-17004038
]
Lyor Goldstein edited comment on SSHD-963 at 12/27/19 9:35 AM:
---
[~barry-gq]
{quote}but in fact they are separated
{quote}
- please examine the code *carefully* - they are separated, but each checks the
existence of the *other* one - in other words, the code is making sure that
*both* are set, and only then adds the relevant mask. According to [SFTP
v3|https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-5] if the
{{SSH_FILEXFER_ATTR_ACMODTIME}} is set then *both* times are available - and
this is what the code ensures.
{quote}look forward to your updates in subsequent versions
{quote}
I don't foresee updates on this issue on subsequent releases since it feels
like what you are asking is to violate the standard - which I am reluctant to
do since it may break compatibility with existing clients.
{quote}I will try to modify it myself to temporarily fix this problem
{quote}
What I can suggest is the following: upgrade to the latest version and see if
the problem persists - especially with +other clients+ such as WinSCP and
OpenSSH. Perhaps FileZilla is trying to do something non-standard - it isn't
the first time we've had issues open that turned out to be violations of the
standard by various clients that were assuming that they were talking with a
proprietary server of their own who was tolerating the non-standard behavior.
If the problem persists (even if it does only for FileZilla), try to debug the
code sequence and try to figure out what *exactly* is causing problems - making
sure especially that it is not something that only FileZilla does or some
peculiar behavior of the O/S or the Java version you are using that somehow
does not report both flags are existing. Once that is done, please update the
issue and describe it. If indeed it is a mis-interpretation on our part we will
gladly fix it. If not, I am willing to entertain adding a +special+
configuration property that can tell our client to "mis-behave" (default of
course will be _false_).
was (Author: lgoldstein):
[~barry-gq] {quote}but in fact they are separated{quote} - please examine the
code *carefully* - they are separated, but each checks the existence of the
*other* one - in other words, the code is making sure that *both* are set, and
only then adds the relevant mask. According to [SFTP
v3|https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-5] if the
{{SSH_FILEXFER_ATTR_ACMODTIME}} is set then *both* times are available - and
this is what the code ensures.
{quote}look forward to your updates in subsequent versions{quote} I don't
foresee updates on this issue on subsequent releases since it feels like what
you are asking is to violate the standard - which I am reluctant to do since it
may break compatibility with existing clients.
{quote}I will try to modify it myself to temporarily fix this problem{quote}
What I can suggest is the following: upgrade to the latest version and see if
the problem persists - especially with +other clients+ such as WinSCP and
OpenSSH. Perhaps FileZilla is trying to do something non-standard - it isn't
the first time we've had issues open that turned out to be violations of the
standard by various clients that were assuming that they were talking with a
proprietary server of their own who was tolerating the non-standard behavior.
If the problem persists (even if it does only for FileZilla), try to debug the
code sequence and try to figure out what *exactly* is causing problems - making
sure especially that it is not something that only FileZilla does. Once that is
done, please update the issue and describe it. If indeed it is a
mis-interpretation on our part we will gladly fix it. If not, I am willing to
entertain adding a +special+ configuration property that can tell our client to
"mis-behave" (default of course will be _false_).
> Uploading a file with filezilla,preserve timestamps of transferred files， but
> setting fileAttributes failed
> ---
>
> Key: SSHD-963
> URL: https://issues.apache.org/jira/browse/SSHD-963
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 1.7.0
> Reporter: barry-gq
>Assignee: Lyor Goldstein
>Priority: Blocker
> Attachments: 1.png, 2.png
>
>
> *background:*
> I have a project to process some data with apache sshd-sftp
>
> *Operation ：*
> I use filezilla to upload a file and turn on the option to preserve the
> timestamp of the transferred file，but modifytime is not set correctly
&
[jira] [Commented] (SSHD-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054508#comment-17054508
]
Lyor Goldstein commented on SSHD-966:
-
I believe I have a possible solution - see
https://github.com/lgoldstein/mina-sshd/tree/SSHD-966. I would appreciate it if
you could test it and let me know. You are more than welcome to also review the
associated PR (https://github.com/apache/mina-sshd/pull/117)
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
> Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
> java.util.conc
[jira] [Work started] (SSHD-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-966 started by Lyor Goldstein.
---
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
> Assignee: Lyor Goldstein
>Priority: Major
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:646)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
[jira] [Commented] (SSHD-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054487#comment-17054487
]
Lyor Goldstein commented on SSHD-966:
-
I see the problem, but will have to think some more about a solution
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
> Assignee: Lyor Goldstein
>Priority: Major
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:646)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
[jira] [Comment Edited] (SSHD-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055227#comment-17055227
]
Lyor Goldstein edited comment on SSHD-966 at 3/9/20, 5:22 PM:
--
Sorry, I spoke too soon - the code has a bug inasmuch as if there is a lot of
traffic the KEX state might never be marked as {{DONE}} (or marked as such very
late). Back to the drawing board...
was (Author: lgoldstein):
Sorry, I spoke too soon - the code has a bug inasmuch as if there is a lot of
traffic the KEX state might never be marked as {{DONE}} (or marked as such very
late).
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
> Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
[jira] [Commented] (SSHD-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055227#comment-17055227
]
Lyor Goldstein commented on SSHD-966:
-
Sorry, I spoke too soon - the code has a bug inasmuch as if there is a lot of
traffic the KEX state might never be marked as {{DONE}} (or marked as such very
late).
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
> Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> com.google.ge
[jira] [Created] (SSHD-973) Add implementation of 'sslh' bridge
Lyor Goldstein created SSHD-973: --- Summary: Add implementation of 'sslh' bridge Key: SSHD-973 URL: https://issues.apache.org/jira/browse/SSHD-973 Project: MINA SSHD Issue Type: New Feature Reporter: Lyor Goldstein Assignee: Lyor Goldstein Implement a pure Java solution similar to [sslh|https://github.com/yrutschle/sslh] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-975) SshClient subclasses fail in OSGi environment
[
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-975.
-
Fix Version/s: 2.4.1
Resolution: Fixed
Fixed by commit
[60bdb04642|https://github.com/apache/mina-sshd/commit/60bdb04642cbcb82501841b9f25601c5532d537b]
> SshClient subclasses fail in OSGi environment
> -
>
> Key: SSHD-975
> URL: https://issues.apache.org/jira/browse/SSHD-975
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Robert Varga
>Priority: Major
> Fix For: 2.4.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Attempting to subclass SshClient and use it in OSGi environment can fail with
> the following:
> {noformat}
> 2020-04-07T07:46:19,968 | WARN | nioEventLoopGroupCloseable-3-1 |
> ChannelInitializer | 64 - io.netty.common - 4.1.45.Final |
> Failed to initialize a channel. Closing: [id: 0xfedebbf7]
> java.lang.ExceptionInInitializerError: null
> at
> org.opendaylight.netconf.client.SshClientChannelInitializer.initialize(SshClientChannelInitializer.java:43)
> ~[402:org.opendaylight.netconf.client:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.ReconnectPromise.lambda$connect$0(ReconnectPromise.java:54)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:206)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:203)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:956)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:502)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:417)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:474)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [64:io.netty.common:4.1.45.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [64:io.netty.common:4.1.45.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.IllegalArgumentException:
> org.apache.sshd.common.forward.PortForwardingEventListener referenced from a
> method is not visible from class loader
> at java.lang.reflect.Proxy$ProxyBuilder.ensureVisible(Proxy.java:858)
> ~[?:?]
> at
> java.lang.reflect.Proxy$ProxyBuilder.validateProxyInterfaces(Proxy.java:681)
> ~[?:?]
> at
[jira] [Commented] (SSHD-660) Add support for authentication using signed client/server keys
[ https://issues.apache.org/jira/browse/SSHD-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083517#comment-17083517 ] Lyor Goldstein commented on SSHD-660: - I reviewed it and had some comments - seems like solid work in general, but it lacks unit tests and most important - a real live server that we can test this code... I am not keen on adding code that I have no way to test it - not only via jUnit but also with real servers. > Add support for authentication using signed client/server keys > -- > > Key: SSHD-660 > URL: https://issues.apache.org/jira/browse/SSHD-660 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein >Priority: Minor > > Similar to _HostCertificate_ and _TrustedUserCAKeys_ configuration values - > see https://ef.gy/hardening-ssh -- 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-660) Add support for authentication using signed client/server keys
[
https://issues.apache.org/jira/browse/SSHD-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084583#comment-17084583
]
Lyor Goldstein commented on SSHD-660:
-
{quote}
For the unit tests I don't really know how and what is best to test.. Are there
some integration tests which I overlook? Would be the easiest to spawn a server
and let a client ping?
{quote}
For unit testing it is enough to spawn a server and let a client ping - there
are plenty of examples.
{quote}
I tested it against `OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep
2019` (default Debian Buster) and with `OpenSSH_8.1p1, LibreSSL 2.7.3` (default
macOS) client.
{quote}
Can you provide some reference documentation how to set up these server to
execute this type of authentication ?
> Add support for authentication using signed client/server keys
> --
>
> Key: SSHD-660
> URL: https://issues.apache.org/jira/browse/SSHD-660
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Lyor Goldstein
>Priority: Minor
>
> Similar to _HostCertificate_ and _TrustedUserCAKeys_ configuration values -
> see https://ef.gy/hardening-ssh
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-660) Add support for authentication using signed client/server keys
[
https://issues.apache.org/jira/browse/SSHD-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084583#comment-17084583
]
Lyor Goldstein edited comment on SSHD-660 at 4/16/20, 6:42 AM:
---
{quote}
For the unit tests I don't really know how and what is best to test.. Are there
some integration tests which I overlook? Would be the easiest to spawn a server
and let a client ping?
{quote}
For unit testing it is enough to spawn a server and let a client ping - there
are plenty of examples in the current code how to do this.
{quote}
I tested it against `OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep
2019` (default Debian Buster) and with `OpenSSH_8.1p1, LibreSSL 2.7.3` (default
macOS) client.
{quote}
Can you provide some reference documentation how to set up these server to
execute this type of authentication ?
was (Author: lgoldstein):
{quote}
For the unit tests I don't really know how and what is best to test.. Are there
some integration tests which I overlook? Would be the easiest to spawn a server
and let a client ping?
{quote}
For unit testing it is enough to spawn a server and let a client ping - there
are plenty of examples.
{quote}
I tested it against `OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep
2019` (default Debian Buster) and with `OpenSSH_8.1p1, LibreSSL 2.7.3` (default
macOS) client.
{quote}
Can you provide some reference documentation how to set up these server to
execute this type of authentication ?
> Add support for authentication using signed client/server keys
> --
>
> Key: SSHD-660
> URL: https://issues.apache.org/jira/browse/SSHD-660
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Lyor Goldstein
>Priority: Minor
>
> Similar to _HostCertificate_ and _TrustedUserCAKeys_ configuration values -
> see https://ef.gy/hardening-ssh
--
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-660) Add support for authentication using signed client/server keys
[ https://issues.apache.org/jira/browse/SSHD-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084992#comment-17084992 ] Lyor Goldstein commented on SSHD-660: - Great - thx > Add support for authentication using signed client/server keys > -- > > Key: SSHD-660 > URL: https://issues.apache.org/jira/browse/SSHD-660 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein >Priority: Minor > > Similar to _HostCertificate_ and _TrustedUserCAKeys_ configuration values - > see https://ef.gy/hardening-ssh -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-895) Add support for RSA + SHA-256/512 signatures
[
https://issues.apache.org/jira/browse/SSHD-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17086503#comment-17086503
]
Lyor Goldstein edited comment on SSHD-895 at 4/18/20, 3:39 PM:
---
The comment simply says that there are servers that refuse to authenticate if
the public key algorithms listed by the clients are not supported by the
server. In other words, even if eventually the negotiated algorithm would be
{{ssh-rsa}} some servers refuse to authenticate if the client lists algorithms
they do not support. It contradicts SSH protocol behavior of course, but we
want the default settings of MINA SSHD to provide the widest possible support -
which means the most common "denominator".
was (Author: lgoldstein):
The comment simply says that there are servers that refuse to authenticate if
the public key algorithms listed by the clients are not supported by the
server. In other words, even if eventually the negotiated algorithm would be
`ssh-rsa` some servers refuse to authenticate if the client lists algorithms
they do not support. It contradicts SSH protocol behavior of course, but we
want the default settings of MINA SSHD to provide the widest possible support -
which means the most common "denominator".
> Add support for RSA + SHA-256/512 signatures
>
>
> Key: SSHD-895
> URL: https://issues.apache.org/jira/browse/SSHD-895
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Lyor Goldstein
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.0
>
>
> See https://tools.ietf.org/html/rfc8332 - *Note:*
> {quote}
> Servers that accept rsa-sha2-* signatures for client authentication
> SHOULD implement the extension negotiation mechanism defined in
> [RFC8308], including especially the "server-sig-algs" extension.
> {quote}
--
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-895) Add support for RSA + SHA-256/512 signatures
[
https://issues.apache.org/jira/browse/SSHD-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17086503#comment-17086503
]
Lyor Goldstein commented on SSHD-895:
-
The comment simply says that there are servers that refuse to authenticate if
the public key algorithms listed by the clients are not supported by the
server. In other words, even if eventually the negotiated algorithm would be
`ssh-rsa` some servers refuse to authenticate if the client lists algorithms
they do not support. It contradicts SSH protocol behavior of course, but we
want the default settings of MINA SSHD to provide the widest possible support -
which means the most common "denominator".
> Add support for RSA + SHA-256/512 signatures
>
>
> Key: SSHD-895
> URL: https://issues.apache.org/jira/browse/SSHD-895
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Lyor Goldstein
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.0
>
>
> See https://tools.ietf.org/html/rfc8332 - *Note:*
> {quote}
> Servers that accept rsa-sha2-* signatures for client authentication
> SHOULD implement the extension negotiation mechanism defined in
> [RFC8308], including especially the "server-sig-algs" extension.
> {quote}
--
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-978) Autoformat source code instead of using checkstyle
[ https://issues.apache.org/jira/browse/SSHD-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17086504#comment-17086504 ] Lyor Goldstein commented on SSHD-978: - Can you provide some more information on this issue ? I am not sure it is feasible - my main concern is how this would work in coordination with the IDE(s) (let's say Eclipse and Intellij). > Autoformat source code instead of using checkstyle > -- > > Key: SSHD-978 > URL: https://issues.apache.org/jira/browse/SSHD-978 > Project: MINA SSHD > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.4.1 > > -- 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-975) SshClient subclasses fail in OSGi environment
[
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077132#comment-17077132
]
Lyor Goldstein commented on SSHD-975:
-
In general I am fine with the suggested change (see my previous comment) - I am
not so clear though as to why {{getClass().getClassLoader()}} would yield
something different than {{AbstractFactoryManager.class.getClassLoader()}}. Can
you provide some more details as to the mechanism involved here that make these
class loaders different somehow ?
While on this subject - why are you using NETTY and not the default NIO2
service factory ? Have you tried NIO2 ? Does it exhibit the same behavior ?
> SshClient subclasses fail in OSGi environment
> -
>
> Key: SSHD-975
> URL: https://issues.apache.org/jira/browse/SSHD-975
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Robert Varga
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Attempting to subclass SshClient and use it in OSGi environment can fail with
> the following:
> {noformat}
> 2020-04-07T07:46:19,968 | WARN | nioEventLoopGroupCloseable-3-1 |
> ChannelInitializer | 64 - io.netty.common - 4.1.45.Final |
> Failed to initialize a channel. Closing: [id: 0xfedebbf7]
> java.lang.ExceptionInInitializerError: null
> at
> org.opendaylight.netconf.client.SshClientChannelInitializer.initialize(SshClientChannelInitializer.java:43)
> ~[402:org.opendaylight.netconf.client:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.ReconnectPromise.lambda$connect$0(ReconnectPromise.java:54)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:206)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:203)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:956)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:502)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:417)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:474)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [64:io.netty.common:4.1.45.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [64:io.netty.common:4.1.45.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.IllegalArgumentExcepti
[jira] [Comment Edited] (SSHD-975) SshClient subclasses fail in OSGi environment
[
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077132#comment-17077132
]
Lyor Goldstein edited comment on SSHD-975 at 4/7/20, 11:14 AM:
---
In general I am fine with the suggested change (see though my comment on the
PR) - I am not so clear though as to why {{getClass().getClassLoader()}} would
yield something different than
{{AbstractFactoryManager.class.getClassLoader()}}. Can you provide some more
details as to the mechanism involved here that make these class loaders
different somehow ?
While on this subject - why are you using NETTY and not the default NIO2
service factory ? Have you tried NIO2 ? Does it exhibit the same behavior ?
was (Author: lgoldstein):
In general I am fine with the suggested change (see my previous comment) - I am
not so clear though as to why {{getClass().getClassLoader()}} would yield
something different than {{AbstractFactoryManager.class.getClassLoader()}}. Can
you provide some more details as to the mechanism involved here that make these
class loaders different somehow ?
While on this subject - why are you using NETTY and not the default NIO2
service factory ? Have you tried NIO2 ? Does it exhibit the same behavior ?
> SshClient subclasses fail in OSGi environment
> -
>
> Key: SSHD-975
> URL: https://issues.apache.org/jira/browse/SSHD-975
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Robert Varga
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Attempting to subclass SshClient and use it in OSGi environment can fail with
> the following:
> {noformat}
> 2020-04-07T07:46:19,968 | WARN | nioEventLoopGroupCloseable-3-1 |
> ChannelInitializer | 64 - io.netty.common - 4.1.45.Final |
> Failed to initialize a channel. Closing: [id: 0xfedebbf7]
> java.lang.ExceptionInInitializerError: null
> at
> org.opendaylight.netconf.client.SshClientChannelInitializer.initialize(SshClientChannelInitializer.java:43)
> ~[402:org.opendaylight.netconf.client:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.ReconnectPromise.lambda$connect$0(ReconnectPromise.java:54)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:206)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:203)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:956)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:502)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:417)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:474)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [64:io.netty.common:4.1.45.Final]
> at io.netty.channel.nio.NioEve
[jira] [Commented] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077557#comment-17077557
]
Lyor Goldstein commented on SSHD-974:
-
I cannot reproduce it in any way - however, I do have another suspicion: is
{{eddsa-0.3.0.jar}} on your CLASSPATH ? If not, then the decoder for the
{{ssh-ed25519}} key will not be available...
> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
> Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub,
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with
> the error message "Bad format (no key data delimiter)" however this key is
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.
--
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-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[ https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077560#comment-17077560 ] Lyor Goldstein commented on SSHD-974: - Yes, I just confirmed it - the problem you describe occurs if eddsa-0.3.0.jar}} is not}} on your CLASSPATH. Please try it after fixing this problem and re-open the issue if it still occurs. > AuthorizedKeyEntry fails to parse ed25519 public keys > - > > Key: SSHD-974 > URL: https://issues.apache.org/jira/browse/SSHD-974 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 > Environment: Arch Linux compiled with OpenJDK 1.8.0_242 >Reporter: Justin Crawford > Assignee: Lyor Goldstein >Priority: Minor > Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, > id_ed25519.pub.hex > > > When parsing an authorized keys file, I get a StreamCorruptedException with > the error message "Bad format (no key data delimiter)" however this key is > accepted by OpenSSH and generated by ssh-keygen. Other key types, such as > RSA, are parsed just fine by this parser. > I attached an example program demonstrating how I am using the parser. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[ https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-974. - Resolution: Invalid > AuthorizedKeyEntry fails to parse ed25519 public keys > - > > Key: SSHD-974 > URL: https://issues.apache.org/jira/browse/SSHD-974 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 > Environment: Arch Linux compiled with OpenJDK 1.8.0_242 >Reporter: Justin Crawford > Assignee: Lyor Goldstein >Priority: Minor > Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, > id_ed25519.pub.hex > > > When parsing an authorized keys file, I get a StreamCorruptedException with > the error message "Bad format (no key data delimiter)" however this key is > accepted by OpenSSH and generated by ssh-keygen. Other key types, such as > RSA, are parsed just fine by this parser. > I attached an example program demonstrating how I am using the parser. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077560#comment-17077560
]
Lyor Goldstein edited comment on SSHD-974 at 4/7/20, 8:46 PM:
--
Yes, I just confirmed it - the problem you describe occurs if
{{eddsa-0.3.0.jar}} is not on your CLASSPATH. Please try it after fixing this
problem and re-open the issue if it still occurs.
was (Author: lgoldstein):
Yes, I just confirmed it - the problem you describe occurs if
eddsa-0.3.0.jar}} is not}} on your CLASSPATH. Please try it after fixing
this problem and re-open the issue if it still occurs.
> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
> Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub,
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with
> the error message "Bad format (no key data delimiter)" however this key is
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.
--
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-976) Add support for RSASSA-PSS keys
[ https://issues.apache.org/jira/browse/SSHD-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-976: Description: See [a|https://tools.ietf.org/html/rfc4056]ttached links (was: See [https://tools.ietf.org/html/rfc4056]) > Add support for RSASSA-PSS keys > --- > > Key: SSHD-976 > URL: https://issues.apache.org/jira/browse/SSHD-976 > Project: MINA SSHD > Issue Type: New Feature > Reporter: Lyor Goldstein >Priority: Minor > > See [a|https://tools.ietf.org/html/rfc4056]ttached links -- 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-976) Add support for RSASSA-PSS keys
Lyor Goldstein created SSHD-976: --- Summary: Add support for RSASSA-PSS keys Key: SSHD-976 URL: https://issues.apache.org/jira/browse/SSHD-976 Project: MINA SSHD Issue Type: New Feature Reporter: Lyor Goldstein See [https://tools.ietf.org/html/rfc4056] -- 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-977) Apply consistent logging policy to caught exceptions
Lyor Goldstein created SSHD-977: --- Summary: Apply consistent logging policy to caught exceptions Key: SSHD-977 URL: https://issues.apache.org/jira/browse/SSHD-977 Project: MINA SSHD Issue Type: Improvement Reporter: Lyor Goldstein Assignee: Lyor Goldstein See [https://github.com/apache/mina-sshd/pull/120] as an example: * Log at ERROR/WARNING level the basic exception details (class + message) * If DEBUG enabled then also log at ERROR/WARNING level the actual stack trace -- 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] [Work started] (SSHD-977) Apply consistent logging policy to caught exceptions
[ https://issues.apache.org/jira/browse/SSHD-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-977 started by Lyor Goldstein. --- > Apply consistent logging policy to caught exceptions > > > Key: SSHD-977 > URL: https://issues.apache.org/jira/browse/SSHD-977 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein > Assignee: Lyor Goldstein >Priority: Major > > See [https://github.com/apache/mina-sshd/pull/120] as an example: > * Log at ERROR/WARNING level the basic exception details (class + message) > * If DEBUG enabled then also log at ERROR/WARNING level the actual stack trace -- 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-981) Implement no-flow-control SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088664#comment-17088664 ] Lyor Goldstein commented on SSHD-981: - Great - thanks > Implement no-flow-control SFTP extension > > > Key: SSHD-981 > URL: https://issues.apache.org/jira/browse/SSHD-981 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.5.0 > > > This extension has been specified by [https://tools.ietf.org/html/rfc8308] -- 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
