adminSSH Brute Force Defense Operations Checklist
SSH brute force attacks are common on public VPS servers. The goal is not only to block bad attempts, but to make SSH access controlled, observable and recoverable.
Core principle
SSH defense has three layers: strong authentication, limited exposure and log-based detection. If one layer fails, the other layers should still reduce risk.
Checklist
- Confirm who needs SSH access.
- Use a non-root sudo user for daily work.
- Confirm SSH key login works.
- Review password authentication policy.
- Review root login policy.
- Allow SSH only through firewall rules you understand.
- Install or verify Fail2ban for repeated failures.
- Review auth logs for repeated attempts.
- Keep provider console recovery available.
- Document SSH access policy.
Reusable lesson
This model applies to VPS administration, cloud servers, deployment users, automation users and emergency recovery accounts.
When to Use This Checklist
Use this checklist when defending SSH access on a public VPS against repeated login attempts and unauthorized access risk.
Required Tools
SSH access, sudo user, SSH keys, UFW, Fail2ban, auth log, provider console
Before You Start
Keep one active SSH session and provider console access available before tightening SSH rules.
Structured Checklist Steps
- List SSH users.
- Test sudo user.
- Test key login.
- Review password authentication.
- Review root login.
- Check firewall access.
- Check Fail2ban.
- Review auth logs.
- Confirm console recovery.
- Document policy.
Verification Steps
- Only intended users can access SSH.
- Key login works.
- Firewall allows only intended SSH access.
- Brute force attempts are visible in logs.
- Recovery console is available.
Rollback Plan
If SSH access is blocked by a security change, use provider console to restore the previous sshd_config or firewall rule, then retest with a safer policy.
Common Mistakes
- Disabling password login before testing keys.
- Closing the only active SSH session.
- No recovery console.
- Ignoring repeated auth failures.
- Keeping old sudo users.
Related Commands
who
getent group sudo
sudo nano /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl reload ssh
sudo tail -n 100 /var/log/auth.log
sudo fail2ban-client status sshd