openssh unix dev - Apr 2010 - sshd sending eof to peer instead of SSH_MSG_CHANNEL_CLOSE.

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.

I am not sure what sshd on the server machine is waiting for. Probably
waiting for the ssh client to consume all of the backlog.

 

 

Finally, my question:

 

Is there a way to force sshd (on the server machine) to send
SSH_MSG_CHANNEL_CLOSE and terminate the session immediately?
 
**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or
entity to which it is addressed and may contain information that is privileged,
confidential, or otherwise protected from disclosure. Distribution or copying of
this e-mail, or the information contained herein, to anyone other than the
intended recipient is prohibited.

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