Securing SSH

Depending on how far and in depth you want to go, locking down SSH is one of the easiest methods to securing your server from outside attempts to gain access.  You can change the port, allow connections only from specific IP addresses, and so forth. There are many different ways to secure and harden SSH on your servers. We'll cover some simple ways and then some more complex methods.

Change SSH Port

Changing SSH ports is possibly one of the easiest things you can do to completely avoid the internet bots that scan entire subnets for TCP Port 22 connections available. By Default, SSH is hosted on port 22 and can be edited via line 13 in the sshd configuration file:

[root@centos ~]# cat /etc/ssh/sshd_config -n | grep "Port "
    13	Port 22

After changing the port and restarting SSH, you will need to ensure that you add the proper IPTables rules (usually, before you even change the port).

Disable Password Authentication

Disabling password authentication means that the user connecting does not even get prompted to enter a password. Use this in conjunction with private/public SSH authentication keys to gain instant access with no password. The only caveat here is that you better keep your private SSH key protected. If someone were to get it, any servers using it could potentially be compromised. Here is a good Oracle Document on Setting up the SSH Keys that works well on RHEL/CentOS systems as well.

Allow SSH Connections from Specific Hosts / Jumpboxing

Selection_019This is another powerful option of blocking connections. It's called using a "Jump Box". Essentially, it is a server that sits behind everything and connections over SSH or any other locked down services are only allowed to connect via the server that is the "Jump Box". A lot of companies I have worked for have used this method via a VPN server to prevent any "from-the-outside" port scans and brute force attacks or attempts to gain access. Typically this is set up simply using: hosts.allow, hosts.deny, IPTables, or if you're into that sort of thing, a hardware firewall.

The Private LAN + VPN

Needless to say, there are many, many different configuration options for what you want to do with security. How much you want to manage said security is entirely up to you. Coming from a background where security is one of the main things that I consider and think about -- well...let's just say I usually have my hands full.Selection_020Having a private LAN with a VPN Jump box is one of the best ways to go although the VPN aspect is usually one of the more difficult parts for people to set up and get configured correctly. There's a lot that can go into it.
This setup can be complex although it is straight forward. Machines are SSH accessible ONLY via the private LAN range and the only way to get into the private LAN range is via the VPN Jumpbox.

Private LAN + Jumpbox + AuthKeyForwarding

This is probably one of the best ones I have used. You have your public SSH key distributed among the servers and you use a Jumpbox in the middle to gain access on the private interfaces via SSH. Assuming you are using a bash terminal, you can SSH to the jump box and forward your private key for authentication using the following:

$ ssh -ACX user1@host1.com

This will actually forward your auth key and from here you can then SSH to other servers via the private interfaces WITHOUT storing your private SSH key on the jumpbox.
NOTE: Your hosts will need to be configured to accept SSH Key Forwarding!

Disable SSHv1

This one is pretty straight forward although you *really* don't need to worry about it. Still, it's safer just to make sure. By default for CentOS/RHEL, "Protocol 2" is already specified in the configuration of sshd. I believe it was left commented out in previous versions <6 of RHEL.

Disable root Logons

Unfortunately, this one is still defaulted to "yes". This directive allows "root" user to SSH directly to the server. By changing it to "no", a user would be denied SSH access when SSHing to the server as root, even if they got the password correct. This directive is found on line 42 of the SSHD configuration:

[root@centos ~]# cat /etc/ssh/sshd_config | grep "PermitRootLogin no" -n
42:PermitRootLogin no

Extra?

Do you have any other advice on locking down SSH that I did not list here (or maybe I don't know about it) that you would like to see? Please leave a comment. My goal is to learn something new every day.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *