&
SEO LEO
Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
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.)