Synology SSH Key Authentication and Hardening on DSM 7

SSH on a Synology NAS is one of those features you switch on "just for a minute" to fix something, and then it stays on for years with a password login and the default port. That's a bad combination on a box that holds your backups, photos and business files. This guide sets up proper key-based SSH on DSM 7, explains the permission problem that trips almost everyone up, and then locks password logins out once keys are proven to work.

My own sites run on a Synology, so this is a box I look after every day. If you want the general Linux version of this topic (fail2ban, port knocking, sshd_config in depth), read Hardening Your SSH Server: Beyond Password Authentication as well. This post covers what is different on DSM.

What's different about SSH on DSM 7

DSM is Linux underneath, but a few Synology-specific rules apply:

• Only members of the administrators group can log in over SSH. A normal DSM user is rejected even with the right password. That's good for security, but it means every SSH account is effectively a sudo-capable account.
• Your home folder only exists if the user home service is on. Without it there's nowhere to put ~/.ssh/authorized_keys.
• DSM manages /etc/ssh/sshd_config. Changes made in Control Panel (like the SSH port) rewrite parts of it, and DSM updates can reset your edits. Always re-check after an update.
• Home folders often have the wrong permissions for OpenSSH. Synology ACLs can make your home directory group-writable, and OpenSSH silently refuses key authentication when that happens.

Step 1: Enable SSH and the user home service

1. Open Control Panel > Terminal & SNMP and tick Enable SSH service. Changing the port from 22 to something like 2222 doesn't add real security, but it does cut down log noise from scanners.
2. Open Control Panel > User & Group > Advanced and tick Enable user home service.
3. Create a dedicated admin account for yourself rather than using the built-in admin account, and disable the built-in one if it's still enabled.

Test a password login from your computer first, so you know the basics work:

ssh -p 2222 youruser@192.168.1.50

Step 2: Create a key pair on your computer

On macOS, Linux or Windows (PowerShell has OpenSSH built in), generate an Ed25519 key. Use a passphrase; your SSH agent or the macOS keychain will remember it so you don't type it every time.

ssh-keygen -t ed25519 -a 100 -C "laptop-to-nas"

This creates ~/.ssh/id_ed25519 (private, never copy it anywhere) and ~/.ssh/id_ed25519.pub (public, safe to share).

Step 3: Install the public key on the NAS

If ssh-copy-id is available on your computer, it's the easiest way:

ssh-copy-id -p 2222 -i ~/.ssh/id_ed25519.pub youruser@192.168.1.50

Otherwise, do it by hand. Synology has SFTP turned off unless you enable it in File Services, so piping over SSH is the reliable method:

cat ~/.ssh/id_ed25519.pub | ssh -p 2222 youruser@192.168.1.50 \
  'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

Step 4: Fix the permissions (the step everyone misses)

This is where most Synology key setups fail. You copy the key, try to log in, and SSH still asks for a password with no error message. The cause is almost always permissions: OpenSSH's StrictModes check refuses keys if your home directory, ~/.ssh or authorized_keys can be written by anyone other than you.

Log in with your password and run:

chmod 755 ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

You want to see drwxr-xr-x on the home folder, drwx------ on .ssh and -rw------- on authorized_keys, all owned by your user. If File Station or a Windows share later re-applies ACLs to homes, the problem can come back, so this is the first thing to check if key login suddenly stops working.

Now test from a new terminal, leaving your existing session open:

ssh -p 2222 -i ~/.ssh/id_ed25519 youruser@192.168.1.50

If it logs in without asking for your DSM password (only your key passphrase, if any), keys are working. Add -v to see exactly which key is offered and why it's accepted or refused.

Step 5: Make it convenient with ~/.ssh/config

On your computer, add a host entry so you never type the port or IP again:

Host nas
    HostName 192.168.1.50
    Port 2222
    User youruser
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Now ssh nas is all you need, and tools like rsync, scp and VS Code Remote pick it up automatically.

Step 6: Turn off password logins (carefully)

Only do this after key login works from every device you need. Keep one session open the whole time so you can undo a mistake.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-$(date +%F)
sudo vi /etc/ssh/sshd_config

Set or add these lines (remove any duplicate or commented versions so there's no ambiguity):

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no

DSM 7 ships the older name, ChallengeResponseAuthentication (DSM 7.4.1 already sets it to no). If your file uses the newer KbdInteractiveAuthentication instead, set that one to no. Then check the syntax and restart the SSH service:

sudo /usr/bin/sshd -t && echo "config OK"
sudo /usr/syno/bin/synosystemctl restart sshd.service

From a second terminal, confirm that a password-only login is now refused:

ssh -p 2222 -o PubkeyAuthentication=no youruser@192.168.1.50
# expected: Permission denied (publickey)

If anything goes wrong, you still have the open session: copy the .bak file back and restart the service. If you do lock yourself out completely, DSM's web interface still works: create a one-off task in Control Panel > Task Scheduler that runs as root, copies the .bak file back over sshd_config and runs synosystemctl restart sshd.service.

After every DSM update, run sudo grep -E '^(PasswordAuthentication|PermitRootLogin)' /etc/ssh/sshd_config to confirm your settings survived.

Step 7: Keep SSH off the public internet

Keys stop password guessing, but the best protection is not exposing SSH at all:

• Don't port-forward SSH on your router. Reach the NAS over a VPN instead. My WireGuard VPN guide covers running it on a Linux box or router, and I compare the options in Tailscale vs WireGuard for remote access to a home NAS.
• Use the DSM firewall. In Control Panel > Security > Firewall, allow the SSH port only from your LAN subnet (and your VPN subnet), then deny everything else for that port.
• Turn on Auto Block. Control Panel > Security > Protection blocks an IP after a set number of failed logins. It covers SSH as well as DSM's web login.
• Enable 2-step verification for DSM logins. It doesn't apply to SSH keys, but it protects the web interface, which is just as powerful.

Troubleshooting checklist

• Still asks for a password: permissions (Step 4) or the key isn't in ~/.ssh/authorized_keys of the user you're logging in as. Run ssh -v and look for "Offering public key" followed by "Authentications that can continue".
• "Permission denied" immediately for a working user: the account isn't in the administrators group.
• Worked yesterday, broken today: a DSM update or an ACL change reset permissions or sshd_config. Re-run Steps 4 and 6.
• Connection refused: SSH is disabled in Control Panel, the port changed, or the firewall is blocking your source IP.

Wrapping up

Key-only SSH on a Synology takes about ten minutes, and the only real gotcha is home-folder permissions. Once it's done, add the firewall rule, keep SSH behind a VPN, and check the config after each DSM update. If you're running containers on the same box, my guide to Docker in production is the natural next step.