A lot of administrative things on the DS can be done with the DSM. But sometimes the admin has to change something on the CLI with root rights and for that there are only two ways of access:

• telnet (Port 23)
• ssh (Port 22)

telnet is okay if one access from within a LAN network. As telnet is not encrypted and therefore user credentials (especially the ones of root) are transmitted in plaintext. So for access from outside the LAN telnet SHOULD NOT be used (telnet is okay in that cases only if an encrypted transport connection is established like for example IPSec-VPN oder OpenVPN)
So from outside the weapon of choice is SSH as this protocol only operates in encrypted mode. Furthermore SSH not only allows password authentification but as well certificate based logins. So if you use SSH not only the credentials are transmitted enrypted but as well every bit of data that is transfered between the client and the server.
The main advantage of certificate based logins is that Brute Force Attacks are - at least practically - impossible.

• Access to the DS via telnet and ssh is already activated in DSM
• Access to the shell with root rights (a tool that can be helpful is Putty)
• knowlegde in use of command line based texteditors like vi or nano

Each user that should be authenticated via a key file must have certain directories and files in his/her home. The rights for the folder and the files must be applied very restrictive. Neither the directory nor the files are allowed to have any rights other than for the owner of the ressource

$ mkdir ~/.ssh
$ chmod 0700 ~/.ssh
$ touch ~/.ssh/authorized_keys
$ chown -R YOUR_USER ~/.ssh
$ chmod 0600 ~/.ssh/authorized_keys

~/ stands for the home directory of the respective user. If you want to create the access for root then you can leave it like that. For any other user, use the full path to his/her home directory!!
After that PublicKey-Authentification has to be enabled in the config of ssh which is /etc/ssh/sshd_config. Remove the comment sign (#) in front of the following two lines

#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

To generate the key there are a lot of tools in the web. I prefer Putty (Putty KeyGen). Start Putty KeyGen an click on Generate

After the click you have to move your mouse over the blank area to generate random vectors for key generation. Today with most recent firmware key length of 4096 bit are possible

At the end you define a password for your private key (I recommend to use one, although is possible without) and click on Save private key. This is the key the client must have in order to access the server. So this file remains on the client!
On top Putty already presents the exact string to be pasted in authorized_keys. Copy and paste the string into the file of the user (take care that the entry is JUST ONE LINE, so no linebreaks are allowed)

Finally you need to bring the public key to the DS. The public key is the string that Putty presents on top. Copy the string to the clipboard and add it to the authorized_keys file of the user you want to have certificate login

As long as the access via ssh and certificates is not running or not tested, it is a very good idea to keep the telnet door open. This backup access (telnet) is very important as the ssh connection is terminated when restarting the ssh daemon. Furthermore is always possible to make a mistake which could prevent ssh from starting (for example config errors). Without telnet you would not have any shell access anymore

To test the new config you have to restart the ssh daemon in order to re-read its config file which you changed above. Login as root via telnet!! and call the startscript of the ssh daemon

$ /usr/syno/etc.defaults/rc.d/S95sshd.sh restart

After that the ssh daemon should be restared and ready for connection requests.

To test the public key the easiest way is to use Putty again. Create in Putty a connection like user@IP_OF_DS and BEFORE you click on connect you have to let Putty know the privateKey file to use. To do that look in the SSH–>Auth Menu of Putty (left side), click on browse and add the path to the private key file. If you created a password then at this moment a request for the password will appear. After that click on connect and you should be logged in without password

This is not a password request from the server. The password will never leave Putty and is only used to decrypt the private key. As well the value of the private key will never be transmitted to the server. With the private key the clients encrypts a string (which cleartext value is known to the server) and send the encrypted value to the server. If the server can decrypt the string with the public key found in authorized_keys then it knows that the client must have knowledge of the private key. So the client is authentificated.

If the auth works well, one should adjust the ssh config to only allow certificate based logins. Normal logins (username and password) will be completly blocked. Only then Brute Force is really off the table!
Add the following line in sshd_config and restart ssh daemon again.

PasswordAuthentication no

SSH and authorized_keys are very powerful. For example it's possible to call an external programm through authorized_keys. This program or command will be called everytime this user gets authentificated. This can be very helpful when trying to „tunnel“ a program through ssh. Or you can limit the commands the user can use (commands on the CLI). Or a key can only be allowed to login from certain ip address(es).

The elegance of tunneling a program with ssh can be seen with SVN (Subversion):
Only one user is needed. And this user can have very different rights based on the key used. Based on the key file used the server can determine which command to fire and with which parameters. With different keys different actions for the same user can be specified.

Furthermore one can specify in authorized_keys different ssh parameters. So it's even possible to overwrite certain values from the sshd_config (for example no-pty oder no-port-forwarding). So it would be possible to start a backup job if a certain user with a certain key loggs in

Following a config sample to start svn in tunneling mode with different settings based on the key file used:

command="/opt/bin/svnserve -t -r /volume1/svn/repos/private --tunnel-user=svn",no-port-forwarding,no-agent-forwarding,no-pty  ssh-rsa PUBLIC_KEY1_VALUE COMMENT
command="/opt/bin/svnserve -t -r /volume1/svn/repos/public --tunnel-user=svn",no-port-forwarding,no-agent-forwarding,no-pty ssh-rsa PUBLIC_KEY2_VALUE COMMENT

With each auth via ssh the daemon checks the users autorized_keys for commands to execute for this key. In the example above KEY1 is used for private access and KEY2 for public users. Parameter -t calls svn in tunnel mode and defines a chroot for the user (parameter -r). Furthermore the user for the tunnel (can be different from the user that get authentificated) is defined with –tunnel-user

The commands structure is quite easy to understand:

command="COMMAND PARAMETER[,]PARAMETER[,]PARAMETER",SSH_PARAMETER,SSH_PARAMETER,SSH_PARAMETER KEY_TYPE KEY_VALUE COMMENT