1

So I was trying to download a file from a remote host connected with SSH to a local folder on my Mac using rsync. The command I used is:

$ rsync --progress -avz -e "ssh root@1.2.3.4 -i ~/.ssh/keyFile" root@1.2.3.4:/path/to/files/ ~/Downloads/

And here is what is prompted:

root@1.2.3.4's password: [I typed the password here]
bash: 1.2.3.4: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.3]

It seems odd that the remote host address 1.2.3.4 is interpreted as a command?! I am not sure how and why this happens. How could I update the command to achieve expected result and start to copy the file?

3

I'm pretty sure that you don't want to include the user@host part of the ssh command within the -e flag. Try

rsync --progress -avz -e "ssh -i ~/.ssh/keyFile" root@1.2.3.4:/path/to/files/ ~/Downloads/
  • WOW! Yes! It works!! This is literally mind-blowing! – jackxujh Sep 28 '18 at 16:04
1

The ssh command, when used with the -e (or --rsh) option in rsync, should not need to mention the remote host by name as this is part of the source specification (in your command).

In your case, it would be enough to use

rsync --progress -avz -e "ssh -i ~/.ssh/keyFile" root@1.2.3.4:/path/to/files/ ~/Downloads/

rsync will execute the command given in -e together with the source path. You can see the exact command being executed if you use yet another -v. It will most likely look something like

opening connection using: ssh -i "~/.ssh/keyFile" root@1.2.3.4 -l root 1.2.3.4 rsync --server --sender -vvlogDtpre.iLfxC . /path/to/files/

Here, you can see that 1.2.3.4 would be interpreted as a command to be executed on the remote host as user root (taking the actual command that ought to be executed as command line arguments).

rsync starts a "sender" on the source side of the file copy, and a "receiver" on the destination side. These two processes are then communicating the actual data and checksums etc. between each other to carry out the file copy. The ssh command that you see above is the command that rsync uses to (try to) start the sender on the remote host. The --server --sender etc. are internal command line flags that rsync uses for this purpose. The rsync manual basically says "don't use these options yourself".

In your case, you can see in the error message that the receiver (rsync running locally) is having problems communicating with the sender on the remote host. This is because the sender wasn't started correctly, and this in turn was due to the erroneous ssh command.

  • Thank you for the explanation! But could you elaborate a little on the second command in your post? Is it a pseudo-command? And what is -vvlogDtpre.iLfxC? – jackxujh Sep 28 '18 at 16:07
  • @jackxujh rsync starts a "sender" on the source side of the file copy, and a "receiver" on the destination side. The ssh command that you see is the command that rsync uses to start the sender on the remote host. The --server --sender etc. are internal command line flags that rsync uses for this purpose. The rsync manual basically says "don't use these options yourself". – Kusalananda Sep 28 '18 at 16:10
  • so do you mean that if I use -vv with rsync, I will see that line of prompt? Like some sort of expanded prompt? – jackxujh Sep 28 '18 at 16:15
  • @jackxujh If you use -vv then rsync will tell you more verbosely what it is doing, including how it tries to connect to the other host, yes. And even more verbosely with -vvv. – Kusalananda Sep 28 '18 at 16:17
  • 1
    Oh, I got it! The more v I use, the more detailed the log or prompt I get. – jackxujh Sep 29 '18 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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