Secure Shell is nearly always put in place as a secure replacement for telnet. It’s default behavior for any administrator. But the problem is, out of the box, Secure Shell isn’t as secure as it can be. There are plenty of ways to take this security measure to much higher levels, but which are the quickest to implement that will gain you the most security? Let’s dig in and find out.
SSH key authentication
No matter how you slice it, if you’re using a password to log in, that password can be cracked. That is a security hole in the waiting. You can get around this by using SSH key authentication. To do this you simply need to generate a key and then copy the key to the correct machines. Here are the steps for this (NOTE: These steps will be illustrated on an Ubuntu client and server):
On the local machine
Open up a terminal window and issue the command ssh-keygen -t dsa. That command will generate a public key that is then copied to your server with the command ssh-copy-id -i ~/.ssh/id_dsa.pub username@destination where username is the actual user name on the remote machine and destination is the actual address of the remote machine.
Now, when you attempt to log in to the remote machine you will be asked for the passphrase of the CERTIFICATE and not the user.
If you are using the graphic desktop you could also click on System | Preferences | Passwords and Encryptions Keys. From this GUI (see Figure A) select the My Personal Keys tab, click File | New | Secure Shell Key, and walk through the creation wizard.
Figure A
From this tool you can manage all of your passwords and your personal keys.
Once the key is created, right-click the key and select Configure Key for Secure Shell. From the new window you will need to add a computer name (the remote machine) and a login name. NOTE: You must already have the login name on the remote machine.
If you are using Windows to log into the SSH-enabled server, you can use the PuTTYgen utility. Download PuTTYgen, start it up, click the Generate button, move your mouse around (during the creation phase), save the public key, and copy the public key to the SSH server.
NOTE: As a precaution you should always enforce password-protected keys. If you allow the key authentication method, you might find some users create password-less keys (for ease of use). This is not safe.
Block root access
This one is critical and should be done on ALL machines that allow secure shell access. Open up the file /etc/ssh/sshd_config and look for the line:
PermitRootLogin
Make sure the above line is set to no. The correct line should read:
PermitRootLogin no
Once you have the file corrected and saved, issue the command:
sudo /etc/init.d/ssh restart
If you attempt to log on to the server using ssh as the root user you will be denied access.
Change the port number
I understand that security by obfuscation is not really security. But in the case of secure shell, the more the merrier. So I am a big advocate of changing secure shell from the default port 22 to a non-standard port. To do this, open up the /etc/ssh/sshd_config file and look for the line (near the top):
Port 22
Change this port number to reflect a non-standard port not in use. You will need to make sure all users that connect to this machine are made aware of this change in port number. You will also want to restart the SSH daemon after you make the change.
To connect to a non-standard port from the command line, you would use SSH like so:
ssh -p PORT_NUMBER -v -l USERNAME IPADDRESS
Where PORT_NUMBER is the non-standard port, USERNAME is the username to connect with, and IPADDRESS is the address of the remote machine.
Final thoughts
Out of the box, secure shell is a fairly secure means to connect to a remote machine. But when you can easily take the default a few steps further into the realm of very secure…the little time you will spend doing so will pay off. As a best practice standard, you should always, at a bare minimum, disable root login…everything beyond that is just icing on the proverbial cake.
