Secure Your Sshd with Sshd_config Options

Just a few simple configuration options will make your sshd a lot more secure.

Just a few simple configuration options will make your sshd a lot more secure.

Linux administrators will be very familiar with ssh as it is the most important connectivity tool providing you with shell access to your Linux system.  In this article, we will secure your Sshd with Sshd_config Options.  We have written other articles in the past that mentioned using ssh for other tasks.  Some of them are listed below:

Connect to Blocked Ports with SSH Tunneling

Mount a Remote Directory with SSHFS – Coolest Linux Trick Ever!

Automate File Copy Between Machines Using Rsync Over SSH

Sshd Allow Login by Time Schedule

Backup Your Sshd_config File

Before doing anything, backup your /etc/ssh/sshd_config file as we are going to edit it:

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bkp

Disable SSH Root Login

Set this configuration option by editing the /etc/ssh/sshd_config file and finding a line that looks like this:

# PermitRootLogin yes

We will modify this line by removing the “#” and changing the “yes” to “no” so that it looks like this line:

PermitRootLogin no


Disable Ssh X11 Forwarding

Change these lines:

#X11Forwarding no
X11Forwarding yes

to look like this:

X11Forwarding no
#X11Forwarding yes

Setup Login Message Motd

This system is for authorized users only.  Activity on this system 
is monitored and logged.  Unauthorized access to this system will 
be prosecuted to the fullest extent of the law.  Permitted users performing tasks in excess of their granted privileges will be 
subjected to having all of their access revoked and face disciplinary

Change Your Sshd Port

By default, sshd will listen on tcp/22.  This also means that people trying to break into your system with a brute force attack will try port 22.  One way to avoid this is to change the port that your sshd listens on.  This is simple, just modify the “Port” option in your /etc/ssh/sshd_config file, specifying a different port.

Port 2200

After changing the port number, you need to restart your sshd service.  Before you do this, remember to work with your iptables and other firewalls to ensure that you will be able to access the new sshd port after it is reset.

Specify User Groups That Can Login with AllowGroups

Sometimes you may want to control specifically who can login directly to a machine using an ssh client.  There are several options that can be used to manage this.  One is to use the sshd_config AllowGroups option.  When using this option, I typically put it near the bottom of the /etc/ssh/sshd_config file.  Using AllowGroups allows you to specify exactly which groups of users can login using ssh clients:

Example:  In this example, I have edited my /etc/ssh/sshd_config file to allow only users included in the “systemusers” group to login.

AllowGroups systemusers

After changing the file with the AllowGroups option above, a simple restart of the sshd service puts the change in effect.

Similar to DenyGroups

AllowGroups has a very similar opposite option called DenyGroups that acts exactly opposite of the AllowGroups option.  Using DenyGroups with a group name will mean that users participating in the group mentioned will not be able to login with ssh.

Specify Users That Can Login with AllowUsers

Sshd allows you to specify exactly which users can login with ssh or even which users from which ip addresses that can login with ssh.  We do this with the AllowUsers configuration option.  The AllowUsers option is very similar to the AllowGroups option.

Example:  Below, I allow the paul user and only the paul user to login.  Because there is not an address restriction for the paul user, he can login from any IP Address.

AllowUsers paul

Remember, using the AllowUsers example above, will allow the paul user to login with ssh, but will also preclude any other users from logging in.

Example:  In this next example, we allow the paul and marry users to login from anywhere, while restricting the david and sally users to ssh connections from only specific addresses.

AllowUsers paul mary david@ sally@

This example above is good when you have automated logins using certs and crontabs like we described in this prior article:  Automate File Copy Between Machines Using Rsync Over SSH

Similar to DenyUsers

AllowUsers has a very similar opposite option called DenyUsers that acts exactly opposite of the AllowUsers option.  Using DenyUsers will mean that users mentioned will not be able to login with ssh.

Put Your New Ssh Configuration into Effect

After you have made any one of the changes above, you will obviously want to put the changes into effect.  We will make the changes effective by restarting the sshd service:

Example:  Restart the sshd service / daemon

# service sshd restart

Warning!  Don’t Logout of Your SSH Client Yet!!!

This is important!  Whenever you are changing options in your sshd configuration, there is danger that you are going to make a mistake that may lock you out.  To help mitigate this, don’t logout or disconnect from the ssh session you are using to make these configuration changes.  Instead, after restarting your sshd service, try logging in with another session to be certain that you still can.  Once you have proven that you can still connect with a new session, you can then feel comfortable logging out.

Other Sshd Configuration Options

In addition to the options we discussed above, here are some others that may be useful to you.

Sshd Option:  Banner

I configured my /etc/ssh/sshd_config file with the “Banner” option and afterwards restarted the sshd service

Banner /etc/banner

Then I created the /etc/banner file and inserted the following text into it:

|                                                               |
|            WARNING!!! THIS SYSTEM IS MONITORED!               |
|                                                               |
| Unauthorized access to this system is prohibited. If you      |
| have not been authorized for access by system administrators  |
| disconnect now. Unauthorized access can lead to prosecution   |
| and other disciplinary action.                                |

Now, when I connect with my ssh client, I see the banner:

$ ssh -l mary
|                                                               |
| WARNING!!! THIS SYSTEM IS MONITORED!                          |
|                                                               |
| Unauthorized access to this system is prohibited. If you      |
| have not been authorized for access by system administrators  |
| disconnect now. Unauthorized access can lead to prosecution   |
| and other disciplinary action.                                |
+---------------------------------------------------------------+'s password:


Sshd Option:  LoginGraceTime

The LoginGraceTime option specifies the time in seconds(default) or in other units if specified that you have to successfully login.  This can be a useful configuration option in your fight against brute force attacks.

Example:  Below we configure our sshd to only allow 1 minute for login before forcing a disconnection

LoginGraceTime 1m

Sshd Option:  MaxAuthTries

Another tool for fighting brute force login attacks is the MaxAuthTries option.  This will configure the number of authentication attempts allowed per connection.  If you set this value to 12 for example, any login failure after 6 will be logged.  The default MaxAuthTries is 6.

Example:  We set the sshd’s MaxAuthTries to 4

MaxAuthTries 4

Sshd Option:  PrintMotd

The PrintMotd option in sshd_config tells sshd whether it should echo the /etc/motd file after login.  The default is yes.  The options are yes or no.

Sshd Option:  PrintLastLog

PrintLastLog is a nice little feature that when enabled will show the timestamp of the last time a user successfully logged in after a new successful  login.

Other Resources About How to Secure Sshd with Sshd_config Options

Linux Command SSHD –

Red Hat  Documentation Securing OpenSSH

The following two tabs change content below.
Jeff has 20 years of professional IT experience, having done nearly everything in his roles of IT consultant, Systems Integrator, Systems Engineer, CNOC Engineer, Systems Administrator, Network Systems Administrator, and IT Director. If there is one thing he knows for sure, it is that there is always a simple answer to every IT problem and that downtime begins with complexity. Seasoned IT professional by day, Jeff hopes to help other IT professionals by blogging about his experiences at night on his blog: You can find Jeff on or LinkedIn at: LinkedIn or Twitter at: Twitter

Latest posts by Jeff Staten (see all)

Leave a Reply

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