Mastering SSH Hardening: From Port Changes to Certificate Authentication

Online servers are constantly targeted by brute‑force SSH attacks, so a solid hardening process is essential. The article begins with a background on why the default OpenSSH configuration is insecure—allowing root login, password authentication, and listening on port 22—and presents a complete hardening roadmap verified on CentOS 7/8/9 and Ubuntu 20.04/22.04.

Core Hardening Steps

Port Modification : Change the listening port (e.g., to 52222) to filter out most automated scans. The article notes that failing login records in /var/log/secure drop from tens of thousands to single digits after the change.

Disable Root Login : Set PermitRootLogin no to prevent direct root access.

Enforce Key‑Based Authentication : Generate an ed25519 key pair (preferred over RSA‑4096 for speed and size) with ssh-keygen -t ed25519 -C "user@domain". Add the public key to ~/.ssh/authorized_keys and set strict permissions ( chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys).

Disable Password Authentication : Set PasswordAuthentication no and ChallengeResponseAuthentication no. Verify that key login works before applying.

Fine‑Grained Access Control : Use AllowUsers or AllowGroups to whitelist specific accounts, and optionally employ Match blocks for per‑user or per‑IP policies.

Connection Limits : Configure LoginGraceTime 30, MaxAuthTries 3, MaxSessions 5, MaxStartups 10:30:60, and keep‑alive settings ( ClientAliveInterval 300, ClientAliveCountMax 3) to mitigate DoS and idle sessions.

Performance Tweaks : Disable DNS reverse lookup ( UseDNS no) and GSSAPI ( GSSAPIAuthentication no) to eliminate connection delays, and enable compression only on low‑bandwidth links.

Fail2Ban Integration

Fail2Ban monitors /var/log/secure (or /var/log/auth.log on Ubuntu) and bans IPs after a configurable number of failures. A sample jail.local is provided with bantime = 3600, maxretry = 5, and the custom SSH port. Commands to start, enable, and query Fail2Ban status are included.

Certificate‑Based Authentication (CA)

For environments with dozens or hundreds of servers, managing individual authorized_keys files becomes impractical. The guide shows how to create a CA key ( ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key), distribute the CA public key to all servers ( TrustedUserCAKeys /etc/ssh/ca_user_key.pub), and sign user keys with

ssh-keygen -s /etc/ssh/ca_user_key -I cert-id -n user1,user2 -V +52w ~/.ssh/id_ed25519.pub

. Revocation is handled via a RevokedKeys file.

SSH Config Management for Large Environments

The article demonstrates using ~/.ssh/config with host aliases, ProxyJump, and connection multiplexing ( ControlMaster auto, ControlPath ~/.ssh/sockets/%r@%h-%p, ControlPersist 600) to simplify access to dozens of machines. It also shows an Include ‑based layout ( config.d/*.conf) to separate environment‑specific settings (dev, test, prod) and maintain per‑environment keys.

Automation Scripts

Two Bash scripts are provided: distribute_ssh_keys.sh – batch distributes a public key to a list of hosts, optionally using sshpass for initial password‑based deployment. rotate_ssh_keys.sh – rotates a host’s key pair, backs up the old keys, and re‑distributes the new public key to all managed servers, with verification steps.

Best Practices & Pitfalls

Always keep an active SSH session when editing sshd_config; use sshd -t to check syntax and systemctl reload sshd to apply changes without dropping connections.

Place firewall rules (firewalld or iptables) to restrict SSH source IPs before changing the port.

Ensure strict file permissions: chmod 700 ~/.ssh, chmod 600 ~/.ssh/id_*, chmod 600 ~/.ssh/authorized_keys, and home directory no more permissive than 755.

When using AllowUsers or AllowGroups, remember that any user not listed is denied, including root.

Be aware of compatibility: ed25519 requires OpenSSH 6.5+, ProxyJump and Include need 7.3+. For older systems use ProxyCommand instead.

Monitoring & Troubleshooting

Key diagnostic commands include journalctl -u sshd -f, ss -tlnp | grep 52222, and verbose client logs ( ssh -vvv). Common issues such as "Permission denied (publickey)", connection timeouts, and "Too many authentication failures" are explained with step‑by‑step checks (permissions, authorized_keys content, SELinux context, IdentitiesOnly, DNS/GSSAPI settings).

Performance Monitoring

Suggested Prometheus rules track active connections, authentication failures, fail2ban bans, and sshd process health. A sample ssh_metrics.sh script exports these metrics via the node_exporter textfile collector.

Backup & Recovery

A backup script copies sshd_config, host keys, fail2ban configuration, and optional CA keys to a dated directory, sets strict permissions, and prunes old backups. Recovery steps include stopping sshd, restoring files, verifying syntax, and restarting the service.

Conclusion

The guide consolidates essential SSH hardening techniques—port change, key‑based auth, fail2ban, certificate auth, and configuration management—into a reproducible workflow suitable for small teams and large fleets alike. It also points to advanced topics such as Vault‑driven dynamic certificates, FIDO2 hardware keys, and zero‑trust SSH gateways for future exploration.