bug in channel_still_open() ?

[Richard E. Silverman]

On Thu, 5 Apr 2001, Markus Friedl wrote:

> it depends on what
> 	$ ssh -N -L xxx
> 
> should do.

I think users expect it to behave just as it would without the -N, except
that stdin/out/err are not connected to a remote program.  That is, it
should persist, performing port forwarding, until the user kills it.

Having a mode in which a forwarding goes away the second time its instance
count hits zero is also useful; SSH2 has "one-shot" forwardings (-fo) for
that purpose.

> how do you close the ssh session if a "larval" channel counts a 'open'?

I'm not clear on the use of the "larval" state in the OpenSSH code, which
is why I phrased it as a question.  Since -N removes the usual ways to
close the SSH connection (exit the remote shell/command, type "~.", etc.),
the user has to kill the client manually with ^C, "kill", etc. anyway.

The code appears to assume that normally, the server should end the SSH
session when there are no open channels remaining.  This only seems
reasonable if you think about the typical behavior of a standard
command-line SSH client; I don't think it's correct in general.  There
need not be any session channel, larval or otherwise.  The OpenSSH client
always opens a channel which it calls "client-session", even with -N; it
just never issues an SSH "exec" request on it if -N is given.  But there's
no protocol requirement for this -- the ssh.com Windows client, when given
the analogous option ("disable terminal" checkbox), establishes no
channels at all.

More generally, I see no reason to assume that a channel count of 0 in the
connection protocol means that the transport should be closed.  I think a
client should expect to be able to establish a transport session, start
the connection protocol, start some channels for whatever purposes, close
them all, wait an hour, and then start some more channels.

-- 
  Richard Silverman
  slade at shore.net