Securing SSH
December 26, 2008 by: Allen SanfordOne of the wonderful things about the world wide web today is the ability to have your web servers remotely located. The problem however is accessing these remotely located machines. SSH aka secure shell is by far the best choice for Linux servers, but care must be take or your machine could be left completely open to the crackers, hackers, and script kiddies lurking around every corner. The constant attacks by the scoundrels looking for their next zombie machine can be quite cumbersome and possibly a detrimental drain on system resources. Lucky for us we can take about 20 minutes to secure or linux SSH accessibly server. I have included a sample sshd_config file for your convenience.
Change the port:
The first and probably the easiest way to dramatically reduce the number of brute force cracking attempts on your server is to change the port that SSHD listens on. By default SSHD listens on port 22 and one of the most commonly used application used to troll for servers with SSHD scans port 22 by default. It is also common knowledge that hackers or crackers will use default port with the assumption; If some took the time and trouble to change their default ssh port, they probably have other methods in place to track my actions, thus moving on to the next server that is an easier target. Plain and simple just change the port which SSH runs on to something random above port 1024.
Denying Access:
I like denyhosts but there are also other applications which will accomplish the same thing but I just prefer this one. The basic concept here is that we want to block or deny certain IPs once we determine that the user from this IP is attempting a brute force attack of the SSH port.
Installing denyhosts (Article Coming Soon)
Disallow root login
Two reasons for this are simple if you think about it. One, the root account exists on all linux machines and is one of the first accounts that any would be intruder is going to attempt to login as. Two, this is the do all end all account, in other words if this account is compromised it’s game over.
The protocol:
most modern day systems are going to be using protocol 2 only but some older distros may still be using protocol 1 or both. This should be pretty straight forward here, the developers that develop SSHD decided that protocol was needed and more secure so why not use it. Would you watch TV on a black and white unit?
Final Thoughts
Securing ssh is not hard at all and with a little care and foresight you can save your self a lot of headaches.











