How can rsync fail due to missing permissions if remote login occurs with root?
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:
- You ssh to
[email protected], while rsync is connecting to[email protected]. - 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.