7 Default OpenSSH Security Options You Should Change in /etc/ssh/sshd_config

by Ramesh Natarajan on May 23, 2011

OpenSSH options are controlled through the /etc/ssh/sshd_config file. This article explains the 7 default options in sshd_config file that you should change.

In sshd_config, the lines that start with # are comments. For those 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) as shown below.

$ vi /etc/ssh/sshd_config
PubkeyAuthentication no

I showed the above only as an example. You don’t need to change the default value of PubkeyAuthentication option, as allowing public key authentication is good.

You don’t need to modify any of the default values in the sshd_config file except the 7 options mentioned in this article.

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 (AllowUsers AllowGroups)

By default anybody who is authenticated successfully are allowed to login. Instead you can restrict which users (or groups) you allow to login to the system.

This is helpful when you have created several user accounts on the system, but want only few of them to login.

This is also helpful when you are using NIS, openLDAP (or some other external system) 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 ramesh 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 (DenyUsers DenyGroups)

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.

Please note that this causes little inconvenience to your team who login to the system, as they need to know both the ip-address and 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 (ClientAliveInterval)

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

Linux Sysadmin Course Linux provides several powerful administrative tools and utilities which will help you to manage your systems effectively. If you don’t know what these tools are and how to use them, you could be spending lot of time trying to perform even the basic administrative tasks. The focus of this course is to help you understand system administration tools, which will help you to become an effective Linux system administrator.
Get the Linux Sysadmin Course Now!

If you enjoyed this article, you might also like..

  1. 50 Linux Sysadmin Tutorials
  2. 50 Most Frequently Used Linux Commands (With Examples)
  3. Top 25 Best Linux Performance Monitoring and Debugging Tools
  4. Mommy, I found it! – 15 Practical Linux Find Command Examples
  5. Linux 101 Hacks 2nd Edition eBook Linux 101 Hacks Book

Bash 101 Hacks Book Sed and Awk 101 Hacks Book Nagios Core 3 Book Vim 101 Hacks Book

{ 16 comments… read them below or add one }

1 rohan May 23, 2011 at 3:53 am

Great article Ramesh .

2 alexis May 23, 2011 at 5:54 am

Excelente post

3 Gaurav May 23, 2011 at 6:24 am

Hello,
Ramesh gr8 Artical.
I am learning much more things form your article .

4 Andrew May 23, 2011 at 12:01 pm

Running DenyHosts is also a good security measure to avoid brute force break-ins.

http://en.wikipedia.org/wiki/DenyHosts

5 Jeff May 23, 2011 at 1:19 pm

couple of things,

for the PermitRootLogin, for people in an enterprise environment who use distributed management tools like xCAT or pdsh or some other distributed shell to accomplish one task across hundreds of hosts, you can also set “PermitRootLogin without-password” — this will only allow key based authentication to succeed with root login and thus allow you to control from where root logins are allowed.. aka a central management server… assuming you manage your keys.

also, i gotta say.. changing the sshd port isn’t going to get you very far.. security through obscurity doesn’t work all that well because any attacker can simply port scan to find the new ssh port.. your best bet is to keep ssh up to date and utilize tcpwrappers etc if you can’t rely on an external firewall to block unwanted traffic.

6 kraut June 2, 2011 at 2:42 am

Denying direct root login in an organisation with multiple sysadmins has another advantage: you can withdraw access by deleting the respective user accounts without the need to change the root password.

7 junyi June 7, 2011 at 1:12 am

when I typed this:
sudo update-alternatives –install /usr/bin/editor vi /usr/bin/vim 100
update-alternatives: error: /usr/bin/editor editor
it says error, why?
acquire the answer
Thank you!

8 Ken Caudle June 16, 2011 at 11:14 am

What version of OpenSSH are you referring to in this article? Or, better yet, in what version did the AllowUser option become available.

I have several servers using very old versions, and I do not see the AllowUser etc options in my sshd_config files.

Ken C

9 Md. Abdul Ghani July 14, 2011 at 8:55 pm

As a normal user we cannot edit the /etc/ssh/sshd_config file. I think it is a typing error. ($ vi /etc/ssh/sshd_config). We should be a root to edit this file # vi /etc/ssh/sshd_config.

10 fred July 19, 2011 at 2:14 pm

Nice post, but far from complete to me…
I think that in terms of security, some directives are missing such as “Protocol 2
, UsePrivilegeSeparation yes, X11Forwarding no, AllowTcpForwarding no, StrictModes yes, PermitTunnel no, …”.
For PermitRootLogin directive maybe you should add ‘without-password’ or ‘forced-command-only’.
Fred

11 dilip May 21, 2012 at 5:34 am

EXCELLENT STUFF

12 Rahuman August 20, 2012 at 3:21 am

Perfect & Simple the way you present the details…We are expect more and more from u like this…

13 ashutoshh August 23, 2012 at 2:30 am

great post

14 Some guy March 7, 2013 at 12:06 pm

Yes I agree that “UsePrivilegeSeparation sandbox” should also be mentioned because it means that the initial preauthentication will have in an unprivileged child process.

15 Horacio March 12, 2014 at 1:27 pm

I think ClientAliveInterval is not to disconnect idle clients. ClientAliveInterval is to terminate the session if the client is inaccesible (connection lost). If you leave a terminal open, and don’t do anything, configuring ClientAliveInterval/ClientAliveCountMax won’t close the session.

16 Horacio March 12, 2014 at 1:39 pm

I was wrong! What I have said is when you use ClientAliveCountMax != 0. Sory!

Leave a Comment

Previous post:

Next post: