Any Linux server with port 22 open to the internet is being probed continuously. Most of it is automated and untargeted. Some of it is not.
What it looks like
Check your auth log:
sudo grep "Failed password" /var/log/auth.log | tail -50
Count attempts by source:
sudo grep "Failed password" /var/log/auth.log \
| awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20
Two patterns matter. Concentrated: one IP, hundreds of attempts, usually against root or admin, noisy and easy to block. Distributed: many IPs, a handful of attempts each, often against a valid username. That one is quieter, more deliberate, and slips past naive thresholds.
Blocking automatically
fail2ban handles the concentrated case well. A reasonable SSH jail:
[sshd]
enabled = true
maxretry = 4
findtime = 600
bantime = 3600
For distributed attempts, per-IP thresholds do not trigger. You need to correlate across sources, the signal is the username being targeted, not the IP. If you are weighing fail2ban against a shared-reputation approach that catches distributed attacks earlier, I compared the two in fail2ban vs CrowdSec.
Removing the attack surface entirely
Blocking is a response. Prevention is better: disable password authentication and the brute force problem disappears, because there is no password to guess. Attempts still appear in logs but cannot succeed. That change, and the rest of the SSH lockdown, is covered in the SSH hardening checklist.
What to check after a heavy attempt
Blocked does not mean safe. Verify nothing got through:
sudo grep "Accepted" /var/log/auth.log | tail -20
sudo last -20
Then check for persistence: new entries in ~/.ssh/authorized_keys, new cron jobs, new systemd services, changed sshd_config. If an attacker did get in, they often leave a webshell in a web-writable directory as a second way back - worth checking for at the same time.
The safety net that matters
One risk of aggressive auto-blocking is banning yourself. It happens more than people admit, a bad password from an office IP during an incident, and now you cannot reach the server.
Any auto-blocking system needs a permanent allowlist for your own infrastructure and known-good admin IPs. SecAI treats this as non-negotiable: your own server IPs and trusted addresses are exempt from auto-block by design, so remediation can never lock you out. It blocks hostile sources and monitors for persistence automatically, while keeping you safely on the allowlist.