Production SSH Hardening with Ed25519 & Fail2ban (Ubuntu/Debian)

Lock down Linux server remote access against automated brute-force password scans using Ed25519 public keys, custom port, and Fail2ban.

1. Attack Signature & Impact Analysis

Critical (Full Server Compromise)

Internet-facing port 22 servers receive tens of thousands of automated dictionary attacks every day from botnets attempting default credentials (root / admin / ubuntu).

2. Production Hardening Configuration (`/etc/ssh/sshd_config.d/hardening.conf`)

Deploy this validated configuration to your production server or reverse proxy:

# 1. Hardened SSH Daemon Config (/etc/ssh/sshd_config.d/hardening.conf)
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
MaxAuthTries 3
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

# 2. Fail2ban Jail Config (/etc/fail2ban/jail.local)
[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 3
findtime = 600
bantime = 86400

3. Live Simulation & Rule Verification Command

Execute these commands to verify that traffic is actively mitigated without service downtime:

# Test SSH config syntax before restarting daemon
sshd -t
# Check active Fail2ban status
fail2ban-client status sshd

4. Common Misconfigurations & Troubleshooting Gotchas

⚠️ Production Caution: Always keep an active open terminal session connected while testing new sshd configs to avoid accidentally locking yourself out of the remote server!

5. Best Paired With (Complementary Defense Recipes)

Security engineers implementing this rule frequently deploy these complementary baselines: