Re: closing a channel

[nisse%lysator.liu.se@localhost (Niels Möller)]

Markus Friedl <markus%openbsd.org@localhost> writes:

> Sure, but applications using ssh might behave different if the EOF
> is delayed (e.g. stderr is not closed at all) and not send an
> EOF in the other direction.

Can you say some more about the problems you see? I don't see that the
opensshd behaviour solves real problems. As for EOF sent by the
client, my experience is that one can't rely on clients sending EOF
(on a session) as the result of the server sending EOF.

Clients typically send EOF when they get EOF on stdin, and often not
at all (e.g. with "ssh host cat foo" command, a typical client never
sends any EOF, no matter what combination of EOF, "exit-status" or
CLOSE that the server sends. (Older versions of lsh did send EOF as a
response to "exit-status", but that's the only case I'm aware of. It
turned out to not be very useful, as no other clients seemed to do
that)).

I think the current opensshd behaviour of sending EXTENDED_DATA after
EOF is simply a minor bug that should be fixed sooner or later. Do you
have a good reason for keeping that behaviour?

The below is an excerpt from a log in an lsh bug report, where the
user connected to an opensshd server with the command

  $ lsh openserver "echo hej 1>&2"

> lsh: Registering local channel 0.
> lsh: Taking channel 0 in use, (local 0).
> lsh: client.c: Receiving exit-status 0 on channel 0
> lsh: Receiving EOF on channel 0 (local 0)
> lsh: Extended data on closed or non-existant channel 0
> lsh: Receiving CLOSE on channel 0 (local 0)

(The warning message above is not entire accurate in this case, what
it means is simply that lsh received extended data after eof. The
channel does exist and it isn't closed).

Best regards,
/Niels