> ## Content Index
> Fetch the complete content index at: https://www.novea.cc/llms.txt
> Use this file to discover other available public pages before exploring further.

# SSH Brute Force: What the Logs Actually Say
- URL: https://www.novea.cc/ssh-brute-force-real-numbers-what-the-logs-say/
- Published: 2026-09-05T17:44:43.000Z
- Updated: 2026-09-05T17:44:43.000Z
- Description: What those thousands of failed logins really are, how to read the pattern, and why a key is the end of the story.
- Author: Ethan Nicolas
- Tags: Linux, Security, Hardening

Every server I have ever exposed to the internet gets hit with SSH brute force within hours. I used to find it worrying. Then I read the logs properly and realized it is mostly machines, mostly stupid, and entirely stoppable.

## What the noise actually looks like

On a fresh box, this shows up within a day:

```
sudo grep "Failed password" /var/log/auth.log | head -20
# or, on systemd systems:
journalctl -u ssh --since today | grep "Failed password" | head -20
```

The pattern is always the same: thousands of attempts, a handful of usernames (root, admin, ubuntu, then a few from wordlists), and source IPs spread across the world. The usernames are dictionary words, not your actual accounts. These are bots, running the same lists against millions of servers, and they do not care about you in particular.

## Read the numbers like a sysadmin, not a news headline

```
# attempts in the last week
journalctl -u ssh --since "-7 days" | grep -c "Failed password"

# top 10 attacking IPs
journalctl -u ssh --since "-7 days" | grep "Failed password"   | grep -oE "from [0-9.]+" | sort | uniq -c | sort -rn | head
```

Steady noise is normal. Watch instead for changes: a sudden spike, an IP that tries thousands of times, or usernames that match your real accounts. That last one means someone is aiming at you, and you will see it in the logs long before they get anywhere.

## The fix is boring, which is why it works

Disable password login. Not "use a strong password" — turn passwords off entirely and use keys. A key is 300+ bits of randomness; a brute-forcer needs the heat death of the universe, not a weekend:

```
# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
```

```
sudo systemctl reload ssh
```

Do it from a second terminal so you can test before you lock yourself out. After that, the brute force continues in the logs but becomes harmless — the bots keep trying, and the attempts stay failed forever.

If you still want the logs quieter, fail2ban or CrowdSec will ban the repeat offenders after a few tries. It is cosmetic once passwords are off, but it keeps the auth log readable, and a readable log is one you actually check.

Leave password auth enabled and the math is simple: one of those millions of machines will eventually guess a password that is not strong enough. The logs are not telling you that you are under attack. They are telling you that you forgot to lock the door.