If a persistent write error ('disk full') occurs when writing to
stdout of the 'ssh' command, the command can hang and will not produce
an error message.

I can reproduce both problems with OpenSSH 3.7.1p2 on Linux, and the
code affected appears to be common with the current OpenBSD anoncvs
version of OpenSSH.

The write() call that fails is in chan_handle_wfd.  This goes on to
call chan_write_failed, which since the channel is in CHAN_OUTPUT_OPEN
or CHAN_OUTPUT_WAIT_DRAIN (depending on how much output is being sent)
will simply flush the data and then close the file descriptor.
No error message is provided.

[Note that client_process_output does provide an error message in a
similar situation, but it wasn't used since I was using the 2.0
protocol.]

Now, suppose this happens while data is still being sent from a
command running on the SSH server.  When the client gets into
channel_input_data, it will notice that the output channel is no
longer open, and simply return.  This means it won't update
c->local_window.  It also won't call channel_handle_wfd, which would
in any case return directly, which means that c->local_consumed won't
be updated either.  This means that channel_check_window won't ever
send a SSH2_MSG_CHANNEL_WINDOW_ADJUST message, and eventually the
server will stop sending and wait for the client to catch up, which
will never happen.

I could reproduce this easily on Linux by doing

ssh localhost dd if=/dev/zero bs=1024 count=256 > /dev/full

to see the hang, and

ssh localhost dd if=/dev/zero bs=1024 count=1 > /dev/full

to see it terminate with no error message.  If you don't have
/dev/full, just create it as an empty, writable file and then fill up
/dev :-).