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 0.0.0.0
#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/sshd.pid
#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

#AllowUsers

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.

Conclusion:

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.

Popularity: 8% [?]

Sponsors