How to securely activate SSH into your Synology DiskStation with SSH Keys and no root login

I like to have access to my private network at home, wherever I am, and for me the best choice is to have an ssh server available. I use it for privacy reasons, because i don’t want anyone to know what could be my email, what webs do i visit, etc. Like I explained while ago in Jump over private corporate proxy with Firefox (or git, or any SOCKS ready app) through a SSH tunnel.

As I’ve shutdown my own server to avoid the noise, power waste, gain some space, and to stop worrying about hardware or connection failures and I’ve recently purchased and advanced NAS (Synology DiskStation) I would to explain how to securely active ssh on it.

The Synology DiskStation supports both telnet and SSH, but you should never use telnet when dealing with passwords or when you don’t want to be spied, as it is completely insecure.
Everyone should instead use SSH as it is very secure and almost the standard option.

Synology DiskStation DS211
Synology DiskStation DS211

How to enable SSH and users to login

It’s easy to enable SSH on your DiskStation by going to Control Panel > Terminal & checking the box next to Enable SSH Service.
You can now log in with your root username & password. If you need to login with any other user, you need to enable user’s home and let them use login with a shell.
To enable your user’s home, go to Control Panel -> User -> User Home -> There enable the user home service.
To enable your user’s to login with a shell, you have to edit the file /etc/passwd. Here is an example with the common contents when you have 2 users, one with a enabled shell (/bin/sh) the other without:

How to enable SSH with SSH keys

But that’s not enough. Logging in with a username and password isn’t nearly as secure as requiring SSH keys. When you use password based authentication, anyone can try to reach the port and use bruteforce to gain login credentials.
With public keys authentication, you have a private key on your computer, a public key on the SSH server (the Synology DiskStation in this case). When someone tries to log in via SSH, the server looks at the public key and asks for the corresponding private key. No private key, no login.
NOTE: I’m assuming that you have already generated SSH keys. If you haven’t, you can easily find instructions on the Web.
The needed SSH daemon’s config file to allow access via keys differs from original in :
Edit /etc/ssh/sshd_config using vi, I’ve highlighted in a shortened example the changed options to harden SSH:

Save the file and restart the SSH daemon. The easier is to use the GUI/WEB login. Click on the Control Panel -> Terminal. Uncheck Enable SSH Service, apply, check it again, and press apply again.

Enabling your user public key in authorized_keys

Of course you have to copy to your home directory your ssh public key inside a ssh directory and file called authorized_keys. I would recommend to be careful with permissions.

Try logging in now, with a username enabled to login. You won’t be prompted for a password; instead, you’ll get a nice shell see:

To test our hardening Try logging in now, but use a username that doesn’t exist on the server. You won’t be prompted for a password; instead, you’ll see:

No key, no admittance. No passwords accepted. Excellent.

Extra point. No root login, just for localhost.

An allowed ssh root login for a hacker/juanker is like honey for a bear.
So what we will do is to enable ssh public key access just for our localhost..

Edit /etc/ssh/sshd_config using vi, I’ve highlighted in a shortened example the changed options to harden SSH:

And, next, include this Match rule at the end of file, as Match rules may affect all config options below it. Using without-password we allow root login using public key.

One more step is needed, repeat point “Enabling your user public key in authorized_keys” for root user.

Save the file and restart the SSH daemon. The easier is to use the GUI/WEB login. Click on the Control Panel -> Terminal. Uncheck Enable SSH Service, apply, check it again, and press apply again.

Extra point enable root login from a shell using su. DEPRECATED

Of course we still need to have root access to Synology, anything can happen.
If along any of the steps, or whatever, you have seen this error message while trying to use ‘su’:
‘su: must be suid to work properly

What is happening is that permissions on binary /bin/busybox are “wrong”, run this as root to fix it.


Restart ssh server from CLI

If you want to restart your ssh server from CLI, use this script. Running it in background guarantees that the command will be completed. Because when you launch it, your currrent ssh session will be lost/closed.


For some reason, this command is not fully restarting the server or not loading the modified config, so, a workaround in order to restart the ssh server is to restart the whole system.


This adds a nice layer of security, but it also means that you’d better keep backups of your SSH keys, or you are hosed!
If you’ve fucked up and you can’t get a root shell or you need help because using vi is boring, try to look for a config file editor

