Modify SSH Config To Maximize Security

SSH is a powerful remote logging protocol that took the place of telnet back in the mid-to-late 90′s. With so many people using SSH as an every day tool, it is important for server administrators to understand some ways of making the secure shell a bit more… well… secure. In this article you will learn how a few simple configuration modifications to sshd_config on your SSH server can improve the security of your SSH daemon and allow you to sleep better at night…

First, lets take a look at a default SSH Config file: sshd_config:

# $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker Exp $
# This is the sshd server system-wide configuration file.
# See sshd_config(5) for more information.
# The strategy used for options in the default sshd_config
# shipped with OpenSSH is to specify options
# with their default value where possible, but leave them
# commented. Uncommented options change a default value.
#Port 22
#Protocol 2,1
#AddressFamily any
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don’t trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don’t read the user’s ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to ‘yes’ to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of “PermitRootLogin without-password”.
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to ‘no’.
#UsePAM no
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/
#MaxStartups 10
#PermitTunnel no
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# AllowTcpForwarding no
# ForceCommand cvs server

As we can see, by default most of the configuration options are commented out, meaning that SSH is taking the default values. To maximize SSH security, we are going to modify the following lines:

#Port 22

#Protocol 2,1

#PermitRootLogin yes

#PermitEmptyPasswords no

#MaxAuthTries 6


The six lines pulled out from the sshd_config are the lines that I feel are the most important and basic modifications that should be made to the configuration. Here is what they should be changed to (remember to uncomment them):

Port 60 (pick any port, 60 is just an example)

Running the SSH daemon on a port other than the default port of 22 will minimize your servers vulnerability of being scanned automatically by botnets that search and automate login and password attempts on SSH servers. Keep in mind that after you change the port number on your SSH server, you will need to specify the port whenever you are connecting to the server.

Protocol 2

The SSH protocol 1 is very outdated and nobody should be running it. Protocol 1 had some security issues, so it is pretty mindless to even allow it in your configuration.

PermitRootLogin no

Logging into your SSH server as the root user should not be necessary. The best practice is to log in as a normal user and in the event of needing root privileges you can use the su command to switch to the root user.

PermitEmptyPasswords no

You do not want to allow user accounts that have empty passwords to log into your Linux server via SSH.

MaxAuthTries 3

Setting the MaxAuthTries to a low number will minimize the risk of your SSH server being attacked in a brute force type of way. Automated attacks will disconnect after a third password failure. Though they may reconnect, it can slow the process down and will definitely minimize the potential breach by way of brute force password attempts.

AllowUsers adamk tom sam john jane mark

Setting AllowUsers in the configuration file greatly reduces the risk of automated brute force attacks. If you specify that only certain users are allowed to log into the machine via SSH then you have less to worry about in that aspect. List out all of the user names that are allowed to connect to the SSH server and separate them with spaces.


We’ve looked at six different configuration modifications that will improve our Secure Shell (SSH) server.

  1. Running SSH daemon on a different port.
  2. Allowing only users running protocol 2 to connect to the server
  3. Denying root logins over SSH
  4. Denying users with empty passwords to connect
  5. Permitting a limited number of authorization retries.
  6. Allowing only certain specified users to log in.

With these settings in place, and our SSH server restarted in order to take these configuration changes into effect, we are one step closer to a safer and more secure server.

13 thoughts on “Modify SSH Config To Maximize Security

  1. Pingback: » Modify SSH To Maximize Security

  2. Everything that is commented-out is the default, so changing:
    #PermitEmptyPasswords no
    PermitEmptyPasswords no
    is useless.

    Also, when changing the Port use something higher than 1023 to avoid conflicting with reserved ports for other services.

  3. @chort:

    You’re right in the sense that it’s useless because it is set to “no” by default, but I still decided to include it because some people may be allowing empty passwords. Just wanted to let you know that I thought about the “uselessness” prior to posting.

    Thank you for your input. :)

    Great tip on setting the port higher than 1023, I should have mentioned that.

  4. Pingback: Initial Slackware Configurations « - technical aspects for the masses

  5. It should be mentioned that changing ssh port is useful only if you can afford it, i.e. if only you and several other trusted people use the machine, security through obscurity might be fine, but setting up strong password (or key along with disabling passwords) is still much more important.
    Without it, security through obscurity will on the contrary become much more risky. One aggressive scan will tell attacker anyway and against botnets are abovementioned methods of disabling root login and reducing number of logging tries and permitted users much better.

    Last but not least – any script kiddie worth it’s h4xx0r l33tness will try some obvious ports like 2200 or 22222 while your users, if logging remotely twice in a year, may easily forgot that 13654 port and end up scanning the machine for it.

    Btw. I hope this system hides email, when it’s required, if it is so, it’s fine to mention it, so less people will submit some nonsense like I did.

  6. Pingback: Myglobalblog » Blog Archive » life is about modifying SSH

  7. Pingback: Jimmy Nord » Blog Archive » Instructions on Maximizing SSH security

  8. Pingback: SSH follow-up « Akee fruits

  9. Something I’ve been in the habit of doing is generally have some system group that people who need a shell will be in, such as wheel and admin groups depending on distro. Then, in the sshd_config use the AllowGroups option to restrict access that way. It makes things sort of self-documenting on the system side, doesn’t require updating the sshd_config for account changes, etc.

  10. Where is “AllowUsers” in sshd_config file?
    If it doesn’t have that line, should I just add one like this?

    AllowUsers admin
    #AllowUsers admin

    Which one is correct?

  11. Pingback: Virtual server has been suspended by the administrator

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>