Description of Problem: When transferring finite data streams, ssh exits early. Version-Release number of selected component (if applicable): 2.9p2-9 (also happened in RH 7.2 release RPM) How Reproducible: ssh -n othermach cat bigfile > bigfile Steps to Reproduce: 1. set up ssh permissions 2. start ssh-agent, load keys 3. make bigfile on othermach 4. execute command above 5. compare file sizes Actual Results: on oobleck (Intel RH6.2, patched, openssh-2.3.0p1-1): yes | dd bs=1024 count=1000 of=/tmp/jht ls -l /tmp/jht -rw-r--r-- 1 jh jh 1024000 Oct 23 18:23 /tmp/jht on glup (Intel RH7.2, patched, openssh-2.9p2-9 ssh -n oobleck cat /tmp/jht > jht & ls -l jht -rw-r--r-- 1 jh jh 969216 Oct 23 18:24 jht Expected Results: no output, all data transferred Additional Information: This is particularly troublesome in the following idiom: ssh -n oobleck "(cd /usr ; tar cf - local)" | tar xpf - & ...which has always worked, until now. The larger the data stream, the more data are lost. Perhaps it is forgetting not to count the periodic checksum data in the number of bytes transferred? The data that are transferred match the begining of the file being transferred. --jh--
scp on the file does not have the same problem --jh--
This is the flipside of the hangs-on-exit problem, and is specific to the version of OpenSSH running on the server you're using. Update the server to 2.9.x (or better yet, the just-released 3.1) and you should stop seeing data truncations.