Public-key authentication in SSH is not only a recommended authentication mechanism for automated access, it can also add an additional security factor to a standard username/password authentication method. Once public-key authentication is in place and operational, password authentication can also be disabled completely. This results into more security and more usability due to a passwordless mechanism. A key based authentication can provide an enormous cryptographic strength which cannot be achieved by high complex or ultra-long passwords.
Key-Pair Generation
To implement a key based authentication you need to generate a SSH key-pair using tools like ssh-keygen or similar keygen tools:
ssh-keygen -t rsa -b 4096The type/algorithm RSA is currently being used as de-facto industry standard, but might be replaced by the relatively young ECDSA algorithm in the future.
Be sure to use a key size of 4096 bits as lower key sizes might not work in Synology environments. The ssh-keygen manual page points out that the current default value is considered to be 3072 bits. The NIST (National Institute of Standards and Technology) gives recommendations for general key management and particular a guidance for cryptographic algorithm and key-size selection (p.51).
During the generation process you should protect your private key by defining a passphrase. ssh-keygen generates two files:
- id_rsa (Private Key File, protected by passphrase)
- id_rsa.pub (Public Key File)
If you use other keygen tools, be sure to export the key as OpenSSH format rather than the Standard SSH2 format:
OpenSSH Output:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDCV...Standard SSH2 Output:
---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAADAQABAAACAQDCV... SSH Server Configuration
First of all you need to Enable the SSH service via DSM in the Control Panel → Terminal & SNMP. Assign a port of your choice – any other than the well-known default port 22 minimizes the risk of being brute-force attacked.
Afterwards, continue to edit the OpenSSH daemon configuration file for further custom settings. As the key-pair is generated, the config file needs to be adopted to allow key based authentication:
sudo nano /etc/ssh/sshd_configScroll down to PubkeyAuthentication and remove the # comment indicator. This enables public key authentication:
PubkeyAuthentication yesRemove the # comment at the AuthorizedKeysFile to specify the location of the key file. %h adds the location of the users home directory:
AuthorizedKeysFile %h/.ssh/authorized_keysThere is no need to enable RSAAuthentication as this option is deprecated.
Reload the SSH daemon/service to apply the changes:
sudo systemctl reload sshdAfter enabling public key authentication, the public key (NOT the private key!) has to be registered as an authorized key on the SSH server. Copy the generated id_rsa.pub content to a file called authorized_keys:
sudo cat id_rsa.pub >> authorized_keysIn some cases it might be necessary to use UTF-8 encoding for the authorized_keys file, as SSH can be quite picky if the file is not encoded properly.
Create a new .ssh directory in your users home directory and copy the authorized_keys file to it. The SSH daemon/service automatically checks this directory for either an authorized_keys or authorized_keys2 file.
sudo mkdir ~/.shh
sudo cp authorized_keys ~/.shhSave a copy of your key-pair (id_rsa & id_rsa.pub) ideally within a key management tool and remove the files from the system.
SSH requires proper permissions for the users home directory, the .ssh directory and the authorized_keys file. Double-check these settings accordingly to align with the requirements:
sudo chmod 700 ~/.shh
sudo chmod 600 ~/.ssh/authorized_keys
sudo chmod -R 755 ~Now that all of the basic requirements are in place, you can use your favourite SSH client to connect to the SSH server using public-key encryption. The passwordAuthentication option is still active by default in sshd_config which means if key based authentication fails, you still get prompted with a username/password challenge. This option can also be disabled completely (passwordAuthentication no) to increase security even more.
Troubleshooting
You can do some advanced troubleshooting in starting another SSH daemon on a different port. Keep one default session active and login separately by using the “new” port. Once your connection is going to be established you’ll get real-time debug logs which can be used for further analysis:
sudo /bin/sshd -d -p 2222Last but not least if you`re locked out, frustrated, lost or completely clueless you can still enable Telnet temporarily to get to your system respectively your SSH config files. 🙂