How can rsync fail due to missing permissions if remote login occurs with root?

Question

I can't think of any reason why the transfer of a simple file with rsync -e 'ssh -p 19' -vvv /path/to/file [email protected]: 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 [email protected] 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 [email protected]:, doesn't help.

I'm using rsync 3.1.1 on Ubuntu 15.10.

Solution 1

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.

Solution 2

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 [email protected], while rsync is connecting to [email protected].
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.

Comments

[nKn]

Maybe related to this: stackoverflow.com/questions/7261029/…

[Kalle Richter]

@nKn Thanks, that wasn't it, but pushed me in the right direction (see answer below).

[Kalle Richter]

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.

[msc]

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.

[Jeff Whiting]

I agree, terrible error message! Mine was in /bin/rsync on the remote and /usr/local/bin on the local.