Secure SSH on CentOS 6 And RHEL

CentOS 6

SSH is a very powerful tool. It puts you at the server terminal virtually and apart from pressing the power button, you can do just about anything else to the server over SSH. Unfortunately, so can a cracker, if they get access. It is very important to secure your SSH connection. Here’s a few tried and trusted hints expanded from the CentOS wiki.

1. Use A Good Password

Duh! Setting your root password to cookies is NOT a good idea. In fact if you do that, CentOS will kick out a warning that your password is, well… pathetic.

Go alpha-numeric, mix uppercase and lower and don’t base it on a dictionary word. Using something like S3cur3 is a start, but it’s still based on an English word (erm, secure).

On the server, to change the current user’s password, do the following:

To change another user’s password:

Where username is the user’s account.

2. Don’t Use Root

While I totally agree with this point, permissions errors are such a pain. I would be lying if I said I always do this, but for obvious reasons, it’s important to consider.

Remember, using the root user account over SSH allows you to do anything and everything. You have been warned. To prevent the root user login over SSH, edit the /etc/ssh/sshd_config file:

Afterwards, you will need to restart the SSH service.

3. Limit Login To Certain Users

It’s a great idea to know who exactly is allowed to login via SSH. We can specify that easily. Again, we edit the /etc/ssh/sshd_config file:

Only users in this list will be allowed to login via SSH. Again, restart the SSH service for changes to take effect.

4. Use The Latest Protocol

CentOS 6 has this enabled by default, but make sure that only Protocol 2 is being used by the service. Protocol 1 is outdated and therefore insecure. In the /etc/ssh/sshd_config file:

Save, exit and restart SSH.

As a footnote, in rare circumstances, your setup might require the use of protocol 1. Check with your hosting provider before you lock yourself out of the server!

5. Change The Default Port

This is absolutely essential, in my humble opinion. Unless we change the default port (22), every man and his dog could attempt to login. And it’s the dog I’m worried about! Remember, you’re not the only genius who knows how to type ssh root@myserver.com 😉

Choose a high port number, ideally above 1024, and don’t be tempted to go for 2222! You can check for listening ports in CentOS 6 like so:

Pick one that isn’t listed (and is not used for other vital functions) and set it in the /etc/ssh/sshd_config file:

Save, exit, restart service. Now, to login, you will need to specify the port number to access, otherwise SSH will attempt port 22 by default. We do that as follows:

But wait! I’m using Git, how will I SSH to the server now? Well, I’ve written a separate article to cover that; Git Pull & Push Using A Custom Port.

6. Use Pre-Shared Keys

Again, essential in my opinion. If you have never used public and private keys, you will LOVE this. A pre-shared key setup allows you to login without the need for a password and only allows access to those users who can display the valid key to the server. They are as close to bulletproof as it gets, but some considerations must be taken… read on.

First, you will need a public/private key pair. Beginning on the client machine (your Mac, for example), do the following:

This will create two files in your (hidden) ~/.ssh directory: id_rsa and id_rsa.pub. The first (id_rsa) is your private key and the other (id_rsa.pub) is your public key.

If you don’t want to be asked for a passphrase (which is basically a password to unlock a given public key) each time you connect, just press enter when asked for a passphrase while creating the key pair. It is up to you to decide whether or not you should add the passphrase protective encryption to your key when you create it. Warning: If you don’t passphrase-protect your key, then anyone gaining access to your local machine will automatically have SSH access to the remote server!

Also, root on the local machine has access to your keys although one assumes that if you can’t trust root (or root is compromised) then you’re in real trouble. Encrypting the key adds additional security at the expense of eliminating the need for entering a password for the ssh server only to be replaced with entering a passphrase for the use of the key. This may be further simplified by the use of the ssh_agent program.

Now set permissions on your private key:

Copy the public key (id_rsa.pub) to your server and add it to the authorized_keys list:

Once you’ve imported the public key, you should delete it from the server. Now set the file permissions on the server:

The above permissions are required if StrictModes is set to yes in /etc/ssh/sshd_config. If you use SELinux (bad, bad, bad :)), ensure the correct SELinux contexts are set:

Now when you login to the server you won’t be prompted for a password (unless you entered a passphrase when you created your key pair). SSH will first try to authenticate using your key(s). If no keys are found or authentication fails, then SSH will attempt to use conventional password authentication.

I would NOT recommend it, but once you’ve checked you can successfully login to the server using your public/private key pair, you can disable password authentication altogether by adding the following line to your /etc/ssh/sshd_config file:

Conclusion

Finally, don’t forget firewall rules. Most firewalls are setup to allow SSH traffic from any IP address. You can change this if you have a very limited access regimen, but it’s impractical for most users. Generally speaking, being responsible with login details and pre-shared keys will stand you in better stead than a ton of firewall rules.

As long as you are using a firewall and it is setup well, don’t worry too much about super-tweaking it.

Also, don’t forget the SFTP protocol. This allows FTP access to your server over an SSH connection. Useful, but dangerous from an exploitation point of view. If you do use SFTP, you will need to change the details on your FTP client accordingly (port number, for example).

Hopefully, the steps above will serve you well in maintaining a secure server as far as SSH is concerned.