6

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 [email protected] ssh [email protected]

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 [email protected] ssh [email protected] '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 [email protected] ssh [email protected] '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.

Improve this question
0

3 Answers 3

Reset to default
6

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 [email protected] "/bin/netcat -w 1 10.10.10.130 22"
    User username

scp remotebox:file local

Improve this answer
6
  • Hmm. I'm getting bash: /bin/netcat: No such file or directory
    – Barton Chittenden
    Oct 12, 2011 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, 2011 at 1:14
  • netcat needs to be installed on your bridge box. It is a pretty common tool.
    – Zoredache
    Oct 12, 2011 at 1:34
  • Aha. It's installed as /usr/bin/netcat on the bridge box.
    – Barton Chittenden
    Oct 13, 2011 at 9:27
  • ... and the scp worked. Cheers!
    – Barton Chittenden
    Oct 13, 2011 at 9:31
6

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

ssh -TA [email protected] -L 2222:10.10.10.130:22

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

ssh -p 2222 [email protected]
scp -P 2222 [email protected] 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.

Improve this answer
4

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.

Improve this answer
8
  • 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, 2011 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.
    – u1686_grawity
    Oct 12, 2011 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, 2011 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.
    – u1686_grawity
    Oct 13, 2011 at 11:58
  • I also found that -t was messing up the stream. The problem is, I want to define a shell script or alias as ssh -[t]A bridge.work.com ssh 10.10.10.130 and I need two of them, for interactive and non-interactive each!
    – musiphil
    Oct 9, 2014 at 0:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .