openssh unix dev - Oct 2011 - Channel life span

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Basic context for my questions:

Client (ssh) and server side (sshd) where the client use -L option for a
direct-tcpip channel and forward all requests. (All Linux and openssh version
5.9p1).

$ ssh -L8080:<some-ip>:8181 ...

I noticed that when a third client send data to the local port (8080) used for
forwarding, a channel is created:

...
debug1: channel 1: new [direct-tcpip]
debug1: server_input_channel_open: confirm direct-tcpip
debug3: channel 1: waiting for connection
...

the request then pass through the tunnel, reply comes back and then the channel
receives an EOF (debug2: channel 1: rcvd eof). Both the ssh client and sshd
server agree on closing the channel and it's freed. Seems the normal
behavior.

So, I did try, using a third part lib for SSH (libssh2), to recreate a
direct-tcpip channel and *keep* the channel open (not sending the EOF) in order
to send data later on (where the time between writes on the channel is unknown).
However, here is what's happening. After the first write to the channel, I
read
the data back (reply), and keep the channel open (don't send the EOF on my
side). A quick 5 seconds later, I get this on the sshd (server side):

debug2: channel 1: read<=0 rfd 8 len 0
debug2: channel 1: read failed
debug2: channel 1: close_read
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed

and the channel is *not* usable again for transmission... I have to recreate
one...

I did look at the openssh code to understand that behavior since it's not
define
in the RFC 4254 that it should "close" after a timeout. I'm sure I
am missing
something here that I'm doing wrong but I get this behavior even with the
ssh
client in the openssh code tree.

So my questions are: Is it normal for channel to be open/close at *each*
different data transmission ?  and if not, how can I keep a channel alive for an
undefined period of time without having an EOF sent to me from the sshd server.

Thanks to all! I know it's long... but the problem is not that trivial to
explain by mail :P. Feel free to ask for more details!

Cheers!
David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJOkx9yAAoJEELoaioR9I02drwIAMh9mYLpJYaM3ss5S7cD5BvD
J6/SzDMOgceYijVqgU5JIZJj2l9H7rwDvwZAj178cUv5DSjfHfF1X1WEGALTI6EA
son9usUM0zhkJh+Nsg4Wl2wWPpi0UOLmfQ4yb4dMkxpAU8QrcVCYE0PqCjSVRdcZ
A2lOZdAjEvwnR4QJhiRC2Yxj+h88x/wo0v03ysW9M0bTUj/bLCD8EaNlkopOU1+I
xGDhhcTDpq+e2RYf2wMWBzRRBhqEcNpaUqOSCkiKw4wfdq+8m3UmClRUBngTuPp0
y+Ldb7L81Vtt0niCuIMbj4qjxTSR9KxBlD0j2RMz/w4TCJhDwDRJtjFrx82GLRE=jdEM
-----END PGP SIGNATURE-----

On Mon, 10 Oct 2011, David Goulet wrote:
> So, I did try, using a third part lib for SSH (libssh2), to recreate
> a direct-tcpip channel and *keep* the channel open (not sending the
> EOF) in order to send data later on (where the time between writes on
> the channel is unknown). However, here is what's happening. After the
> first write to the channel, I read the data back (reply), and keep the
> channel open (don't send the EOF on my side). A quick 5 seconds later,
> I get this on the sshd (server side):
>
> debug2: channel 1: read<=0 rfd 8 len 0
> debug2: channel 1: read failed
Whatever you are talking to on the server has closed its standard output
or otherwise done something that triggered a failed read. The code that
emits this message is channels.c:channel_handle_rfd() and if you read it,
you'll see that there is no other way that this message can be generated.

-d

Hi,

David Goulet wrote:
> $ ssh -L8080:<some-ip>:8181 ...
> 
> I noticed that when a third client
What are the other two clients you refer to?

What is this third client you are refering to?

What protocols are being used? 8080 is usually HTTP.

On IRC yesterday you told me that you use SSH inside the tunnel.

> send data to the local port (8080) used for forwarding, a channel
> is created:
"send data" is not so accurate. When you start ssh with -L, the
client will socket() bind() listen() and accept() on port 8080 on the
system where the client runs.

When a program later does socket() and connect() to port 8080 where
the ssh client is listening, *then* the ssh client tells the sshd it
has logged into that the client side wants to open a direct-tcpip
channel, and to where. The sshd then does socket() and connect() and
then passes data between wherever it connected to, and the channel.
I find that this is very clearly described in the SSH RFC that covers
port forwarding. I urge you to read it.

> the request then pass through the tunnel,
What type of request?

> reply comes back
What type of reply?

A complete understanding of the protocol you use inside the tunnel is
required for port forwarding over SSH just like it is for any other
network transport.

> and then the channel receives an EOF
Also not so accurate, "the channel" can not receive anything, it is
important to clearly understand what happens where, and why. Is this
EOF received by the ssh client or the sshd?

> So, I did try, using a third part lib for SSH (libssh2), to recreate
> a direct-tcpip channel and *keep* the channel open (not sending the
> EOF) in order to send data later on (where the time between writes
> on the channel is unknown). However, here is what's happening.
> After the first write to the channel, I read the data back (reply),
You must clearly say what you are communicating over the channel in
order to get any help.

> and keep the channel open (don't send the EOF on my side).
What is your side?

What are you communicating?

What is your idea of "the EOF"?
I mean: How would you "send the EOF" if you wanted to?

> A quick 5 seconds later, I get this on the sshd (server side):
> 
> debug2: channel 1: read<=0 rfd 8 len 0
> debug2: channel 1: read failed
I find this completely clear. I'm glad you also provided the
information that this happens on the server side.

So you already know that the sshd has connect() somewhere and is
constantly transferring data between that somewhere and the channel.

Here the sshd tells you that on the outgoing TCP connection that it
opened on behalf of channel 1, the read() system call returned <= 0,
which means that either there is a local OS error or that the other
end of this TCP connection made by sshd has closed the connection.

> debug2: channel 1: send eof
And thus sshd notifies the ssh client that there will be no more data
on this channel.

> and the channel is *not* usable again for transmission...
Obviously not, the TCP connection from sshd that was used to deliver
data received by sshd in the channel has been closed, so how would
you use the channel anymore?

> I did look at the openssh code to understand that behavior since
> it's not define in the RFC 4254 that it should "close" after
a
> timeout.
There is no timeout involved. As I tried to explain to you already
yesterday the behavior you are seeing depends completely on the
server you are talking to and the protocol that you are using.


//Peter