Securing SSH

In the Linux world, SSH is the network protocol used for secure communication between machines. Through it, both remote access and individual commands can be sent. As a result, it is one of the most important parts of the infrastructure to secure.

For SSH, there are two system-wide configuration files. The first is in /etc/ssh/sshd_config, and handles the server, or incoming connections. The second is located at /etc/ssh/ssh_config and manages clients, or outgoing connections. Each of the following configuration settings are important to helping improve the security of a ssh server. This will be done by running the following command:

sudo vim /etc/ssh/sshd_config

First, we want to be sure we are only using version 2 of the ssh protocol. Version 1 has numerous known security problems and should be not used anywhere without very specific backwards compatibility needs, and even then only while working to migrate to version 2. To do so, you set the following settings in the configuration file.

Protocol 2

Second, you should disable root logins. This ensures that anyone connecting has to know a username to log in, and prevents anyone from having simple access to everything.

PermitRootLogin no

Third, we will increase the server key size. Generally, the more bits for the key the harder to compromise it later. This is done by changing the setting of

ServerKeyBits 758


ServerKeyBits 4096

Once that is complete, you will also need to run the following commands to regenerate the keys:

sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server

Fourth, you want to disable password-based login. You ONLY want to do this one you have set up and confirmed the functionality of your key-based login. Otherwise, you may find yourself unable to log in anymore. When you are ready to proceed, you will modify the following setting:

PasswordAuthentication no
ChallengeResponseAuthentication no

Fifth, unless you what sftp is, and plan to use it, you should disable it. You do so by finding and commenting out the line below.

#Subsystem sftp /usr/lib/openssh/sftp-server

Sixth, you will want to restrict which users can log in via SSH. You can list who is granted such ability either by username or by group. I personally go by the username option.


Finally, you need to restart the SSH server in order for the configuration to be re-read. The method by which you do so varies from distribution to distribution, but on Debian you use the following command:

sudo service ssh restart

When all of those configurations are set, your configuration will look like this:

# What ports, IPs and protocols we listen for
Port 22
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 4096

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 30
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
ChallengeResponseAuthentication no

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
MaxStartups 10:30:60

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# Uncomment following line to enable sftp server
#Subsystem sftp /usr/lib/openssh/sftp-server

# 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 yes

# Lock down to only allow certain users

In addition to the changes above in SSHD configuration, there are other possibilities you can use. Some people suggest moving the port that the SSH server listens on from 22, but that does not particularly add much. It protects against some brute force scanners, but when you are no longer using password authentication your protection does not rely on hiding the server.

Other tools can also be used to add protection. I highly encourage installing denyhosts as well, as it will prevent rapid attacks. You can also configure it to download lists of addresses that attacks are being detected from. The system firewall as well as TCP Wrappers can be used to only allow specific computers to be valid to use the SSH server.

With these modifications, a SSH server is much more secure against attack. The configuration above should be a bare-minimum, and additional protections should be added as specifics require.