17 thoughts on “How to securely activate SSH into your Synology DiskStation with SSH Keys and no root login”

  1. Hello, thanks for this useful guide! Anyway I can’t succeed in connecting with my “user” account. I enabled “user”’ to login with a shell in /etc/passwd but i still got the Permission denied (publickey) message. It’s working with the “admin” account and root, but not with my non-admin account. I even restarded the diskstation. Any idea?



  2. well. I got just one account, let’s call it “user”, which doesn’t allow connection. No idea why. Here i explain:
    I did exactly the same procedure for several other test accounts to figure out what could be the problem (syntax, group…?) & it always works. When i modify /etc/passwd to “nologin” for those working accounts, the connection is rejected withe the following message:
    “Permission denied, please try again.
    Connection to 192.168.*** closed.”

    But, whatever is the content of /etc/passwd for the “user” account, the connection is rejected with the usual “Permission denied (publickey).” message. I feel like this account, or the .ssh folder inside the “user” folder is not properly recognised but I don’t understand why.

    Any idea?


  3. Hello all,

    Just wanted to let everybody know that for me restarting ssh server in any normal way (from GUI or CLI) didn’t apply new configuration set in sshd_config. I had to literally kill the process from CLI and then start it again via GUI.

    This was on Synology DS410j.

  4. I changed my root password a while back and I can log in with the root password, but I cannot make changes to /etc. I always get a permission denied.

    When I run cat /etc/passwd I get this for the root user:


    I have created my ssh keys, but I cannot enable the use of keys since I cannot access /etc. Any ideas of what I might have done here at some point?



  5. NOTE. Before you disable root login or password authentication, make sure $ su root' works for you! This instruction is good, but its order is not correct. Also, if you installed coreutils, most likely you will be using coreutils-su’ (use $ which su' to check), which won't let you to su to root, even with root uid set (!) Remove the symbolic link to coreutils-su, and then you will most likely be using busybox’ (at least this is what you should eventually be able to do by running `$ su ‘) which with uid set will allow you to su to root. Only then can you disable password authentication and root login, otherwise, you won’t be able to get through.

    1. This happened to me. I made the change to sshd_config so that it disallowed passwords before setting a public key for the root login, and as a result lost ssh access to root. If I try $su I get the error:
      su: must be suid to work properly
      Fortunately I was still able to log into DSM as an admin, enable Telnet, and then login as root via Telnet and revert the sshd_config file.

  6. This is a really nice guide, thanks! I tend to agree with Alaksiej that the warning to make sure that “su” is working should come before the instructions for disabling root. I think this is worth fixing, but again, nice guide!

  7. Actually it is not a very good idea from a security perspective to make busybox run as root.
    The +s sets the setuid bit on the busybox binary, this will run the binary always as the owner of the application, in this case root.
    Busybox is/can be used for virtually all actions and commands. Therefore you will run a number of services within the NAS as root (for which I don’t know if they already run as root) and all users which have/get access to the NAS will be able to run all commands as root.

    1. Sorry, clicked a bit too quickly on submit :-S

      Unfortunately I don’t have a good solution to fix this, so therefore the way I did it is to enable the root user, but use an SSH key to log-in and disallow passwords on SSH.

      The other suggestions are very good, I have implemented all of them. Especially the SSH keys is a good idea which I hadn’t though about before (D’OH!).

      Thanks for the post!

      1. My thoughts exactly. I don’t think the author understands the implications of setting suid on /bin/busybox

        Here are 2 solutions:
        1) Edit /etc/ssh/sshd_config. At the end of the file add:
        Match Host
        PermitRootLogin yes
        Then, to gain root priveleges, instead of using “su”, we use “ssh root@localhost”

        2) Copy /bin/su to another location on your PATH. If you check your PATH variable (echo $PATH), it has to be a location that is checked before /bin. Then on your copy of su, run:
        chmod u+s su


  8. This is great two things I would add
    1) Synology has a very power security feature that allows you to either permanently or temporarily disable a user that has xx failed login attempts in y minutes. This is vital if you allow ssh connections over the internet. This is set via Synology Control Panel … … Security …. Auto Block

    2) By default Synology has logging disable for ssh logins, you should enable that so it will show who has logged in both:
    a) Synology GUI via Log Center … Overview and Log Center .. Log Search … Connections
    b) via log files under on Synology at:

    and via Synlogy … Log Center GUI
    To enable ssh and sftp logging, login as root via ssh and edit
    uncomment these two lines:
    #SyslogFacility AUTH
    #LogLevel INFO

    So the lines will appear as:
    SyslogFacility AUTH
    LogLevel INFO

    Now restart your sshd service as described above or reboot your synology for it to take affect

    Also if you allow ssh or sftp (or any connection for that matter) from the internet you must ensure the passwords used are very strong and not hackable via brute force dictionary attach

  9. Thanks a lot for your post. I am able to log in as ‘root’ using keys.
    But I am not able to do it as ‘admin’. I have the error message: “Permission denied (publickey).”

    My question is: I can’t see anything in the log files. Even with “LogLevel VERBOSE”.

    Any ideas? Thanks !

Leave a Reply

Your email address will not be published.