PuTTY wish two-way-keepalives

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.