SSH Hardening in Production
Why SSH Is the Primary Attack Surface
In production infrastructure, SSH is usually the only administrative entry point. Attackers do not begin with kernel exploits — they begin with credentials. Weak SSH configuration means full system exposure.
Symptom
- Hundreds or thousands of failed login attempts
- Unknown IP addresses targeting root
- Increased CPU usage during brute-force waves
- Security alerts for authentication anomalies
Root Cause
- PasswordAuthentication enabled
- PermitRootLogin allowed
- Port 22 open to the public internet
- No rate limiting
- Poor SSH key hygiene
Investigation
Inspect SSH configuration:
cat /etc/ssh/sshd_config
Count failed attempts:
grep "Failed password" /var/log/auth.log | wc -l
Top attacking IP addresses:
grep "Failed password" /var/log/auth.log | awk "{print $(NF-3)}" | sort | uniq -c | sort -nr | head
Verify SSH listener:
ss -tnlp | grep ssh
Mitigation
Disable password authentication:
PasswordAuthentication no
Disable root login:
PermitRootLogin no
Validate configuration before restart:
sshd -t
Restart safely:
systemctl restart sshd
Network Restriction
Restrict SSH by trusted IP:
ufw allow from 1.2.3.4 to any port 22
Cloud security group restriction is preferred over relying only on host firewall.
Key Strategy
Generate modern key:
ssh-keygen -t ed25519 -a 100
- No shared keys
- Immediate removal of former employee keys
- Key rotation policy enforced
Hardening Strategy
- Bastion host architecture
- Multi-factor authentication
- Disable legacy ciphers
- Centralized logging
- Rate limiting layer
Why This Matters
SSH compromise enables lateral movement and full infrastructure takeover. Most real-world breaches start with weak authentication controls. Hardening SSH is foundational, not optional.
Verification
sshd -T ssh -v user@server
If password login is still possible, the hardening failed.