[ 
https://issues.apache.org/jira/browse/SSHD-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&D 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&D 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,
>  30000);
>  
> PropertyResolverUtils.updateProperty(client,ClientFactoryManager.HEARTBEAT_REQUEST,
>  "[email protected]");{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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to