Article By Stanton Levens
Let face it, the Secure Shell (SSH) daemon running on your VPS is the most sensitive service open to attack on your system. Any hacker worth their salt will first try to gain access to your VPS via SSH and 99.9% of all VPS connected to the internet run this service by default and on their public IP.
If somebody gains access to your VPS via the SSH service, you can kiss your data and entire VPS goodbye. This is the ultimate goal for any would-be hacker and as such, needs to be the first thing you secure as a VPS administrator.
In this article I’m going to show you how to take three simple precautions with the SSH service that will stop most hackers and script kiddies in their tracks. So what will you learn?
- How and why to change the port SSH listens on
- How to disable password based access to SSH and only allow key based access
- Monitor failed SSH login attempts and automatically block the originating IP using an Intrusion Detection System
Using the three steps outlined above you can greatly improve the security of any publicly available SSH service running on a VPS and with no additional financial cost to yourself, so let’s gets started.
Changing the SSH Listening Port
This is the easiest of the three precautions to implement, but it really does reduce the number of unauthorised login attempts to your VPS via the SSH service. The default SSH port is 22 and every security scan made against a VPS will make sure to check if this port is open. So let’s close it by moving the port well out of the way.
- Login to your VPS with root privileges
- Edit the following file /etc/ssh/sshd_config (e.g. vi /etc/ssh/sshd_config)
- Change the Port entry from 22 to something between 1025 and 65535 making sure you aren’t already using the port for something else (run netstat -nap to check)
- Save the changes
- Restart the SSH service (normally /etc/init.d/sshd restart)
In addition, changing the default port also makes it easy for you to catch unauthorised people trying to gain access the SSH service when used in conjunction with the Intrusion Detection System detailed later on in this article, so changing the SSH port really is a win, win situation.
Configuring Key Based Access
This is one of the best ways to secure the SSH service. When configured it will prevent users accessing your UK VPS via password based authentication and instead require each user to authenticate by first presenting a key and then entering the corresponding password for the key. This makes the authentication process much more secure, because in order to login, you now need the key and the password, thus we now have a two step authentication process.
First we need to generate a local key pair on a client system running OpenSSH. In this example, we’ll use a Linux computer. Enter you login password when asked for the passphrase. You will need to enter this when connecting to the VPS:
~# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 44:4c:ef:20:94:15:54:c2:6f:ca:ab:21:34:43:3d:42 |
The public / private key files have now been created in the ~/.ssh/ directory of the user you are currently logged in as. We now need to copy the public key to the VPS’s authorized_keys file. Copy the contents of the ~/.ssh/id_rsa.pub file and paste them into the /root/.ssh/authorized_keys file on the VPS (create the file if it does not exist).
Next we must configure the SSH service on the VPS to only allow key based access. Edit the /etc/ssh/sshd_config file and set the PasswordAuthentication parameter to no. To make the changes active you must now restart the SSH service (normally /etc/init.d/sshd restart). Until you have confirmed you can connect to the SSH service using your key and passphrase, you should keep your existing SSH console window open to the server.
To access the server you can now login over SSH from the client you created the SSH public / private key pair on and enter the passphrase when requested. If you are using a different computer than the one you created the key pair on you must copy the Private key to the computer. If using Linux you should copy the key to the ~/.ssh/ directory. If using another SSH client you should follow the instructions provided by the vendor.
Monitoring and Blocking Failed Logins with IDS
The easiest way I’ve found to monitor and block failed user logins is to install CSF. This is an excellent, free Intrusion Detection System and iptables based firewall application that will run on most VPS systems. Simply download the script from http://configserver.com/cp/csf.html and follow the installation instructions for your Linux distribution.
After you have installed CSF, make sure you remove port 22 from your incoming TCP_PORT option and ensure that your newly chosen SSH port is added to the list by editing the /etc/csf/csf.config file and restarting the CSF service (/etc/init.d/csf restart).
When you are happy with the CSF configuration you will want to make sure you turn off the testing feature by setting TESTING = 0 in the /etc/csf/csf.config and again restarting the CSF service (/etc/init.d/csf restart). If you don’t turn off testing, the firewall will clear after 5 minutes and allow everything through!
By default, CSF will now monitor your server authentication logs and ban IPs with too many failed login attempts. In addition, it will also ban IP’s that come banging on port 22 too often.
Article Source: http://EzineArticles.com/7843664
Popular Posts:
- None Found
Don’t forget using hosts.allow. While IPs can be spoofed, it’s another barrier to entry and a very good one.
I think an important added security is to disallow root login to ssh, and preferably to only allow access to 1 special user with a complicated name. This way the attacker has to guess the correct username as well. Just saying.
I have a nit to pick:
The passphrase you set on SSH keys is used to encrypt your key with. This makes it hard for people that have physical access to your key (admins on your system, etc.) to use the key to impersonate you. So for that reason you should have a passphrase set.
It has no influence on the security of the login to other machines though. That only involves the key. Having a passphrase will not make it harder to brute-force the key (which is close to impossible;-), and it is not part of the authentication itself. So this is no two factor authentication: The only factor is the key, the passphrase is just required to retrieve that key.