Secure existing OpenSSH installation

Secure OpenSSH

Though OpenSSH provides secure solutions to several connectivity quandaries, poor configuration and management of this daemon can still lead to security compromises. Also, do not forget that OpenSSH itself could contain bugs that could be exploited if is used default config file.

These days I got a security advisory that demonstrates above words – possibly exists 0day exploit for OpenSSH daemon, that seems to affect OpenSSH 4.3 on CentOS/RHEL servers.

This post provides you with the instructions how to make your OpenSSH daemon secure and usable as possible.

To quickly secure OpenSSH daemon, open config file located at /etc/ssh/sshd_config and make the following changes:

Protocol 2

PermitRootLogin without-password
StrictModes yes
Banner /etc/sshd_banner

LoginGraceTime 60
MaxAuthTries 3
MaxStartups 10

PermitEmptyPasswords no
PrintLastLog yes
AllowTcpForwarding no

IgnoreRhosts yes
IgnoreUserKnownHosts yes
HostbasedAuthentication no

Create SSH banner, just open in a favourite text editor file /etc/sshd_banner and fit it with following contents:

This is secured SSH service. Your activities are logged and monitored.
Warning: Unauthorized access to this system is strictly prohibited.

To secure access to the OpenSSH daemon it is recommended to disable the password authentication for root user and use a public/private keys. This could be done in two simple steps:
1) On local machine create SSH keys:

ssh-keygen -t dsa

2) Copy the public key to the server. For this, Issue below command on local machine:

scp ~/.ssh/ root@ip.address:~/.ssh/authorized_keys2

The command will copy the authorized_keys2 file to the server, allowing root user to login without the password.

Below is a description of directives used to secure OpenSSH:

This directive allows to specify the version of SSH to use. For security reasons it is strongly recommended to use only protocol 2, because the old version has several security flaws.

Configure behaviour for the root account to eliminate security risks. The without-password argument allows root login only using public keys. The password authentication will not be allowed.

Tells SSH daemon to check user's permissions in their home directory and rhosts files before accepting login. For security reasons it is recommended to enable it because sometimes users may accidentally leave files or directories writable, and script-kiddies may use this to assume user's identity.

Directive tells to SSH daemon to the file that contents should be displayed before login occurs. Usually this directive is used by organizations where is required some legal verbage to be shown when host is accessed.

This parameter tells to SSH daemon drop connection attempts if a successful connection hasn't occured in a specifed amount of seconds. I limited it to 60 seconds.

This directive allows to avoid some brute-force attacks to the daemon by limiting failing connections attempts. By default, users who cannot remember the password, gets 3 attempts.

This parameter enhance security by limiting number of unauthenticated sessions keeped alive. This also helps in combating brute-force attacks because other attempts to authenticate will not be blocked, until one of active sessions succeeds authentication or times out.

Allows or disallows empty passwords. It is recommended to disable them because usage of empty passwords is discouraged for security reasons.

This directive empowers the user to check for security by displaying the users last login time at the time of login.

Controls tunneled connctions of TCP protocols over SSH (like rsync over SSH). Sometimes tunneling is a security risk because it is difficult to detect behaviour of malicious protocols or applications. Also, tunnels are usually used by script-kiddies for crossing firewalls.

This directive enhances security by ignoring the legacy .rhost file from users. This is a best practice, in case rsh/rlogin are enabled or could accidentally become enabled.

Directive is used to protect against users setting up host-based authentication. For security purposes, it is often best to change the directive to yes.

Tells SSH daemon to enable or disable host-based authentication. Most security experts are extremely opposed to any form of host-based authentication and recommends to use public keys or password