Synology-specific and user-specific SSH key requirements

Earlier, I figured out how to set up SSH keys for SSH authentication in to a Synology server, and eliminate the use of a password for authentication.

These were steps towards securing the Synology, but what I really wanted to accomplish was being able to disable the “root” account to really put the server on lockdown. Although the process is technically very easy (just edit the /etc/ssh/sshd_config file and change “PermitRootLogin” to “yes”), I still needed to verify that I could SSH in to the Synology with another user account. Having SSH’d in to the Synology in the past, I had learned that the only other user account (besides “root”) that has SSH permissions by default is the “admin” account.

So, knowing that I had already established private and public keys on my computer AND had connected to the Synology from my computer using said keys, I tried to SSH with the admin account. What happened? Got this message: “Permission denied (publickey).”

That’s both good and bad.

Good that the Synology is definitely not using password authentication any more.
Bad that I can only login using the “root” account.

So, how to resolve this? Since I had been under the impression that the server just needed a single public key that corresponded to a single private key, I was a bit stumped. I had assumed that the public key provided to the Synology would apply to all existing user accounts. After a fair amount of searching (and I think perusing the Synology forums), I stumbled across the reason for this.

It turns out that each individual user has their own location on the Synology to store authorized public keys! After discovering that, it was fairly straightforward to add my existing public key on my computer to the appropriate user’s (in this case, “admin”) SSH authorized keys file. I used the following command to accomplish this:

$cat /path/to/ssh_public_key/ | ssh root@synologyaddress 'cat >> /volume1/homes/SynologyUserName/.ssh/authorized_keys'

The brief explanation of the command:
First we used “cat”, which normally prints the text of your intended file (in this case, the to the screen. But, instead of printing the info to the screen we “piped” that info (that’s the “|” character) to our SSH connection. The info of the “” file gets sent to server over our SSH connection and then we tell the server to use “cat” to append (that’s the purpose of the “>>“) that information to the authorized keys file for the specific user.

After doing that, I can now connect using the “admin” user account. That means I can now disable the “root” user login capabilities.

Leave a Comment