SSH brute force attacks: where they come from and what stops them

An SSH brute-force attack is a program guessing passwords on your server's SSH login, one try after another. Turn password logins off and use keys, and the guessing has nothing to find. OpenSSH 9.8 and newer also slow attackers down on their own. On older versions, such as the 9.6 in Ubuntu 24.04 LTS, add fail2ban or a blocklist. FFraud's data holds 358,485 addresses confirmed for SSH brute force, and two in three of a random sample sat on home and business lines.

#What is an SSH brute-force attack?

SSH is the remote login most Linux servers expose to the internet, on port 22 by default. A brute-force attack sends user names and passwords to it until one works. A weak password falls sooner or later. A server that accepts only keys gives the guesses nothing to match.

#Where do SSH brute-force attacks come from?

From a very large pool of machines. FFraud's sensors and reports have confirmed 358,485 addresses for SSH brute force. We drew 200 of them at random on October 24, 2026, and asked FFraud's API what kind of connection each one is:

Two in three sat on residential lines, the connections of homes and small businesses, where the attacking machine is often a hacked router, camera or home server. Most of the rest were rented servers. Blocking datacenter ranges alone would have missed two-thirds of these attackers.

They rarely stop at SSH. A third also guessed web logins, and a quarter scanned ports, which is how they find SSH on a port other than 22.

#How do you stop SSH brute-force attacks?

1. Use keys and turn password logins off

With passwords off, guessing has nothing to succeed against. A plain Ubuntu 24.04 install still allows passwords: sshd -T printed passwordauthentication yes in our test. Put the settings in their own file under /etc/ssh/sshd_config.d/:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3
LoginGraceTime 30

The name matters. sshd keeps the first value it reads, and it reads these files in name order. Cloud images ship 50-cloud-init.conf, which can switch passwords back on. In our test, the same lines named 01-hardening.conf turned passwords off, and named 99-hardening.conf they changed nothing.

sudo sshd -t                                   # no output means the config is valid
sudo sshd -T | grep -E '^(passwordauthentication|maxauthtries) '
sudo systemctl restart ssh                     # "sshd" on Fedora and RHEL

Keep your current session open, and log in with your key from a second terminal before you close it. A restart leaves open sessions running.

2. Check whether OpenSSH penalizes attackers itself

OpenSSH 9.8, released on July 1, 2024, refuses addresses that repeatedly fail to log in. The setting is called PerSourcePenalties, and it is on by default: after a failed login, the address waits 5 seconds before it may connect again, and repeat failures add up. ssh -V shows your version. Ubuntu 24.04 LTS ships 9.6, and its sshd rejects the setting:

$ ssh -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.20, OpenSSL 3.0.13 30 Jan 2024
$ /usr/sbin/sshd -t -f /tmp/psp-test.conf
/tmp/psp-test.conf: line 1: Bad configuration option: PerSourcePenalties

OpenSSH warns that penalties hit every user behind a shared address, so servers that take connections through NAT or proxies may need to tune them. PerSourcePenaltyExemptList takes the addresses of your office or monitoring.

3. Add fail2ban where OpenSSH has no penalties

fail2ban reads the SSH log and bans addresses that fail too often. Our fail2ban guide sets it up and shares every ban, so each server warns the others.

4. Block known attackers before they connect

A list of confirmed attackers in the kernel firewall drops them before sshd sees them. Our ipset guide loads one, and FFraud's free badips.txt holds addresses confirmed abusive 6 or more times in 14 days.

5. Close SSH to everyone who does not need it

If only a few addresses need SSH, allow just those in the firewall, or reach the server through a VPN. A port nobody can reach takes no guesses at all.

#Does rate-based blocking catch most attacks?

Less than most people expect. A University of Utah study of four years of SSH logs from more than 500 servers found that rate-based blocking, the method fail2ban uses, caught 66.1 percent of brute-force attacks. Attackers spread their guesses over many addresses, and each address can stay under the limit. The study's own method, which follows an attack across its sources, caught 99.5 percent with 83 percent fewer false positives.

fail2ban and blocklists cut the noise and the load. Keys are the defense that works whether or not anything catches the attacker.

#Does changing the SSH port help?

It cuts the noise in your logs, and it hides nothing from a port scan. A quarter of the SSH attackers in FFraud's data also scanned ports, which finds SSH on any port. Treat a new port as housekeeping and keep keys as the protection.

#How do you know your server is being brute forced?

Count the login attempts with unknown user names since midnight:

sudo journalctl -u ssh --since today | grep -c "Invalid user"

Many failures from many addresses are the background noise of any server on port 22. A successful login you do not recognize is the alarm. Cloud providers flag that case too, such as Google Cloud's "Brute Force: SSH" finding. To see why an address from your log is listed, paste it into the free IP blacklist check.

#Questions people ask