Passwordless SSH on a Synology Router (SRM): Where authorized

I wanted passwordless SSH into my Synology router (SRM) the same way I have it for every other box on my LAN: generate a key, ssh-copy-id, done. Instead I got a tour of all the ways SRM is not DSM. If you just want the answer: SRM’s sshd reads public keys from /etc/ssh/keys/<username>/authorized_keys, not ~/.ssh/authorized_keys. Everything else in this post is the debugging path that leads there.

The Setup

A standard SSH config entry on the client:

Host router
  HostName 192.168.1.1
  User myuser

Then the usual:

ssh-copy-id router

Dead End #1: No Home Directory

ssh-copy-id prompts for the password, then falls over:

Could not chdir to home directory /var/services/homes/myuser: No such file or directory
sh: cd: line 1: can't cd to /var/services/homes/myuser
mkdir: can't create directory '.ssh': Permission denied

The user has no home directory, so ssh-copy-id has nowhere to put the key. On a Synology NAS (DSM) you’d fix this in Control Panel → User & Group → Advanced → Enable user home service. That toggle does not exist in SRM’s control panel. Router users just don’t get home directories.

Fine — create it by hand. SSH in with the password and:

sudo mkdir -p /var/services/homes/myuser/.ssh
echo 'ssh-ed25519 AAAA...your-public-key...' | sudo tee /var/services/homes/myuser/.ssh/authorized_keys
sudo chown -R myuser /var/services/homes/myuser
sudo chmod 755 /var/services/homes/myuser
sudo chmod 700 /var/services/homes/myuser/.ssh
sudo chmod 600 /var/services/homes/myuser/.ssh/authorized_keys

Two SRM quirks to know while you’re in there:

There is no users group. chown -R myuser:users ... (the reflexive Linux habit) fails outright. Chown the owner only.
Only users in the administrators group can SSH in and use sudo at all.

Dead End #2: The Key Is Ignored Anyway

With the home directory created, permissions strict, and the key in ~/.ssh/authorized_keys… public key auth still fails:

myuser@192.168.1.1: Permission denied (publickey,password).

This is the point where you should stop fighting permissions and read the sshd config:

grep -iE '^[^#]*(pubkey|authorizedkeys|strictmodes)' /etc/ssh/sshd_config

AuthorizedKeysFile      /etc/ssh/keys/%u/authorized_keys

There it is. SRM’s sshd is configured to look for keys in /etc/ssh/keys/<username>/authorized_keys. The ~/.ssh/authorized_keys file you carefully created is never consulted.

The Actual Fix

sudo mkdir -p /etc/ssh/keys/myuser
echo 'ssh-ed25519 AAAA...your-public-key...' | sudo tee /etc/ssh/keys/myuser/authorized_keys
sudo chown -R myuser /etc/ssh/keys/myuser
sudo chmod 700 /etc/ssh/keys/myuser
sudo chmod 600 /etc/ssh/keys/myuser/authorized_keys

No sshd restart needed — authorized_keys is read per login attempt. From the client:

ssh router 'echo ok'
ok

Summary

Symptom	Cause
`ssh-copy-id` fails with `can't cd` / `mkdir: Permission denied`	SRM users have no home directories, and there’s no DSM-style “user home service” toggle to create them
`chown myuser:users` fails	SRM has no `users` group — set the owner only
Key in `~/.ssh/authorized_keys` ignored, still password-prompted	sshd_config sets `AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys`
Passwordless login works	Key installed at `/etc/ssh/keys/<user>/authorized_keys`, dir `700`, file `600`, owned by the user

The broader lesson: when public key auth fails and the usual permission-tightening ritual doesn’t help, grep AuthorizedKeysFile /etc/ssh/sshd_config before anything else. Appliance vendors love moving that path — and Synology’s router OS and NAS OS made different choices, so experience with one actively misleads you on the other.