You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Patrik Ek (Jira)" <ji...@apache.org> on 2020/02/23 17:22:00 UTC
[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&focusedCommentId=17042997#comment-17042997 ]
Patrik Ek edited comment on SSHD-968 at 2/23/20 5:21 PM:
---------------------------------------------------------
[~lgoldstein] Sorry for replying late. Saturdays and Sundays are normally my days off, so I have not been that active. Hontestly I did not expect this fast response. Anyway, To answer your questions,
{color:#172b4d}1.{color}
_{color:#172b4d}Seems to me that servers that respond with {color}{{SSH_MSG_UNIMPLEMENTED}}{color:#172b4d} violate {color}[rfc4254 - section 4|https://tools.ietf.org/html/rfc4254#section-4]{color:#172b4d} that states that the response should be {color}{{SSH_MSG_REQUEST_FAILURE}}{color:#172b4d}.{color}_
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).
2.
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.
3.
_{color:#172b4d}Have you tried using the {color}[SSH_MSG_IGNORE|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic]{color:#172b4d} mechanism instead of global requests{color}_
yes, but the problem is not only to keep the connection alive. The problem is to know when the connection goes down. The proper way to do this is to send an SSH_MSG_GLOBAL_REQUEST with the want-reply flag. This is also how OpenSSH does. The differerence is that when you get the SSH_MSG_UNIMPLEMENTED flag in OpenSSH, it will instead count this as a valid reply, as this shows the server is alive and it is very obvious there will be no other reply.
BR
Patrik
was (Author: patrikek):
[~lgoldstein] Sorry for replying late. Saturdays and Sundays are normally my days off, so I have not been that active. Hontestly I did not expect this fast response. Anyway, To answer your questions,
{color:#172b4d}1.{color}
_{color:#172b4d}Seems to me that servers that respond with {color}{{SSH_MSG_UNIMPLEMENTED}}{color:#172b4d} violate {color}[rfc4254 - section 4|https://tools.ietf.org/html/rfc4254#section-4]{color:#172b4d} that states that the response should be {color}{{SSH_MSG_REQUEST_FAILURE}}{color:#172b4d}.{color}_
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).
2.
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.
3.
_{color:#172b4d}Have you tried using the {color}[SSH_MSG_IGNORE|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic]{color:#172b4d} mechanism instead of global requests{color}_
yes, but the problem is not only to keep the connection alive. The problem is to know when the connection goes down. The proper way to do this is to send an SSH_MSG_GLOBAL_REQUEST with the want-reply flag. This is also how OpenSSH does. The differerence is that when you get the SSH_MSG_UNIMPLEMENTED flag in OpenSSH, it will instead count this as a valid reply, as this shows the server is alive and it is very obvious there will be no other reply.
BR
Patrik
> 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, 30000);
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST, "keepalive@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-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org