OpenSSH clients (in all releases I have been able to test with,
including 4.7p1) when talking protocol version 2 seem to be sending
SSH_MSG_CHANNEL_REQUEST messages with the want_reply field set to 0.
This leads to a problem when the server they interact with does not
support the service being requested.
If the channel request is for, say, command execution, and the
server does not support such a capability, a standards-compliant
server won't send anything back at that point - because the OpenSSH
client has set the want_reply field to 0. However, the OpenSSH client
seems to be assuming that this request will always be successful. That
is, that servers will always support this capability. Because of this
assumption, a deadlock ensues.
This is a bug in the OpenSSH client. It is true that for some
channel requests (e.g. things like, say, X11 and XON/XOFF requests)
the client can proceed (and does proceed) without the server replying
anything, but for others (most notably SHELL and EXEC) it can't. The
OpenSSH client should always set want_reply to 1 when sending such
requests, in order to prevent deadlocks like the one described above.
