Bug 1384 - client hangs against server lacking common channel requests
Summary: client hangs against server lacking common channel requests
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 4.7p1
Hardware: All All
: P2 minor
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_5_1
  Show dependency treegraph
 
Reported: 2007-10-26 10:14 AEST by jca
Modified: 2008-07-22 12:20 AEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jca 2007-10-26 10:14:00 AEST
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.
Comment 1 Damien Miller 2008-05-08 23:12:18 AEST
A fix for this bug has been committed and will be in OpenSSH 5.1:


> CVSROOT:        /cvs
> Module name:    src
> Changes by:     djm@cvs.openbsd.org     2008/05/08 07:06:11
> 
> Modified files:
>         usr.bin/ssh    : clientloop.c clientloop.h ssh.c
> 
> Log message:
> Use new channel status confirmation callback system to properly deal
> with "important" channel requests that fail, in particular command exec,
> shell and subsystem requests. Previously we would optimistically assume
> that the requests would always succeed, which could cause hangs if they
> did not (e.g. when the server runs out of fds) or were unimplemented by
> the server (bz #1384)
> 
> Also, properly report failing multiplex channel requests via the mux
> client stderr (subject to LogLevel in the mux master) - better than
> silently failing.
> 
> most bits ok markus@ (as part of a larger diff)
Comment 2 Damien Miller 2008-07-22 12:20:12 AEST
Mass update RESOLVED->CLOSED after release of openssh-5.1