[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 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] [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 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
[RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git
Hi, The vote has passed with the following results: +1 Guillaume Nodet (binding) +1 Emmanuel Lécharny (binding) +1 Jeff Maury (binding) +1 Roy Lenferink (non-binding) No -1 votes have been cast. To continue I'll need some help from a PMC member to request the mina-site repository here [1] Once requested I'll open the pull request against it. I need someone with commit privileges to help initially because of branch creation, moving around some content, initial site generation, cleanup of SVN etc. which requires having commit rights to the repository (I'm more than willing to help out with this so let me know when someone is available). After having the site in place, I'll create a Jenkins job, test whether it works and open a pull request against the infrastructure-puppet repository to make the actual switch from svn to git. Best, Roy [1] https://gitbox.apache.org/setup/newrepo.html - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [VOTE][LAZY] Move site from CMS/SVN to Hugo/Git
Adding my +1 (non-binding) as well. On 2020/02/19 13:45:51, Roy Lenferink wrote: > Hi MINA community, > > After last weeks proposal [1] I'd like to start a formal vote for moving over > from the current Apache > CMS (and SVN) to use Hugo and git. > > Short recap about Hugo: Hugo is a static site generator which is already > having more stars on > GitHub than Jekyll. It is easy to get started with (single static binary > without dependencies) and it is > really doing well performance wise. > > [ ] +1 for moving over from the Apache CMS / SVN to Hugo / Git. > [ ] 0 I don't have a strong opinion on this > [ ] -1 for not moving over, in this case please explain why > > This vote will be open for the usual 72 hour period. Lazy consensus applies: > if no -1 votes are being > cast within the voting period, the vote passes. > > --- > Roy > > [1] > https://lists.apache.org/thread.html/r20a75ad7f2509ba29413ef198d2a8d1aa3912367fd4f7921061fb060%40%3Cdev.mina.apache.org%3E > > - > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org > For additional commands, e-mail: dev-h...@mina.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-968) SshClient times out during keep-alive, when SSH_MSG_GLOBAL_REQUEST is replies with SSH_MSG_UNSUPPORTED
Patrik Ek created SSHD-968:
--
Summary: 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
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
