SSH Configuration

Introduction

The Secure Shell (ssh), sometimes also known as Secure Socket Shell, is a protocol for gaining secure access to a remote computer. It is widely used by network administrators to control Web and other kinds of servers remotely. ssh is actually a suite of three utilities - slogin, ssh, and scp - which are secure versions of earlier UNIX utilities, rlogin, rsh, and rcp. ssh commands are encrypted and secure in several ways. Each end of the client/server connection is authenticated using a digital certificate, and passwords are protected by being encrypted.

For comprehensive definitions of this and closely related topics see:

• http://en.wikipedia.org/wiki/Secure_Shell
• http://en.wikipedia.org/wiki/OpenSSH
• http://en.wikipedia.org/wiki/OpenSSL

The following guidance might be useful in helping to configure ssh on a Linux server.

My SSH Server Configuration

After experimentation I arrived at the following /etc/ssh/sshd_config configuration file. Only the relevant lines are shown:

$ sudo more sshd_config
...

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

#...

# Port 22
# Protocol 2,1

# ListenAddress 0.0.0.0
# ListenAddress ::

# ...

# Logging
# obsoletes QuietMode and FascistLogging
# SyslogFacility AUTH
SyslogFacility AUTHPRIV
# LogLevel INFO

# Authentication:

# LoginGraceTime 2m
PermitRootLogin no
# StrictModes yes
# MaxAuthTries 6

RSAAuthentication       yes
PubkeyAuthentication    yes
AuthorizedKeysFile      .ssh/authorized_keys

# ...

# To disable tunneled clear text passwords, change to no here!
...
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable s/key passwords
# ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# ...

# GSSAPI options
# GSSAPIAuthentication no
GSSAPIAuthentication yes
# GSSAPICleanupCredentials yes
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 mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
# UsePAM no
UsePAM yes

# AllowTcpForwarding yes
# GatewayPorts no
# X11Forwarding no
X11Forwarding yes
# X11DisplayOffset 10
# X11UseLocalhost yes
# PrintMotd yes
# PrintLastLog yes
# TCPKeepAlive yes
# UseLogin no
# UsePrivilegeSeparation yes
# PermitUserEnvironment no
# Compression yes
# ClientAliveInterval 0
# ClientAliveCountMax 3
# UseDNS yes
# PidFile /var/run/sshd.pid
# MaxStartups 10
# ShowPatchLevel no

# no default banner path
# Banner /some/path

# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server
$

In this configuration password authenication has been disabled and all access to the ssh server is by the use of public/private authenication keys. I got tired of seeing my ssh default port being hit 2000-5000 times per 24hrs with attempts to gain access by password authenication, even though I was sure I was using secure passwords I could see every username/password combination under the sun being tried. So I turned password authenication off and use public/private key authenication instead! It's easy to set up and I don't need to worry about passwords being cracked: without the keys (which I physically store safely) there is no access to my ssh server.

