2

I can't think of any reason why the transfer of a simple file with rsync -e 'ssh -p 19' -vvv /path/to/file root@192.168.179.3: fails with

opening connection using: ssh -p 19 -l root 192.168.179.3 rsync --server -vvve.Lsfx . .  (11 args)
Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]
[sender] _exit_cleanup(code=12, file=io.c, line=226): about to call exit(12)

when ssh login ssh -p 19 root@192.168.179.3 works fine. cat [/path/to/file] for the local file suceeds and permissions are 664 and owner is the user invoking rsync. The file is located in /tmp/.

Specifying the absolute path in the -e argument, i.e. rsync -e '/usr/bin/ssh -p 19' -vvv /path/to/file root@192.168.179.3:, doesn't help.

I'm using rsync 3.1.1 on Ubuntu 15.10.

8

Another possible interpretation of ssh or rsync giving Permission denied, please try again.. The reasons is that the remote rsync is in an unusual location and has to be specified with --rsync-path on the sender side (see https://stackoverflow.com/questions/7261029/how-to-solve-rsync-error-error-in-rsync-protocol-data-stream-code-12-at-io-c#comment22193023_12286054).

Dear ssh devs, please stop this nonsense! The number of error cause which trigger Permission denied, please try again. grows and grows, please find it in your heart to provide users with any usable feedback - you didn't implement anything in this direction so far which I'm telling after using ssh for years now and encountering dozens of very clear and explainable reasons for failures which just end up in Permission denied, please try again.. No one can understand that!

The fact that the OS produces this message and can't be change doesn't mean anything. You're responsible for the feedback your software provides to the user and if Permission denied, please try again. is given for the very easy to communicate reasons of failure above something is very wrong - just print remote binary not found, please use --rsync-path on the sender side instead! See, that wasn't so hard.

  • It's not that the remote rsync is in an unusual location. It is that it is in a different location than the local one. In my case remote was in /usr/bin, which is hardly unusual, local was in /opt/usr/bin. – msc Nov 26 '18 at 12:12
1

The error message doesn't say anything about file permissions. Rather, it's the standard ssh error message saying that the login itself was not allowed – either due to wrong password, or the server configuration disallowing logins by root.

Note that there are several differences between your "test" and the rsync command:

  1. You ssh to root@1.2.3.4, while rsync is connecting to root@192.168.179.3.
  2. You do not specify a port, thus connecting to standard SSH port 22, while rsync has the port 19 specified. It is possible that these ports are handled by two separate sshd daemons, with different configurations.
  • I just pasted the output of the wrong command, sorry. Of course, I'm connecting to 192.168.179.3 on port 19, not 1.2.3.4 on port 22. There's no daemon listening on port 22. Login by root to 192.168.179.3 on port 19 works. – Karl Richter Dec 24 '15 at 22:27
0

Just putting my solution here in case it's useful for anyone else.

I was trying to use rsync to copy files to an EC2 instance. The same command had been working fine for a good while, but then broke. None of the solutions I found online really helped.

By ssh-ing into the remote server and running ls -l in the location I was copying to, I found that the build folder had been created by root while all the others had been created by ubuntu. The permissions issue came from trying to copy my local build folder to the remote, so removing the local build folder (which shouldn't have been getting copied anyway) solved the problem for me.

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.