PuTTY semi-bug winadj-success
summary: Bombing out with 'Received SSH_MSG_CHANNEL_SUCCESS for "firstname.lastname@example.org"'
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
priority: high: This should be fixed in the next release.
present-in: 2008-03-28 2008-12-01
fixed-in: r9185 3a649ed4edf0248afdc4c67e44ef2cdd8f4d472a 2011-07-02 (0.61)
We've had a few reports of SSH connections bombing out with the
following error message, reportedly under load:
PuTTY Fatal Error
(X) Disconnected: Received SSH_MSG_CHANNEL_SUCCESS for
[ OK ]
This message has only existed in PuTTY since the
feature was implemented, which was after we released 0.60; so only
people using development snapshots, or third-party code incorporating
development code, should have seen this.
On the face of it, it looks like the SSH server -- which in all the
cases positively identified so far is "boks_sshd" -- is incorrectly
responding to our unilaterally-defined channel request message with
SUCCESS, which it should never do since it's something we made up.
mandates a FAILURE response, but that's only a restatement of the
RFC 4254 requirement for a FAILURE response to requests that
aren't understood -- we don't expect any server to specifically
handle this message.)
The maintainers of boks_sshd, foxt.com, acknowledged this server issue
(case 090916-090424). It was fixed in BoKS 6.5.4, released on June 2,
The obvious workaround for the behaviour of old versions of this
server behaviour is to just ignore the protocol error, and quietly
treat a (bogus) SUCCESS response to "winadj@putty" the same as a
FAILURE response -- it won't do any harm, since all we're interested
in is when the server replies; we don't actually care about the
content. So we did that.
Using "Portable PuTTY from the Xming project" (not our code)
but also seen with 2008-12-01:r8355
Server claims to be "SSH-2.0-OpenSSH_4.3" -- however, if that
were really true I'd have expected many more reports, and
looking at the OpenSSH 4.3/p1/p2 source code I can't see how this
can happen; apparently the server is actually "boks_sshd" from
Seems to happen readily -- a few "ls -ltr"s are sufficient to break it
Session log shows this happening the very first time we send one of
our "winadj" requests; there aren't any ambiguities with multiple
outstanding requests or anything like that.
(but also reported with PSFTP 2008-03-28:r7934:
Reported as failure shortly after 1Gbyte of a file transfer.
Again, server claims to be "SSH-2.0-OpenSSH_4.3"
Again, shows up under light load ("ls -l" etc)
Again, session log shows it happens on the first "winadj" we send.
Again, shows up with "ls -l" type activity.
Server claims to be "SSH-2.0-OpenSSH_3.8.1p1" but is in fact
If you want to comment on this web site, see the