More on SSH and potential exploits

The Linux Gazette has an article about The Potential for an SSH Worm. A brief and interesting read if you’re managing servers remotely (and I sincerely hope you’re using SSH to do that).

I’ve played a lot with SSH and though haven’t experienced a single compromise through it, I still don’t trust the default settings much. The first thing I do after setting up a server is disable direct root login through SSH (by setting “PermitRootLogin” to “no” in sshd_config). It creates an extra layer of security and makes accountability easier (may be worth mentioning that Bash 3 has a history timestamp feature which further eases this).

Next, I change the default port (tcp 22) that the SSH daemon runs on. Though some people might not agree with this, it would deter such things as worms and automated breakin attempts. Other things you can do to increase security include using the “AllowUsers” option to limit the accounts that can login and from which IPs/networks. Here is an example:

AllowUsers sajjad eggs@ eggs@172.17.*.* spam@

This example allows user “sajjad” to connect from anywhere. User “eggs” can connect only from the IP and the subnet. User “spam” can only connect from the IP address All other users will not be able to login, even with the correct password/key.

Another useful thing is to disable password logins altogether and stick to using SSH keys which makes brute-force password attacks useless. I used to do this by just creating a user, copying the key of the allowed user to “~/.ssh/authorized_keys2″ and not setting its password. However, newer (and maybe very old) SSH versions treat an account as locked if the shadow password file contains the default ‘!’ or ‘!!’ for the password field. Replacing these with ‘*’ should allow you to login through SSH without allowing any password authentication (local or remote).

Lastly, you can use iptables (or an external firewall) to restrict access to allowed IP addresses or networks. This would prevent attackers coming in from other IPs from accessing the running SSH daemon and exploiting a newly discovered vulnerability. Combine all these together and you have a virtually unbreakable server.

Note: The above have settings have been tested on OpenSSH (upto version 3.9p1) and may not be available on other versions.