mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lyor Goldstein (Jira)" <j...@apache.org>
Subject [jira] [Commented] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replies with SSH_MSG_UNSUPPORTED
Date Sat, 22 Feb 2020 16:54:00 GMT

    [ https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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,
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


Mime
View raw message