| Summary: | client hangs against server lacking common channel requests | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | jca |
| Component: | ssh | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED FIXED | ||
| Severity: | minor | CC: | djm |
| Priority: | P2 | ||
| Version: | 4.7p1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 1452 | ||
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)
Mass update RESOLVED->CLOSED after release of openssh-5.1 |
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.