Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a Linux box at work that I often log in to from home. The Linux box is on an internal network, but there's a box that spans both networks, so I can log in like so:

ssh -tA username@bridge.work.com ssh username@10.10.10.130

I have a couple of files sitting in ~/tmp that I would like to copy to my local machine. (let's call them ~/tmp/file1 ~/tmp/file2 and ~/tmp/file3 for the sake of argument)

I've seen something like this work:

ssh -tA username@bridge.work.com ssh username@10.10.10.130 'tar cf - ~/tmp/file*' | tar xf -

This would tar the files on the remote machine, send the result to stdout, then pipe the results to a local tar, which was unpacking data on local stdin.

Doesn't work:

On the remote machine, if I run

tar cf - tmp/file* | md5sum
f1b776364c10dfc20500f228399a7c63  -

From the local machine:

ssh -tA username@bridge.work.com ssh username@10.10.10.130 'tar cf - ~/tmp/file*' | md5sum
bc7436c9771ee2b4978ffd29b8b7ed36  -

I'm assuming that this is probably a byte ordering snafu across the network... I was eventually able to get around it by uuencoding the file, catting it across the network then uudecoding it locally... for some reason I couldn't get the syntax correct to be able to tar | uuencode on the remote side and uudecode | untar on the local side.

I'm looking for a good way of doing this all in one step; preferably something that I can wrap in a shell function.

share|improve this question
add comment

3 Answers

up vote 6 down vote accepted

Use the SSH ProxyCommand configuration option to in the configuration on your client. This allows you to make a direct connection to the destination.

Host remotebox
    ProxyCommand /usr/bin/ssh username@bridge.work.com "/bin/netcat -w 1 10.10.10.130 22"
    User username

scp remotebox:file local

share|improve this answer
    
Hmm. I'm getting bash: /bin/netcat: No such file or directory –  Barton Chittenden Oct 12 '11 at 0:25
    
By the way, I really like this solution... I've never played with the 'ProxyCommand' directive, and it's got me curious. I would have marked this as the accepted answer had this worked out of the box. Thanks for the education. –  Barton Chittenden Oct 12 '11 at 1:14
    
netcat needs to be installed on your bridge box. It is a pretty common tool. –  Zoredache Oct 12 '11 at 1:34
    
Aha. It's installed as /usr/bin/netcat on the bridge box. –  Barton Chittenden Oct 13 '11 at 9:27
    
... and the scp worked. Cheers! –  Barton Chittenden Oct 13 '11 at 9:31
add comment

You can set up port forwarding. Change your inital command to be:

ssh -TA username@bridge.work.com -L 2222:10.10.10.130:22

Then ignore this command. Open a new terminal and run one of:

ssh -p 2222 username_for_10.10.10.130@127.0.0.1
scp -P 2222 username_for_10.10.10.130@127.0.0.1 remote_file local_file

Whenever your local system gets a connection request on its localhost IP address port 2222, the SSH command that you ran first will forward that on to the remote system and have it issue a connection request to 10.10.10.130. This is all specified by the -L switch.

share|improve this answer
add comment

Byte ordering only applies to such things as IP headers (which have four-byte-sized addresses as a single unit), but does not affect higher-layer protocols which work with 8-bit bytes only -- IP, TCP, and SSH all guarantee that you receive data exactly as it was sent, byte by byte.

The problem is caused by the -t option to the first ssh. It forces allocation of a pseudo-tty for the first connection, which is only necessary for terminals (and terminal emulators) and will mangle certain data during the transfer. In particular, carriage returns (0x0D) will be automatically inserted before every linefeed (0x0A).

Just remove the -t option, and you will have a clean channel for transferring binary data.

share|improve this answer
    
This worked... I got a good tar file on the local side. Ironically, the difference in md5sum was a red herring: every time that I ran 'tar zcf - /home/username/tmp/file* | md5sum' on the remote machine, I got a different md5sum. –  Barton Chittenden Oct 12 '11 at 1:08
2  
@Barton: No, it wasn't. Your test in the question was done using plain tar, which always outputs the same data for the same directory and results in the same hash as well. (Your data was being corrupted by SSH.) The one in your comment, however, compresses the output with gzip (the z) option, which embeds the current timestamp in the gzip header, causing different hashes every time. –  grawity Oct 12 '11 at 8:24
    
Fascinating. Why is it that this is only the case when tar gzips a file? If I create 'asdf.txt' and run 'gzip -c asdf.txt | md5sum' twice in a row, I'll get the same checksum... oh... I get it... the gzip header holds the mtime of the file being gzipped... if that's a freshly created tar file, different mtime. –  Barton Chittenden Oct 13 '11 at 8:11
    
@Barton: In this case, the "mtime" is actually the current system time. When you are using gzip via tar -z, there is no "tar file"; there is only an anonymous stream that tar outputs and gzip compresses. –  grawity Oct 13 '11 at 11:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.