Using SSH key authentification on a Synology NAS for remote rsync backups

Synology DiskStations are awesome. The DSM web interface is both powerful and easy to use and is constantly improving. One thing I have struggled with, though, has been setting up public key authentification in order to allow automated scripts to push backups to the NAS via rsync. Here is how it can be done.

First, two things to keep in mind :

  • By default, root is not allowed to connect, you need to connect with another user and use sudo su (type the password of the user you are connected with, not the root password).
  • Only members of the administrators group are allowed to connect by SSH. However, even non-administrators can use the rsync service.

Public key authentification is disabled by default, you will need to enable it :

  • make sure the SSH service is enabled in Control panel > Terminal & SNMP > Enable SSH service
  • set up a user account if you don’t already have one (mine will be called foaly) and temporarily add it to the administrators group using Control panel > User > foaly > Edit > User groups)
  • log into the NAS via SSH : ssh foaly@[nas-ip] in a Linux terminal or use Putty on Windows
  • log into a root session : sudo su
  • edit the SSH service config : vim /etc/ssh/sshd_config
  • uncomment the lines PubkeyAuthentication yes and AuthorizedKeysFile .ssh/authorized_keys (make sure not to change anything else, otherwise you could lock yourself out of SSH)
  • restart the SSH service, either using synoservicectl --restart sshd or by disabling and re-enabling the SSH service in Control panel > Terminal &SNMP
  • if you added your user to the administrators group at the beginning of this procedure, you can now remove it form the group (except if this is the same user you want to add keys to, keep reading)

Now that public key authentification is enabled, you need to exchange keys for each host and user that need to be able to automatically authenticate. Let’s assume you want to allow a remote server to authenticate with the user backup :

  • add the backup user to the administrators group
  • connect to the server and generate a key pair if don’t have one already : ssh-keygen -t rsa
  • copy the public key to the NAS : ssh-copy-id backup@[nas-ip] (you will need to enter the password of the backup user)
  • this is important : connect to the NAS by SSH and check the files permissions :
    • chmod 0711 ~
    • chmod 0711 ~/.ssh
    • chmod 0600 ~/.ssh/authorized_keys
  • now, the authentification should work : from the server, try to log in to the NAS (ssh backup@nas-ip) and check that it logs in without requiring a password
  • if you only want to use rsync with this user (not SSH) you can now remove the backup user from the administrators group

In order to push data via rsync on the NAS, here are the steps to follow :

  • make sure the rsync service is enabled in Control panel > File Services > rsync > Enable rsync service (do not check Enable rsync account)
  • choose (create if necessary) the shared folder you want to push to, for example Backups
  • fire rsync with something like this : rsync -az /var/www backup@[nas-ip]:/volume1/Backups/

Here is an example of a more complex rsync command :
rsync -az -e "ssh -p 23342" --backup --backup-dir="rsync_bak_`date '+%F_%H-%M'`" --exclude 'tmp*' --exclude 'cache*' --exclude 'logs' /var/www backup@[nas-ip]:/volume1/Backups/

This will :

  • connect to the randomly-chosen port 23342 : this is useful if your NAS is an a local network behind a router/firewall/NAT, you can configure the NAT to redirect the external port 23342 to the port 22 on the NAS (this can make your configuration safer against bots looking for open SSH ports to exploit)
  • keep a copy of the previous version of each modified file in a dedicated folder with the current date, every time the backup is performed
  • exclude some useless directories from the backup

