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