rsync: Permission denied (publickey) with SSH

11,362

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.

Share:
11,362

Related videos on Youtube

prog-amateur
Author by

prog-amateur

Updated on September 18, 2022

Comments

  • prog-amateur
    prog-amateur over 1 year

    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:

    [email protected]: 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
    
    • davidgo
      davidgo almost 5 years
      Did you change your unix password or the passpgrase on your key?
    • prog-amateur
      prog-amateur almost 5 years
      Yes I have updated my server root password with sudo passwd root
    • davidgo
      davidgo almost 5 years
      I think the password is a red herring. Most likely something you have done (maybe related to your cron job) has caused sshd to stop, or be firewalled so its unreachable.
    • prog-amateur
      prog-amateur almost 5 years
      @davidgo : thank you, so you think it's not related to the password but rather to the cronjob? This would explain why I am able to connect in SSH but it is impossible for me to transfer files. I'm thinking about a permission problem (chmod type), what do you think? Thank you. Thank you.
    • davidgo
      davidgo almost 5 years
      can you ssh as nextcloud?
    • prog-amateur
      prog-amateur almost 5 years
      Yes, I can ssh to my server as nextcloud. Only rsync through ssh (from my computer to my server) doesn't work.
  • davidgo
    davidgo almost 5 years
    That sounds right. SSH would, by default look on the users home/.ssh for private key. Any reason tjis needs to be run as root?
  • prog-amateur
    prog-amateur almost 5 years
    What you say is very logical, I should have thought about it.. I have no particular reason to use sudo privileges for this ssh file transfer. It's a reflex, yet I don't usually abuse sudo. I really appreciate the help you gave me until the end. Thank you very much @davidgo !
  • Gabriel Staples
    Gabriel Staples over 4 years
    Can anyone please confirm? CONFIRMED! Thank you, @prog-amateur! You nailed it! It too me forever to figure out what was going on here, as my ssh key was loaded in my ssh-agent via ssh-add /path/to/priv/key and I didn't know why it wasn't working.
  • Gabriel Staples
    Gabriel Staples over 4 years
    @davidgo, I need to use sudo because I am rsyncing some root files too which are readable only by root.
  • Gabriel Staples
    Gabriel Staples over 4 years
    Ex: /root is not readable by anyone but root, yet I'd like to back it up to an external drive connected to a remote server, using rsync. This puts me in a conundrum: I need to use sudo to access the /root dir, yet I need to NOT use sudo because that breaks the ssh-agent. Not sure what to do to solve this...