16 thoughts on “Using SSH key authentification on a Synology NAS for remote rsync backups

    1. Hi Neil, indeed that’s one of the important parts that’s easy to miss, I lost hours because of that. Glad you made it work!

  1. After doing all the above, does Security Advisor of Synology give you several warnings, such as:
    1) error with the homes folder
    2) FTR should have default UNIX permissions
    3) change the SSH port

    1. Hi Patrick,
      I don’t think these warnings have to do with the key authentication procedure. I don’t have the first two you mention, and to be honest I don’t know what they are about. The third one is self explanatory, I have too but it doesn’t matter in my case because the port is only available from my local network.

      1. I believe the first warning is because the homes checkbox is not checked in control panel
        User->Advanced->User Home==>Enable user home service for that user

  2. This is the error i have when i try to copy over the server key to the NAS:

    ~/.ssh> # ssh-copy-id rsync@
    rsync@‘s password:
    Could not chdir to home directory /var/services/homes/rsync: No such file or directory
    mkdir: cannot create directory ‘.ssh’: Permission denied
    sh: .ssh/authorized_keys: No such file or directory

      1. Can you check that this setting is enabled in your Control Panel ?
        Control Panel > User > tab Advanced > section User Home at the bottom > Enable user home service
        Then maybe disable and re-enable the SSH service, and make sure that the user you want to add keys to is in the Administrators group.

  3. Hi,

    I’ve got a slightly different setup where the Synology NAS is performing an ssh to another machine. I got everything working to the point where the ssh user@host asks for the passphrase of the public key. After entering this, the ssh connection is successfully established, however the next time I do an ssh, I’m asked again for the passphrase.

    Debugging with ssh -vvv user@host mentions the following thing and that’s where I’m stuck:
    debug3: no authentication agent, not adding key

    This appears to be the reason my passphrase is not being stored, but the Synology seems to be incapable of that since it doesn’t have an authentication agent at all?? I have a DS213+ with DSM 6.2.2-24922.

    Any clues?


    1. Hi Raymond,
      I’m not sure the “debug3” message is the cause of the problem. You mention using “ssh” but not “ssh-copy-id”, have you done that? Does your key appears in ~/.ssh/authorized_keys after that ?

      1. Hi foaly,

        The reference to ssh is when you test the connection to see if a password is asked or a passphrase. The synology does not have the command ssh-copy-id, so I copied the public key manually.

        I actually found a workaround of using no passphrase when generating the ssh key, which seems ok since it is local traffic within my house.

        Thanks though!

        1. Hi Raymond,

          I misunderstood your first message, I thought SSH server was still asking for a password even after the keys were added. In your case, it is the SSH client which asks for the passphrase in order to open your local private key, which is expected. If the connection is successful after you enter the passphrase it means your key authentication is working correctly.

          Just to make things clear for anyone reading this with a similar problem, here is a bit more explanation :
          – By default, when a client wants to connect to an ssh server with a specific username, the server asks for the password of this user before allowing the connection.
          – This can be avoided by using key authentication instead of password authentication : a key pair (public and private) is generated on the client side, and the public key is sent to the server and added to a list of authorized keys. Anyone with the corresponding private key stored locally can connect to this username on this server without needing a password anymore. This is a bit like storing the password on the client side and sending it automatically when the server asks it, but way more secure.
          – However, if the private key gets stolen on the client (stolen computer or hacked operating system for example), the thief will be able to use it to connect to the server. In order to prevent that, the private key can be encrypted locally with a passphrase (but it is not mandatory). Without knowing the passphrase, the key is worthless.
          – Now, it looks like we got back to square one : a password/passphrase is asked every time we need to connect. In order to mitigate this inconvenience, ssh provides a software called an ssh agent, which role is to keep your private key in memory once it has been decrypted. This way, you only have to enter your passphrase once per session (of the local client). Further connections later in the day will succeed automatically but if you log out or reboot your computer, the agent will ask for the passphrase again.

          In your case Raymond, using a passphrase doesn’t seem convenient because you don’t want to have to enter it for every connection (as I understand, these are automatic scripted connections of some sort, such as for backups) and I don’t see an easy way to use an agent and give the passphrase every time your NAS reboots. Storing the passphrase on the NAS to use it automatically would defeat the purpose of using a passphrase in the first place. In my opinion the best (and probably only) solution is to not use a passphrase. The connection will still be secure, even through the internet, because the key authentication scheme is strong.
          Your only risk is if someone steals your NAS and recovers the private key. In your set of constraints, this risk cannot be avoided because your NAS needs to know all the information needed to perform a connection, and there is always a way this information can get stolen.
          You can however mitigate this risk. Here are a few ideas :
          – make your NAS as secure as possible, check the file permissions of the private key, avoid opening it to the outside
          – create a dedicated user on the server with permissions restricted to only what is needed by your nas, and associate the key to this user, so that even if the key is stolen the damage won’t spread too far
          – your NAS is probably fixed and hopefully on a network with a static IP address, so you can configure the server to restrict the use of this key to your IP address


  4. Hey Foaly, yes that basically describes my situation! Thanks for the tips on the additional security steps, I will definitely look in to that!

    Thanks again,


Leave a Reply

Your email address will not be published. Required fields are marked *