I also considered opting to not use the default port 22, rather changing it to an alternative value (not shown) to use a security through obscurity approach in order to reduce the large number of hits on Port 22 I was observing on the server. In fact I did adopt this approach for a while but decided to stop using it again because of the general inconvenience that it causes (e.g. it proved not to be possible to use ssh from the office on anything other than port 22 due to firewall port rules only allowing port 22.

I finally decided to use the TCP Wrapper approach to allow/deny access to ssh on the basis of permitted IP addresses and/or subnets only being able to access the ssh server (on port 22). This is restrictive, I have to enable TBA if I move from my normal access locations, but not inconveniently so. This is addressed in more detail below.

Firewall Configuration

The firewall/port-blocking configuration of any routers/firewalls used on the LAN needs careful attention. As noted above ssh by default uses port 22, if this is altered on the ssh server then the firewall needs to be modified accordingly. Otherwise just forward port 22 are necessary to the Linux server hosting ssh.

TCP Wrapper

Through use of the TCP Wrapper approach to allow/deny access to ssh, it is possible to reduce the number of hits on the ssh port very significantly; in general rogue programs trying to access my ssh server made only two attempts before giving up, whereas previously when they got through to the ssh server they would tend to try brute-force password cracking and make many hundreds, or even more, of attempts to find a password for numerous, common, user account names (such as root, system, admin, oracle, fred, etc).

TCP Wrapper is a host-based Networking ACL system. This approach allows the system admininstrator to define lists of IP addresses and/or subnets to be specially allowed or denied access to programs; the approach is not just limited to ssh, it can also be used to govern access to other programs such as vsftpd (Very Secure FTP Daemon), etc.

The configuration details used for this are described in TCP-Wrapper.

OpenSSL Vulnerability

Recently a severe vulnerability was found in the random number generator (RNG) of the OpenSSL package used by some Linux systems, specifically Debian or Debian-derived variants, Ubuntu, etc. Source TechRepublic: see the Finding weak OpenSSL/OpenSSH keys report available on the TechRepublic site.
So affects the Debian OpenSSL package, starting with version 0.9.8c-1 (and similar packages in derived distributions such as Ubuntu).

Specifically if a system provides ssh access to a remote user account and that account is based on one of the flawed (mainly Debian or Debian-derived variants, Ubuntu) OpenSSL implementations and was used to generate the ssh key-pair used in the ssh exchange then the system, or specifically those user accounts, may be compromised. If keys used are generated on an affected Linux system then the keys may be compromised (reported ca. 20mins to crack in brute-force attack).

See the following links for further information on how to detect whether you have potentially affected (i.e. weak) keys, and what to do to fix it:

• Find and fix weak OpenSSL/OpenSSH keys: Debian-based Linux vulnerability
• Detect and replace vulnerable SSH keys on Debian
• Debian Wiki: SSLKeys

While this bug is not present in the OpenSSL packages provided by CentOS (my Linux installation), it may still affect CentOS users, as reported in: [CentOS-announce] Impact of the Debian OpenSSL vulnerability.

Executing the steps defined in the first two bullet points above should show a history similiar to the following:

# curl -O -L http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10.7M  100 10.7M    0     0   503k      0  0:00:21  0:00:21 --:--:--  487k
#

# curl -O -L http://security.debian.org/project/extra/dowkd/dowkd.pl.gz.asc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   481  100   481    0     0   1811      0 --:--:-- --:--:-- --:--:--     0
#

# gpg --keyserver subkeys.pgp.net --recv-keys 02D524BE
gpg: key 02D524BE: public key "Florian Weimer (HIGH SECURITY KEY)
" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
#

# gpg --verify dowkd.pl.gz.asc
gpg: Signature made Sun 18 May 2008 06:54:24 PM BST using RSA key ID 02D524BE
gpg: Good signature from "Florian Weimer (HIGH SECURITY KEY)
"
gpg: checking the trustdb
gpg: no ultimately trusted keys found
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C8D3 D9CF FA9E 7056 3F32  FA54 BF7B FF04 02D5 24BE
#

# gunzip dowkd.pl.gz

# perl dowkd.pl host localhost
notice: creating database, please wait
# localhost SSH-2.0-OpenSSH_3.9p1
# localhost SSH-2.0-OpenSSH_3.9p1
summary: keys found: 2, weak keys: 0
#

# perl dowkd.pl user
/home/username/.ssh/authorized_keys:2: warning: no blacklist for rsa/1023 key
key_read: uudecode
AAAAB3NzaC1yc2EAAAABIwAAAIEAu6hRcbC52+Go2n9/WB39Gngh84AQWsvfnxuZOZfIVS01zpBmivIXAAEz7CorjvkCvicUUw+NypDUAyhW/LiO+NQAoEoHuEyQfztUVUWazV5SwWM5uokTDERIvD
 failed
/home/ username /.ssh/authorized_keys:4: warning: unparsable line
/home/ username /.ssh/authorized_keys:5: warning: unparsable line
/home/ username /.ssh/known_hosts:5: weak key (OpenSSH/rsa/2048)
/home/ username /.ssh/known_hosts:6: weak key (OpenSSH/rsa/2048)
summary: keys found: 18, weak keys: 2

If the script indicates that any keys are weak, they should be removed and regenerated immediately. So once you have determined what keys need to be replaced, it's time to do something about it. For each user that needs new SSH keys generated, first delete the old keys, and then re-generate the new keys using the ssh-keygen tool.

Since the problem was discovered and fixed in Debian, there has been a new tool added to the standard distribution of OpenSSH for Debian and derived Linux distributions called ssh-vulnkey. This tool was specifically designed to detect any vulnerable OpenSSH keys within a common range, if they exist on your system, so that you can replace them. It is installed by default when you update your OpenSSH install to a secure version.

General Links

The following general links are useful references when setting up ssh: