SSH Hardening: Key-Based Authentication, Fail2ban, and Secure Daemon Configuration

SSH is the front door of every Linux server, and the internet knocks on it constantly: any host with port 22 exposed collects thousands of automated login attempts per day within hours of coming online. Most of these attacks are trivial password guessing — which means the single highest-value hardening step is making passwords irrelevant. Key-based authentication, a locked-down daemon configuration, and brute-force protection together turn SSH from the most attacked service into one of the most defensible.

Step 1 — Move to key-based authentication

• Generate modern keys: ssh-keygen -t ed25519. Ed25519 keys are short, fast, and the current best practice; protect the private key with a passphrase.
• Distribute the public key with ssh-copy-id user@server, then verify key-based login works from a second terminal before changing anything else — the classic mistake is locking yourself out with your only session.
• For fleets, distribute keys through configuration management (Ansible) or centralize with SSH certificates signed by an internal CA — certificates add expiry and identity to keys and eliminate the authorized_keys sprawl problem.

Step 2 — Harden sshd_config

Edit /etc/ssh/sshd_config (or a drop-in file under /etc/ssh/sshd_config.d/) with the core settings:

• PasswordAuthentication no — the setting that ends brute-force as a threat class. Also set KbdInteractiveAuthentication no so password prompts cannot sneak back through the keyboard-interactive path.
• PermitRootLogin no — administrators log in as themselves and elevate with sudo, preserving accountability. Use prohibit-password only where automation genuinely requires root with keys.
• AllowGroups ssh-users (or AllowUsers) — an explicit allowlist of who may SSH at all; service accounts and everyone else are denied by default.
• MaxAuthTries 3, LoginGraceTime 30, ClientAliveInterval 300 with ClientAliveCountMax 2 — tighten the authentication window and drop dead sessions.
• X11Forwarding no, AllowAgentForwarding no, AllowTcpForwarding no unless a documented use case exists — forwarding features are lateral-movement tools when unneeded.
• Validate before reloading: sshd -t checks syntax; then systemctl reload sshd — and keep your existing session open until a fresh login succeeds.

Step 3 — Add brute-force protection with Fail2ban

• Even with passwords disabled, connection floods waste resources and pollute logs. Fail2ban watches the auth log and firewalls repeat offenders automatically.
• Install and create /etc/fail2ban/jail.local (never edit jail.conf directly) enabling the sshd jail: a sensible start is maxretry = 3, findtime = 10m, bantime = 1h, with bantime.increment = true so repeat offenders earn escalating bans.
• Add ignoreip for your management networks so you cannot ban yourself, and verify operation with fail2ban-client status sshd.

Reduce exposure entirely where possible

• The best SSH attack surface is none: restrict port 22 to management networks or VPN/ZTNA sources at the firewall rather than exposing it to the internet.
• Changing the port to something nonstandard reduces log noise from scanners but is not a security control — never treat it as one.
• For privileged access, add MFA (pam_google_authenticator or hardware-key sk-ed25519 keys) on top of key auth for internet-reachable or Tier 0 systems.

Verify the end state from an external host: password authentication refused, root login refused, an unauthorized user refused even with a valid key, and repeated failures resulting in a firewall ban. Fifteen minutes of configuration removes the single most common Linux compromise vector.