SSH hardening on Linux Servers


While allowing ssh connections to the production servers there are few best practices which a sysadmin must know.These are explained in this article.

Openssh options are controlled through the /etc/ssh/sshd_config file. Options that uses the default values, the sshd_config file contains a commented line with the option and its default value. This makes it easier for us, as we can see the Openssh option name and the default value without having to lookup somewhere else.

For example, sshd_config file contains the following commented line. This indicates that the PubkeyAuthentication option contains “yes” as the default value.

$ grep -i pubkey /etc/ssh/sshd_config

#PubkeyAuthentication yes

If you like to change this, you should remove the comment and change the value (from yes to no)

1. Disable Root Login (PermitRootLogin)

By default you can ssh to the server as root. It is best not to allow root to login directly to the server. Instead, you should login to the system as your account and then do ‘su -’ to login as root.

If you have multiple sysadmins in your organization, and if they all login to the server directly as root, you might not know which sysadmin logged in as root. Instead, if you disable login as root, sysadmins are forced to login as their account first, before they can do ‘su -’, this makes the auditing easier.

Add the following entry to sshd_config to disable root to login to the server directly.

$ vi /etc/ssh/sshd_config

PermitRootLogin no

2. Allow Only Specific Users or Groups 

This is helpful when you have created several user accounts on the system, but want only few of them to login.By default anybody who is authenticated successfully are allowed to login

This is also helpful when you are using NIS, openLDAP  for authentication. Every user in your company might have account on NIS, OpenLDAP etc. But, on a specific server you want only few of them to login. For example, on production system you want only sysadmins to login.

Add the following entry to the sshd_config file to allow only specific users to login to the system. In the example below only ramesh, john and jason can login to this system. Usernames should be separated by space.

$ vi /etc/ssh/sshd_config

AllowUsers alex john jason

Add the following entry to the sshd_config file to allow only the users who belong to a specific group to login. In the exampe below only users who belong to sysadmin and dba group can login to the system.

$ vi /etc/ssh/sshd_config

AllowGroups sysadmin dba

3. Deny Specific Users or Groups

Instead of allowing specific users (or groups), you can also deny specific users or groups.Add the following entry to the sshd_config file to deny specific users to login to the system. In the example below cvs, apache, jane cannot login to this system. Usernames should be separated by space.

$ vi /etc/ssh/sshd_config

DenyUsers cvs apache jane

Add the following entry to the sshd_config file to deny users who belong to a specific group to login. In the exampe below users who belong to developers and qa group cannot login to the system.

$ vi /etc/ssh/sshd_config

DenyGroups developers qa

Note: You can use combination of all the Allow and Deny directivies. It is processed in this order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups

4. Change SSHD Port Number (Port)

By default ssh runs on port 22. Most of the attackers will check if a server is open on port 22, and will randomly use brute force to login to the server using several username and password combination.

If you change the port to something different, others need to know exactly what port to use to login to the server using ssh. The exampe below uses port 222 for ssh.

$ vi /etc/ssh/sshd_config

Port 222

From your logs (/var/log/secure), if you see lot of invalid logins using ssh for accounts that don’t exist on your system, from the ip-address that you don’t recognize, it migth be some brute-force attack. Those kind of ssh invalid login will stop, if you change the port number.

5. Change Login Grace Time (LoginGraceTime)

When you ssh to a server, you have 2 minutes to login. If you don’t successfully login within 2 minutes, ssh will disconnect. 2 minutes time to login successfully is too much. You should consider changing it to 30 seconds, or may be 1 minute.

Add the following entry to the sshd_config file to change the login grace time from 2 minutes to 1 minute.

$ vi /etc/ssh/sshd_config

LoginGraceTime 1m

6. Restrict the Interface (IP Address) to Login (ListenAddress)

If you have multiple interfaces on the server that are configured to different ip-address, you might not want everybody to login to the server using all those ip-address.

Let us assume that you have the following 4 interfaces on the server:

  • eth0 – 192.168.10.200
  • eth1 – 192.168.10.201
  • eth2 – 192.168.10.202
  • eth3 – 192.168.10.203

By default ssh will listen on all of the above ip-addresses. If you want users to login only using ip-address 200 and 202, do the following in your sshd_config

$ vi /etc/ssh/sshd_config

ListenAddress 192.168.10.200

ListenAddress 192.168.10.202

7. Disconnect SSH when no activity 

Once you’ve successfully logged in to the system, you might want to get disconnected when there are no activities after x number of minutes. This is basically idle timeout.

In Bash, you can achieve this using TMOUT variable.In OpenSSH, this can be achieved by combining ClientAliveCountMax and ClientAliveInterval options in sshd_config file.

  • ClientAliveCountMax – This indicates the total number of checkalive message sent by the ssh server without getting any response from the ssh client. Default is 3.
  • ClientAliveInterval – This indicates the timeout in seconds. After x number of seconds, ssh server will send a message to the client asking for response. Deafult is 0 (server will not send message to client to check.).

If you want ssh client to exit (timeout) automatically after 10 minutes (600 seconds), modify the sshd_config file and set the following two parameters as shown below.

$ vi /etc/ssh/sshd_config

ClientAliveInterval 600

ClientAliveCountMax 0

About Alex Hunt

Hi All I am Manish Kumar Jha aka Alex Hunt. I am currently working in VMware Software India Pvt Ltd as Operations System Engineer (vCloud Air Operations). I have around 5 Years of IT experience and have exposure on VMware vSphere, vCloud Director, RHEL and modern data center technologies like Cisco UCS and Cisco Nexus 1000v and NSX. If you find any post informational to you please press like and share it across social media and leave your comments if you want to discuss further on any post. Disclaimer: All the information on this website is published in good faith and for general information purpose only. I don’t make any warranties about the completeness, reliability and accuracy of this information. Any action you take upon the information you find on this blog is strictly at your own risk. The Views and opinions published on this blog are my own and not the opinions of my employer or any of the vendors of the product discussed.
This entry was posted in Linux/CentOS. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s