Linux – rsync: Permission denied (publickey) with SSH

cronlinuxpermissionsrsyncssh

I have a server on which I connect in SSH with my key files such as id_rsa.pub
I am using Debian on client and server side.

I followed a tutorial to disable root authentication and password use for more security (by configuring the /etc/ssh/sshd/sshd_config file on the server).

Until now, I could easily use rsync to synchronize my files from my computer to the server.

A few days ago, I used a cron job job and for that I had to reset my root password on the server side.

Since then, it has been impossible for me to use rsync in SSH;
I get the following message:

nextcloud@192.168.0.20: Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far)[sender]
rsync error: unexplained error (code 255) at io.c(235)[sender=3.1.3]

There are some similar topics, but I think my case is a bit different because I think the problem is due to resetting my password on the server. I have also asked a question on the Ask Ubuntu site,
but I think maybe people here are more expert in permission issues.

I have no idea how to fix the problem (I manage a little bit in terminal commands, but I'm not a computer expert). Could you help me, please?

For Your Information only, please find the tutorial tweaking the /etc/ssh/sshd_config to not use password:

#Uncomment or add the following line. 
#This allows the server to give its DSA footprint in case of an ssh connection.
HostKey /etc/ssh/ssh/ssh_host_dsa_key

#Then set the next parameter to 20s (for example). 
#This is the time during which a connection without being logged in will be opened. 
#If we had kept the good old password technique, leave 2 or 3 minutes to type it, it's not too much. 
#But since we're using the key now, we'll be logged in immediately. #So we can really reduce the thing and put it down to 20 seconds for example.
LoginGraceTime 20s

#this is the maximum number of attempts before being thrown by the server.... 
#Since with the key, no possible error, you can put it to 1 possible test.
MaxAuthTries 1

#Then, we will tell the SSH server where the keys are and tell it that we will use them as an authentication method
PubkeyAuthentication yes
AuthorizedKeysFile.ssh/authorized_keys

#And of course, we'll disable all other authentication methods
RSAAuthentication no.
UsePAM no
KerberosAuthentication no
GSSAPIA Authentication no.
PasswordAuthentication no

#Then, we will tell that we only allow users of the sshusers group (for more security)
AllowGroups sshusers

#The MaxStartups setting indicates the number of un-authenticated ssh connections you can launch at the same time. 
#2 is more than enough, knowing that with the keys, it's instantaneous.
MaxStartups 2

Best Answer

Oh no!

I just found the solution... My command was:

sudo rsync -avz -e "ssh -p <port>" <source> <destination>

But I had to do it simply (without sudo):

rsync -avz -e "ssh -p <port>" <source> <destination>

I'm not sure about the cause, but I think that the root user of my desktop computer was not allowed to access my server in SSH since the key was only for my classic Desktop user (so without sudo).

Can anyone please confirm? Thank you.

Related Question