the raw numbers behind why ssh keeps getting brute forced

the raw numbers behind why ssh keeps getting brute forced

someone asked for the data instead of taking my word for it. fair. so let's pull it. spin up a cheap cloud vm, leave port 22 open with password auth on, walk away for a few hours, and come back to a log file that looks like a crime scene. this is what that looks like and why the fix is boring but non negotiable.

the command that started this

this is the whole investigation in one line:

grep 'Failed password' /var/log/auth.log

grep searches text for a pattern. 'Failed password' is the exact string sshd writes to the log every single time someone (or something) tries to log in and gets it wrong. /var/log/auth.log is where debian and ubuntu keep authentication history. on rhel or centos boxes you'd point this at /var/log/secure instead.

run that on a fresh box that's been online for a day and you'll likely get thousands of lines back. not because you're special or targeted. because you exist with an ip address and an open port.

how many attackers, not just how many attempts

thousands of failed logins doesn't mean one determined person. to see how many distinct bots are involved, pull the ip out of each line and count uniques:

grep 'Failed password' /var/log/auth.log | awk '{print $(NF-3)}' | sort -u | wc -l

awk '{print $(NF-3)}' grabs the field that holds the source ip (the exact position can shift depending on log format, so check a sample line first). sort -u removes duplicates. wc -l counts what's left. on most exposed servers this comes back in the hundreds. hundreds of separate hosts, most of them other people's compromised machines, all automated, all running the same playbook of common usernames and leaked password lists.

the internet-scale part: shodan

your one box isn't an isolated incident, it's a drop in an ocean. shodan is a search engine that continuously scans the internet and indexes what it finds open. search port:22 and you'll see the count sitting in the millions of publicly reachable ssh servers at any given moment.

that number matters because it tells you attackers aren't hand picking targets. they're running mass scanners that sweep entire ip ranges, find anything answering on 22, and hand it off to a brute force script. you get hit not because you were noticed, you get hit because the scanner reached your range that day.

why keys break the entire attack

password auth means the attacker just needs to guess a string. that's a solvable problem at scale, which is exactly why the bot networks exist. key based auth changes the math completely. instead of a password, your server holds a public key and only accepts a login from whoever holds the matching private key. there is no string to guess. there's no password field for the brute forcer to even attack, because you've turned password auth off entirely.

a rsa or ed25519 keypair isn't brute forceable in any practical sense with current computing. the attacker's whole toolkit becomes useless the second you disable password login.

how to protect your own box

first, generate a key pair on your own machine if you don't have one:

ssh-keygen -t ed25519 -C "your-label-here"

copy the public key to your server:

ssh-copy-id user@your-server-ip

then edit /etc/ssh/sshd_config on the server and set:

PasswordAuthentication no
PermitRootLogin no

restart sshd, then test the key login from a second terminal before you close your current session, so you don't lock yourself out. once that's confirmed, also consider moving ssh off port 22 to cut down on the low effort automated noise, and use fail2ban to auto ban ips that fail repeatedly, as a backup layer, not a replacement for keys.

the takeaway

the numbers aren't scary because someone's targeting you specifically. they're scary because the internet is full of bots doing this to everyone, all the time, as a baseline condition of having a public ip. check your own auth.log, see your own numbers, then close the door that makes those numbers possible. keys only. no exceptions.