[
https://issues.apache.org/jira/browse/SSHD-968?focusedWorklogId=394185&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-394185
]
ASF GitHub Bot logged work on SSHD-968:
---------------------------------------
Author: ASF GitHub Bot
Created on: 27/Feb/20 14:10
Start Date: 27/Feb/20 14:10
Worklog Time Spent: 10m
Work Description: lgoldstein commented on issue #114: SSHD-968 interpret
SSH_MSG_UNIMPLEMENTED response to a global request as its failure
URL: https://github.com/apache/mina-sshd/pull/114#issuecomment-591989830
>> I thought you wanted a less invasive fix ;-)
I did not mean less invasive as much as less aware of the purpose of the
changes. It is less invasive as far as existing methods since it only
introduces new ones.
>> I don't really like the artificial split with the introduction of the
preProcessEncodeBuffer method as it's only called from AbstractSession. encode,
while the preProcessEncodeBuffer is defined in the SessionHelper and overriden
in the AbstractSession. This looks rather complex instead of simply adding the
few needed lines in the existing encode method
(efdb7c3#diff-916a03c44b5846431681a4411891d952R843-R849).
True, but it was the only way that I could come up with - IMO `encode`
already does so much (lots of code for one method) so I thought it would make
sense to split it rather than add to it. Anyway, like I said it opens up the
door for future fixes/extension - e.g., perhaps one of the derived classes from
`AbsractSession` needs something else.
>> Anyway, if you really wanted something simple, we could go for
gnodet@cdefec7 which is much simpler ;-)
True, but IMO this fix while more complex feels more robust. Any objections
to merging it ?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 394185)
Time Spent: 50m (was: 40m)
> 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: 50m
> 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,
> 30000);
>
> 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
