DB-유

Enabling SSH on Synology and Using the Terminal Safely

· synology, ssh, security

I resisted SSH on my NAS for a long time because the web UI covers most things. Then I needed mdstat output during a slow rebuild, and a log the GUI doesn't show, and that was that. DSM 6 ships an SSH daemon that's off by default, and a few things behave differently from a normal Linux box.

Here's how I turn it on, get root, move it off port 22, and switch to keys so a password guess from the internet isn't a way in. You need DSM 6.0 or 6.1, an account in the administrators group (regular users are refused since DSM 6), and PuTTY or a normal terminal.

Turn it on

Go to Control Panel → Terminal & SNMP → Terminal. Tick "Enable SSH service". Leave the port at 22 for now; I change it once key login works. Click Apply.

Now connect with your admin account:

ssh admin@192.168.1.20

Note that you do not log in as root. DSM 6 disabled direct root login and the root account has no usable password. To get a root shell use sudo:

sudo -i

It asks for your own account password, not a root password.

What's different on DSM

A few things that trip up people used to Debian or CentOS:

  • Volumes are under /volume1, /volume2 and so on. Shared folders are directories directly under them: /volume1/homes, /volume1/docker.
  • Package files live in /var/packages/<name>/target, and package control is synopkg, not systemd:
sudo synopkg list
sudo synopkg restart Docker
  • DSM's own services are managed by synoservice:
sudo synoservice --status
sudo synoservice --restart nginx
  • There is no package manager. Do not try to install apt or yum. If you need tools like htop or git, use the SynoCommunity repository or Entware, or run them in a Docker container.
  • Files under /etc are regenerated from /etc.defaults and DSM's configuration on upgrade. Manual edits to /etc/ssh/sshd_config can be lost after a DSM update; keep a copy.

Key authentication

Generate a key on your workstation if you do not already have one:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_syno

Copy the public key to your DSM user's home. The user home service must be enabled first (Control Panel → User → Advanced → Enable user home service). Then:

ssh admin@192.168.1.20 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys" < ~/.ssh/id_rsa_syno.pub
ssh admin@192.168.1.20 "chmod 600 ~/.ssh/authorized_keys && chmod 755 ~"

The chmod 755 ~ line matters. DSM creates home directories as 777 on some setups and sshd's StrictModes refuses to read authorized_keys when the home directory is group- or world-writable.

Test it:

ssh -i ~/.ssh/id_rsa_syno admin@192.168.1.20

Password login off, new port

Only do this once key login works. I keep a second terminal open on the old session while testing, so a typo doesn't lock me out. Edit the daemon configuration as root:

sudo vi /etc/ssh/sshd_config

Set these lines:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no

Then go back to Control Panel → Terminal & SNMP → Terminal, change the port to something like 2222 and click Apply. Applying from the GUI restarts sshd and picks up your file changes as well. Do the port change from the GUI rather than the config file, because DSM's firewall rules and its own record of the SSH port follow the GUI setting.

Finally, in Control Panel → Security → Firewall, make sure a rule allows the new port only from your LAN subnet, and enable Control Panel → Security → Account → Auto Block so repeated failures get the source IP banned.

Did it work?

ssh -p 2222 -i ~/.ssh/id_rsa_syno admin@192.168.1.20 "id; uname -a"

You should be logged in without a password prompt. Try ssh -p 2222 -o PubkeyAuthentication=no admin@192.168.1.20 and confirm it is refused with "Permission denied (publickey)".

When it goes wrong

  • "Permission denied, please try again" for a user that is not an administrator: expected on DSM 6. Add the user to the administrators group or leave SSH admin-only.
  • Key login silently falls back to a password prompt: check permissions. Run ls -ld ~ ~/.ssh ~/.ssh/authorized_keys on the NAS; the home must not be group-writable.
  • After a DSM update, PasswordAuthentication is back to yes: /etc/ssh/sshd_config was regenerated. Re-apply your changes and consider keeping them in a script you run after each update.
  • Locked out entirely: go to the GUI, Control Panel → Terminal & SNMP, untick and re-tick SSH. If you also blocked yourself in the firewall, connect from a machine on the allowed subnet or use the reset button procedure, which resets network and admin settings but keeps data.

SSH on a NAS is fine by me as long as it's key-only, not on port 22 facing the internet, and behind the built-in firewall.