openssh unix dev - Aug 2001 - Bugs: SSH sometimes failing to report exit-status and more

I have a few bug reports and some comments after upgrading from SSH
1.2.27 to OpenSSH 2.9p2 at a large university.

OpenSSH often fail to return the correct exit status from the remote
command if small amounts of data are transfered, SSH version is 2 and
ssh is run with no STDIN or with the -n option.  Below is an example.
Authentication method is hostbased and the file sizes are 1KB, 4KB and
8KB:

  [sturles at ulrik]~ $ for i in `seq 1 20`; do ssh -n pat cat 1kfile >
/dev/null || echo $i failed; done
  1 failed
  3 failed
  5 failed
  8 failed
  10 failed
  12 failed
  18 failed
  19 failed
  [sturles at ulrik]~ $ for i in `seq 1 20`; do ssh -n pat cat 4kfile >
/dev/null || echo $i failed; done
  10 failed
  [sturles at ulrik]~ $ for i in `seq 1 20`; do ssh -n pat cat 8kfile >
/dev/null || echo $i failed; done
  [sturles at ulrik]~ $ 

If run with -v, the difference between correctly reporting and wrong
reporting instances, is the following lines:

Correct:
  debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
  debug1: Exit status 0

Wrong:
  debug1: Exit status -1


More verbose versions:
 Correct:
  debug1: Sending command: cat 8kfile
  debug1: channel 0: open confirm rwindow 0 rmax 16384
  debug1: channel 0: read<=0 rfd 7 len 0
  debug1: channel 0: read failed
  debug1: channel 0: input open -> drain
  debug1: channel 0: close_read
  debug1: channel 0: input: no drain shortcut
  debug1: channel 0: ibuf empty
  debug1: channel 0: input drain -> closed
  debug1: channel 0: send eof
  debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
  debug1: channel 0: rcvd eof
  debug1: channel 0: output open -> drain
  debug1: channel 0: rcvd close
  debug1: channel 0: obuf empty
  debug1: channel 0: output drain -> closed
  debug1: channel 0: close_write
  debug1: channel 0: send close
  debug1: channel 0: is dead
  debug1: channel_free: channel 0: status: The following connections are open:
    #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1)

  debug1: channel_free: channel 0: dettaching channel user
  debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.6 seconds
  debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
  debug1: Exit status 0

 Wrong:
  debug1: Sending command: cat 1kfile
  debug1: channel 0: open confirm rwindow 0 rmax 16384
  debug1: channel 0: read<=0 rfd 7 len 0
  debug1: channel 0: read failed
  debug1: channel 0: input open -> drain
  debug1: channel 0: close_read
  debug1: channel 0: input: no drain shortcut
  debug1: channel 0: ibuf empty
  debug1: channel 0: input drain -> closed
  debug1: channel 0: send eof
  debug1: channel 0: rcvd eof
  debug1: channel 0: output open -> drain
  debug1: channel 0: rcvd close
  debug1: channel 0: obuf empty
  debug1: channel 0: output drain -> closed
  debug1: channel 0: close_write
  debug1: channel 0: send close
  debug1: channel 0: is dead
  debug1: channel_free: channel 0: status: The following connections are open:
    #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1)
  
  debug1: channel_free: channel 0: dettaching channel user
  debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.6 seconds
  debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
  debug1: Exit status -1



ssh -2 also always report 0 byted trasfered, regardless of real amount:
  debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.6 seconds

If compression is enabeled, however (btw, protocol verson 2 ignores
CompressionLevel -- this is not documented), it reports the total
amount of data transfered:
  debug1: compress outgoing: raw data 777, compressed 709, factor 0.91
  debug1: compress incoming: raw data 9656, compressed 1663, factor 0.17


The manual claims compression slows things down on fast networks, but
my client uses less CPU when compression is enabeled (with a low
CopmressionLevel) and the data transfered is not already compressed.
I guess decompression is cheaper than decryption, and compressed data
means less data to decrypt.  This is highly data dependant and
probably architecture dependant too, but generally I think using
compression is a good idea.


And a comment about having "ForwardX11 no" as default: When lusers
don't get their X programs to work, they ask for advice from some
other luser, who tells them to set $DISPLAY and do "xhost +" localy.
(Usenet, mailing lists and universities are full of lusers giving bad
advice.)  Users with a clue, who know what "xhost +" mean, also knows
when to enable or disable X11 forwarding themselves, so the default
doesn't do much for security for users who know why they are using ssh
in the first place.  I think having "ForwardX11 yes" as default is far
more secure, as it makes the clueless lusers -- the ones we need to
protect from doing stupid things -- less likely to disable security
completely with "xhost +".


-- 
Sturle      All eyes were on Ford Prefect. Some of them were on stalks.
~~~~~~           -- Douglas Adams, So long, and thanks for all the fish