Designed Cybersecurity
Tutorials

Harden Your OpenSSH Configuration

Michael Berg
Posted . Last modified .

Make your OpenSSH servers and clients more secure with these hardened settings.

You may want to review the typographical conventions used on this site.

Threat Model

If you have an Internet-facing SSH server, your logs almost certainly contain records of frequent brute-force password authentication attempts by malware. Most of this malware is trying common username and password combinations. Some of this malware is trying specific usernames and passwords obtained from data breaches at other sites. It only takes one user with a weak or re-used password for this malware to gain a foothold on your system.

OpenSSH provides many powerful features, including ssh-agent forwarding and X11 forwarding. However, if these features are enabled in an SSH client’s connection, malicious or compromised SSH servers can use ssh-agent forwarding to authenticate to other systems with a client’s forwarded credentials and can use X11 forwarding to access the client’s local X11 display to perform activities such as keystroke monitoring. These powerful, but risky, features must be disabled by default.

Surveillance states around the world want to exploit cryptographic weaknesses in order to decrypt SSH sessions. For a number of legacy and compatibility reasons, the default settings in OpenSSH support various cryptographic algorithms that shouldn’t be supported in a hardened configuration.

Design Requirements

Strong Authentication

Disable password authentication (PasswordAuthentication no) and require public key authentication (PubkeyAuthentication yes) to defend against password-guessing brute-force malware. Since these brute-force attempts are trying to authenticate using guessed or stolen passwords, disabling password authentication removes that attack path.

Disable or restrict root logins (PermitRootLogin no or PermitRootLogin prohibit-password) and restrict logins to the members of a specific group (AllowGroups ssh-users) to further restrict the available attack paths and provide additional defense in depth.

Disable host-based authentication (HostbasedAuthentication no) to prevent abuse of trust relationships between hosts and to require that all authentication is user-based.

Disable Risky Features

Disable client-side ssh-agent forwarding (ForwardAgent no), X11 forwarding (ForwardX11 no and ForwardX11Trusted no), and local commands (PermitLocalCommand no) to prevent malicious or compromised SSH servers from abusing these features to attack the client or other systems.

In cases where these features are required and the SSH server is trusted, the required features can be enabled in that specific command line invocation.

Strong Cryptographic Algorithms

OpenSSH is gradually deprecating weak algorithms. However, unless you need to support legacy clients, there is no need to wait. Disable the weak algorithms in your configuration files today.

Host and User Keys

Only support ED25519 and RSA keys. Prefer ED25519 where possible. Use the HostKeyAlgorithms and PubkeyAcceptedKeyTypes options to restrict the enabled algorithms. Use the HostKey or IdentityFile options to restrict the respective host or user keys.

Check which key algorithms are available to use with the respective command:

ssh -Q HostKeyAlgorithms
ssh -Q PubkeyAcceptedKeyTypes

The acceptable key algorithms are:

Do not support DSA or ECDSA keys. First, DSA keys are limited to 1024-bits, which can be broken. Next, DSA and ECDSA both leak bits from the private key if the random number generator if flawed. Finally, there are concerns about the security of the NIST elliptical curves used in ECDSA.

Key Exchange

Only support Curve25519 and strong Diffie-Hellman groups. Prefer Curve25519 where possible. Use the KexAlgorithms option to restrict the enabled algorithms.

Check which key exchange algorithms are available with the command:

ssh -Q KexAlgorithms

The acceptable key exchange algorithms are:

Do not support the Elliptical Curve Diffie-Hellman (ECDH) algorithms that are using the NIST elliptical curves. As previously covered, there are concerns about the security of the NIST elliptical curves.

Ciphers

Only support ChaCha20, AES in GCM mode, and AES in CTR mode. Use the Ciphers option to restrict the enabled algorithms.

Check which ciphers are available to use with the command:

ssh -Q Ciphers

The acceptable ciphers are:

Do not support ARCFOUR (RC4), 3DES, Blowfish, CAST-128, or AES in CBC mode. RC4 has been broken. 3DES, Blowfish, and CAST-128 are limited to 64-bit block sizes, which limits the amount of data that can be securely sent with each key. SSH messages that employ CBC mode may allow an attacker to recover plaintext from a block of ciphertext.

MACs

Only support SHA2 HMACs. Prefer the Encrypt-then-Mac (ETM) variants where possible. Use the MACs option to restrict the enabled algorithms.

Check which MACs are available to use with the command:

ssh -Q MACs

The acceptable MACs are:

Do not support MD5. Try not to support SHA1. However, to support certain SSH clients, you might be forced to add hmac-sha1 to the end of this list.

Client Configuration

The following OpenSSH client configuration implements these design requirements.

/etc/ssh/ssh_config or ~/.ssh/config

Host *
    Protocol 2
    HostKeyAlgorithms sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
    KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
    StrictHostKeyChecking ask
    VerifyHostKeyDNS ask
    ForwardAgent no
    ForwardX11 no
    ForwardX11Trusted no
    PermitLocalCommand no
    HashKnownHosts yes
    TCPKeepAlive yes
    SendEnv LANG LC_*

Server Configuration

The following OpenSSH server configuration implements these design requirements.

Create an ssh-users group. SSH logins will be restricted to members of this group.

groupadd --system ssh-users

For each user that should be able to SSH into the system, add that user to the ssh-users group.

usermod -a -G ssh-users [username]

Ensure that each of the above users has a key configured in an appropriate authorized_keys file.

Generate new, stronger ED25519 and RSA host keys.

rm -f /etc/ssh/ssh_host_*key*

ssh-keygen -o -t ed25519 -N '' -f /etc/ssh/ssh_host_ed25519_key
ssh-keygen -o -t rsa -b 4096 -N '' -f /etc/ssh/ssh_host_rsa_key

Modify or add the following lines in /etc/ssh/sshd_config. Remove any HostKey lines other than the two shown below for the ED25519 and RSA host keys generated in the previous step.

Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

HostKeyAlgorithms sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
PubkeyAcceptedKeyTypes sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

PermitRootLogin prohibit-password
AllowGroups ssh-users

PubkeyAuthentication yes

ChallengeResponseAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no

HostbasedAuthentication no
IgnoreRhosts yes

Once these changes are complete, restart the OpenSSH server.

systemctl restart ssh

Don’t close your active SSH session until you have verified that you can SSH into the system under these new settings. If there are any problems establishing a new SSH session, you can troubleshoot, resolve problems, or revert specific changes using your still-open SSH session.

Tags: encryption, OpenSSH, privacy, security, SSH