I like to have access to my private network at home, wherever I am, and for me the best choice is to have an ssh server available. I use it for privacy reasons, because i don’t want anyone to know what could be my email, what webs do i visit, etc. Like I explained while ago in Jump over private corporate proxy with Firefox (or git, or any SOCKS ready app) through a SSH tunnel.
As I’ve shutdown my own server to avoid the noise, power waste, gain some space, and to stop worrying about hardware or connection failures and I’ve recently purchased and advanced NAS (Synology DiskStation) I would to explain how to securely active ssh on it.
The Synology DiskStation supports both telnet and SSH, but you should never use telnet when dealing with passwords or when you don’t want to be spied, as it is completely insecure.
Everyone should instead use SSH as it is very secure and almost the standard option.
How to enable SSH and users to login
It’s easy to enable SSH on your DiskStation by going to Control Panel > Terminal & checking the box next to Enable SSH Service.
You can now log in with your root username & password. If you need to login with any other user, you need to enable user’s home and let them use login with a shell.
To enable your user’s home, go to Control Panel -> User -> User Home -> There enable the user home service.
To enable your user’s to login with a shell, you have to edit the file /etc/passwd. Here is an example with the common contents when you have 2 users, one with a enabled shell (/bin/sh) the other without:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
MyDiskStation> cat /etc/passwd root:x:0:0:root:/root:/bin/ash lp:x:4:7: lp:/var/spool/lpd:/sbin/nologin ftp:x:21:21:Anonymous FTP User:/nonexist:/sbin/nologin anonymous:x:21:21:Anonymous FTP User:/nonexist:/sbin/nologin smmsp:x:25:25:Sendmail Submission User:/var/spool/clientmqueue:/sbin/nologin postfix:x:125:125:Postfix User:/nonexist:/sbin/nologin dovecot:x:143:143:Dovecot User:/nonexist:/sbin/nologin spamfilter:x:783:1023:Spamassassin User:/var/spool/postfix:/sbin/nologin nobody:x:1023:1023:nobody:/home:/sbin/nologin admin:x:1024:100:System default user:/var/services/homes/admin:/bin/sh guest:x:1025:100:Guest:/nonexist:/bin/sh myuserwithlogin:x:1026:100::/var/services/homes/mypersonaluser:/bin/sh myuserwithoutlogin:x:1026:100::/var/services/homes/mypersonaluser:/sbin/nologin |
How to enable SSH with SSH keys
But that’s not enough. Logging in with a username and password isn’t nearly as secure as requiring SSH keys. When you use password based authentication, anyone can try to reach the port and use bruteforce to gain login credentials.
With public keys authentication, you have a private key on your computer, a public key on the SSH server (the Synology DiskStation in this case). When someone tries to log in via SSH, the server looks at the public key and asks for the corresponding private key. No private key, no login.
NOTE: I’m assuming that you have already generated SSH keys. If you haven’t, you can easily find instructions on the Web.
The needed SSH daemon’s config file to allow access via keys differs from original in :
Edit /etc/ssh/sshd_config using vi, I’ve highlighted in a shortened example the changed options to harden SSH:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
#AllowAgentForwarding yes AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #StrictModes yes MaxAuthTries 2 #MaxSessions 10 #RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes ChallengeResponseAuthentication no |
Save the file and restart the SSH daemon. The easier is to use the GUI/WEB login. Click on the Control Panel -> Terminal. Uncheck Enable SSH Service, apply, check it again, and press apply again.
Enabling your user public key in authorized_keys
Of course you have to copy to your home directory your ssh public key inside a ssh directory and file called authorized_keys. I would recommend to be careful with permissions.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
MyDiskStation> ls -la .ssh/ drwx------ 2 myuserwithlogin users 4096 Aug 8 00:12 . drwxr-xr-x 3 myuserwithlogin users 4096 Aug 19 16:56 .. -rw-r--r-- 1 myuserwithlogin users 1417 Aug 8 00:12 authorized_keys MyDiskStation> cat .ssh/authorized_keys ssh-rsa 1eK8+8yx4KYcpouNXp2C5DC1dPKtrCWPmUzuSk10fGRNmdE4XHEeoAFQzg390u4 vUOQ3fxd5D122+qA2LxBnReIW6uiP+az/KQIH0Ti7kvwFUqjjlGl9cwS/8KuwT1SBMiaW26 pQPfGQIUVcP+u1ef4OcSck33P9w79e+BZtoE6QAX3bmaJAJF680D0UJINKrsBIighmGohEK RWF/3DET9kSK0W1eriCN8aiyu1j02fuCaz5+V43jqI3bIKW0TrCoGPbRYT8JIsP3GmEIqGy fOw6qIMXmclZG65dXjN0snLxhQIx7FHXISgqZPNlmR/uEWyXc/6VXZf6lXH4qxWgfiZHlPY mI7PWk0nTAT7SzMFcWgtarIndoZVXIrWryc3eVjifNmA06lFCjHWsK0Ljo4Orh2L/B9wv33 6T6Qv2naohg1/NH67PH+nzaLt9EGPe036ZJzGM1Kc+MBX5F2JjSFUHOlHLGccst9MiEnfdyP YDATuXqdYOXJtt0LfP11U1P023e0TGOJ7OA1QwY6ODQJY+XK8zldfqeg77Z5YmztGqGRiOns dfE$== myuserwithlogin@myPC |
Try logging in now, with a username enabled to login. You won’t be prompted for a password; instead, you’ll get a nice shell see:
|
1 2 3 4 |
myuserwithlogin@jack-sparrow:~$ ssh myuserwithlogin@192.168.0.7 BusyBox v1.16.1 (2012-05-10 02:27:56 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. MyDiskStation> |
To test our hardening Try logging in now, but use a username that doesn’t exist on the server. You won’t be prompted for a password; instead, you’ll see:
|
1 |
Permission denied (publickey). |
No key, no admittance. No passwords accepted. Excellent.
Extra point. No root login, just for localhost.
An allowed ssh root login for a hacker/juanker is like honey for a bear.
So what we will do is to enable ssh public key access just for our localhost..
Edit /etc/ssh/sshd_config using vi, I’ve highlighted in a shortened example the changed options to harden SSH:
|
1 2 3 4 5 6 7 |
# Authentication: #LoginGraceTime 2m PermitRootLogin no #StrictModes yes MaxAuthTries 2 #MaxSessions 10 |
And, next, include this Match rule at the end of file, as Match rules may affect all config options below it. Using without-password we allow root login using public key.
|
1 2 3 |
Match Host 127.0.0.1 PermitRootLogin without-password |
One more step is needed, repeat point “Enabling your user public key in authorized_keys” for root user.
Save the file and restart the SSH daemon. The easier is to use the GUI/WEB login. Click on the Control Panel -> Terminal. Uncheck Enable SSH Service, apply, check it again, and press apply again.
Extra point enable root login from a shell using su. DEPRECATED
DEPRECATED
Of course we still need to have root access to Synology, anything can happen.
If along any of the steps, or whatever, you have seen this error message while trying to use ‘su’:
‘su: must be suid to work properly
What is happening is that permissions on binary /bin/busybox are “wrong”, run this as root to fix it.
|
1 |
<del>chmod u+s /bin/busybox</del> |
DEPRECATED
Restart ssh server from CLI
If you want to restart your ssh server from CLI, use this script. Running it in background guarantees that the command will be completed. Because when you launch it, your currrent ssh session will be lost/closed.
|
1 |
/usr/syno/etc.defaults/rc.d/S95sshd.sh restart & |
For some reason, this command is not fully restarting the server or not loading the modified config, so, a workaround in order to restart the ssh server is to restart the whole system.
Important
This adds a nice layer of security, but it also means that you’d better keep backups of your SSH keys, or you are hosed!
If you’ve fucked up and you can’t get a root shell or you need help because using vi is boring, try to look for a config file editor