OpenSSH and non-blocking mode

[Larry Jones]

Dear OpenSSH developers,

OpenSSH setting non-blocking mode on its standard files creates serious
problems.

Setting non-blocking mode violates many of the semantics of how files
are supposed to behave and most programs (and most, if not all, stdio
libraries) are not prepared to deal with it.  That wouldn't be a problem
except that non-blocking mode is not a property of the file descriptor
but a property of the underlying file table entry and thus affects *all*
file descriptors that are bound to that file table entry, not just the
one used to set non-blocking mode.  Thus, you really shouldn't use
non-blocking mode unless you're in complete control of the underlying
file.  Since the standard files (stdin, stdout, and stderr) are
inherited from the parent process, that's never the case.  Consider:

        $ cat bigfile | wc -c
         10858893
        $ (ssh localhost sleep 120& sleep 3; cat bigfile) | wc -c
        cat: stdout: Resource temporarily unavailable
          270336

When ssh puts its stdout into non-blocking mode, it also puts cat's
stdout into non-blocking mode.  cat notices the problem, but doesn't
actually handle it correctly (most likely because it's using stdio and
thus *can't* handle it correctly), so the vast majority of the data just
disappears into the bit bucket.

I understand the necessity to keep ssh from blocking in order to keep
port-forwarding working, but wouldn't it be possible to do that by just
selecting for write before trying to write to stdout or stderr rather
than setting non-blocking mode?

-Larry Jones

My brain is trying to kill me. -- Calvin