SSH Hardening Guide: The sshd_config Settings That Actually Matter for Enterprise Linux Security

Edit /etc/ssh/sshd_config (or drop a file in /etc/ssh/sshd_config.d/ on distributions that support include directories):

# Disable root login -- use sudo from a named account
PermitRootLogin no

# Disable password authentication -- keys or certificates only
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Disable empty passwords (should be default but make it explicit)
PermitEmptyPasswords no

# Limit SSH to protocol 2 only (protocol 1 has cryptographic flaws)
Protocol 2

# Restrict to specific groups or users
AllowGroups ssh-users admins
# Or by user:
# AllowUsers alice bob carol

# Set idle session timeout
ClientAliveInterval 300
ClientAliveCountMax 2
# Disconnects idle sessions after 300 seconds * 2 = 10 minutes of no activity

# Limit authentication attempts per connection
MaxAuthTries 3

# Limit open sessions per connection
MaxSessions 4

# Disable X11 forwarding unless required
X11Forwarding no

# Disable TCP forwarding if not needed (blocks SSH tunneling abuse)
AllowTcpForwarding no
GatewayPorts no

# Disable agent forwarding to prevent credential forwarding attacks
AllowAgentForwarding no

# Log at verbose level for forensics
LogLevel VERBOSE

# Banner for legal notice
Banner /etc/ssh/banner.txt

After editing, validate syntax before reloading:

sshd -t && systemctl reload sshd
# sshd -t exits 0 on no errors, non-zero on syntax errors
# Never restart sshd without -t check -- a syntax error will lock you out

Older OpenSSH versions enable weak algorithms for backward compatibility. Remove them:

# Restrict key exchange algorithms to modern elliptic curve methods
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# Restrict symmetric ciphers to AES-GCM and ChaCha20 (AEAD ciphers, no separate MAC needed)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

# Restrict MACs to HMAC-SHA2 (remove MD5 and SHA1 variants)
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

# Restrict host key types
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256

# Restrict public key algorithms accepted from clients
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256

Verify active algorithms from the client:

ssh -vvv user@host 2>&1 | grep 'kex:'
# Should show only the algorithms from your configured list

For RSA host keys, ensure minimum key size is 4096 bits. Regenerate if needed:

rm /etc/ssh/ssh_host_rsa_key*
ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ''
# Prefer Ed25519 for new keys:
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ''

Distributing individual user public keys to authorized_keys files across hundreds of servers does not scale and creates a key sprawl problem -- former employees' keys persist until manually removed.

SSH certificates solve this: users present a certificate signed by a trusted CA; servers trust the CA. To revoke a user's access, you stop issuing them certificates. No authorized_keys cleanup required.

Create the SSH CA (keep the CA private key offline or in a vault):

# Generate the CA key pair (do this on an offline/secure machine)
ssh-keygen -t ed25519 -f /secure/ssh-ca -C 'Enterprise SSH CA'
# Store /secure/ssh-ca (private) in your vault
# Distribute /secure/ssh-ca.pub to all servers

Configure servers to trust the CA:

# On each server, copy the CA public key
cp ssh-ca.pub /etc/ssh/trusted_user_ca_keys
# Add to sshd_config:
TrustedUserCAKeys /etc/ssh/trusted_user_ca_keys
# Remove AuthorizedKeysFile if migrating fully to certificates:
# AuthorizedKeysFile none

Issue a certificate for a user:

# Sign the user's public key with the CA
ssh-keygen -s /secure/ssh-ca \
    -I 'alice@company.com' \
    -n alice \
    -V +8h \
    /home/alice/.ssh/id_ed25519.pub
# Creates id_ed25519-cert.pub with 8-hour validity
# -n sets the principal (username the cert is valid for)
# Short validity forces re-issuance, acting as implicit revocation

For enterprise scale, use a certificate signing service (HashiCorp Vault SSH Secrets Engine, Teleport, or a custom signing endpoint) rather than signing certificates manually.

After hardening, verify that the settings are actually active and have not drifted:

On a single host:

# Dump all active sshd settings
sshd -T | grep -E 'permitrootlogin|passwordauthentication|allowgroups|clientaliveinterval|maxauthtries|x11forwarding|allowtcpforwarding'
# sshd -T shows the full compiled config including defaults -- use this, not grep on sshd_config

Across a fleet (Ansible):

- name: Verify SSH hardening settings
  command: sshd -T
  register: sshd_config

- name: Assert PermitRootLogin is no
  assert:
    that: "'permitrootlogin no' in sshd_config.stdout"

- name: Assert PasswordAuthentication is no
  assert:
    that: "'passwordauthentication no' in sshd_config.stdout"

CIS Benchmark check with Lynis:

lynis audit system
# Lynis checks all CIS SSH configuration requirements and reports pass/fail
# Focus on the SSH section of the lynis report output

Monitor for unauthorized sshd_config changes:

# File integrity monitoring rule (auditd)
auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_change
auditctl -w /etc/ssh/sshd_config.d/ -p wa -k sshd_config_change
# Alert on Event: key=sshd_config_change in your SIEM