PuTTY semi-bug ssh-close-vs-request

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Trouble when SSH channel closed with outstanding requests
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
difficulty: taxing: Needs external things we don't have (standards, users etc)
fixed-in: r10200 aaaf70a0fc0f071b9e9c6a51606c78b16a464841 2014-07-07 (0.64)

There's been a long-standing problem with closing channels within an SSH session due to an ambiguity in the SSH-2 specification about what happens to CHANNEL_REQUESTs that are outstanding at the point a channel is closed, and a consequent variance in behaviour among SSH implementations. This leads to a small probability of trouble each time a channel is closed when connected to certain servers, which shows up particularly when forwarding X connections or browser traffic.

A discussion on the IETF SSH protocol implementers' list in April 2014 yielded a consensus (that channel closure cancels outstanding channel requests). As of this change (first released in 0.64), PuTTY implements and expects the consensus behaviour, and has a bug-compatibility mode 'Replies to channel requests after channel close' for servers that implement the other common behaviour (which detects OpenSSH prior to 6.7 automatically).

In versions of PuTTY prior to 0.63 (which implemented what is now the consensus behaviour), this confusion could lead to symptoms such as PuTTY closing connections with messages like "Disconnected: Received SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 257" when connecting to servers like OpenSSH prior to 6.7.

PuTTY's behaviour changed in 0.63, to what is now considered incorrect behaviour, in pursuit of `half-closed'; it held off sending CHANNEL_CLOSE itself until it had seen responses to all its outstanding channel requests. Unfortunately this could lead to hangs when talking to servers implementing what is now the consensus behaviour (such as Dropbear, which changed to this behaviour in 0.52 according to our notes).

In 0.64, PuTTY's behaviour reverted to what is now the consensus. While users should not see a regression with old OpenSSH due to the automatic bug detection, server implementations not covered by that detection may cause a recurrence of the "nonexistent channel" message, in which case you'll have to set the bug-compatibility setting manually.

(Since the situation arises mostly with the `winadj' messages PuTTY has sent since 0.61, a partial workaround for PuTTY 0.61, 0.62, and 0.63 was to set the "Chokes on PuTTY's SSH-2 'winadj' requests" bug-compatibility mode.)


If you want to comment on this web site, see the Feedback page.
Audit trail for this semi-bug.
(last revision of this bug record was at 2016-12-27 11:40:21 +0000)