Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
Anecdotal evidence suggests that at least one type of router is not
fooled by PuTTY's current SSH keepalive mechanism (sending
SSH_MSG_IGNORE): it ignores them and disconnects idle
sessions regardless. I asked the user in question to experiment with
using repeat key exchanges as an alternative form of keepalive, and
that turned out to work fine.
This leads me to suspect that the router has noticed that the
SSH_MSG_IGNORE keepalives only transfer data in the
client-to-server direction: although TCP packets must come
back the other way carrying acks, no actual data is
transferred down the TCP connection from server to client. Rekeys
transfer real data in both directions, so they work better for this
purpose. (However, they're very CPU-intensive compared to what a
keepalive ought to be.)
It wouldn't be very difficult to rig up an alternative form of
keepalive, at least in SSH-2, which requested an actual response
from the server. The obvious approach would be to invent a spurious
SSH_MSG_GLOBAL_REQUEST ID which no servers would
understand, so that they would respond with
SSH_MSG_REQUEST_FAILURE. Much like the OpenSSH "client
alive" feature, in fact.
I envisage this being implemented as a checkbox with wording
something along the lines of "Use two-way keepalives where
available"; then we could implement it in SSH-2 immediately, and add
it to other back end protocols if and when we thought up ways to do
it. (For example, it's not entirely impossible that there might be
some fiddly way to make it work in Telnet, perhaps by periodically
sending IAC WILL followed by a non-existent option
number; but I haven't tried it and can't be sure.)
Audit trail for this wish.