+1 vote
by (520 points)

we fixed this internally by addding the following to the SshChannel.cs file in the OnRequestReceived function.

        //NOTE (VAE): This prevents wrong things from happening because of a failure to handle ssh keepalive requests, seen on Cisco Wireless and F5 Network devices
        case "keepalive@openssh.com":
            if (!_closeSent)
        // VAE

1 Answer

0 votes
by (147k points)
edited by

Update: Rebex SSH used replied even to requests with WantReply=false. This has been fixed in Rebex Total Pack R5.1.

Thanks for bringing this to our attention!

It looks like the client-side handling of SSH_MSG_CHANNEL_REQUEST packets in Rebex SSH does not conform to RFC 4254, and we will address that in the next release.

However, the proposed solution does not seem to be a proper one either. According to the comment in OpenSSH's server-side code where the keepalive@openssh.com is sent, the expected behavior for the SSH client is to simply respond with a SSH_MSG_CHANNEL_FAILURE packet, which is also what RFC 4254 says.

So we'll address this in a standard-compliant way first. Hopefully, that would address the issues you discovered as well. If not, we would add a workaround later.

by (520 points)
Excellent, thanks