sshd sending eof to peer instead of SSH_MSG_CHANNEL_CLOSE.

[Damien Miller]

On Wed, 14 Apr 2010, Avi Albo wrote:

> I am using the ssh port forwarding feature. My configuration is as
> follows:
>
> On my server machine, running sshd, and app1.
>
> On my client machine, running ssh (client) and app2.
>
> The client connects to the server requesting remote port forwarding
> from port X on the server machine to port Y on the client machine.
>
> app2 is listening on port Y on the client machine.
>
> app1 connects to port X on the server machine.
>
> sshd (on the server machine) forwards the connection to the client
> machine, and the two applications begin to exchange data.
>
> app1 pushes bytes into the socket much faster than app2 can process,
> and there is a backlog on both machines.
>
> At some point, app1 gives up and terminates the session (by
> calling close()), as a result sshd on the server machine sends an
> SSH_MSG_CHANNEL_EOF to the peer.
>
> The two sides then wait. app2 does not know that its peer is gone,
> since its session with the ssh client is still active.
>
> ssh client, on the client machine does not terminate the session,
> because it hasn't received the SSH_MSG_CHANNEL_CLOSE message.

SSH protocol 2 channels are bidirectional, so they have a half-closed
state where one direction is closed but the other is open. CLOSE
messages are only send when both directions are closed (fully closed).
If app2 is backlogged then it might not respond promptly to the
half-close state, but you might be able to force the issue by having
app1 close both its input and output file descriptors.

Unfortunately, older OpenSSH and all non-OpenSSH implementations suffer
from a protocol deficiency where the half-closed signalling is missing
in one direction. If both ends are using a recent OpenSSH then this
shouldn't be a problem. For more details, search for "eow at openssh.com"
in the PROTOCOL file in the OpenSSH source distribution.

-d