SSH Brute Force Protection: IP Blocklists and Best Practices

To protect SSH from brute force, turn off password logins and require SSH keys, keep root password login disabled, and limit who can reach port 22 at the firewall. Then add fail2ban or CrowdSec to ban repeat offenders and cut log noise. A firewall IP blocklist is an optional extra layer, not a replacement.

Any server with port 22 open to the internet gets automated login attempts, because bots scan the IPv4 address space looking for SSH. MITRE ATT&CK tracks this as Brute Force: Password Guessing (T1110.001). The attack is old and simple, and it still works against servers that accept passwords.

This guide covers why SSH is targeted, what the attempts cost you even when they fail, and the defenses in order of impact, with the exact sshd_config settings to use.

What Is an SSH Brute Force Attack?

An SSH brute force attack is an automated attempt to get shell access to a server by guessing username and password combinations against the SSH daemon, usually on port 22. Attackers run it from botnets and rented servers, scanning for open SSH ports and then guessing credentials against every server they find.

The attack is simple. The bot connects to port 22, tries a common username (root, admin, ubuntu, deploy) with a password from a list of common or leaked credentials, then repeats. Spread across many source IPs, the attempts add up and each IP can stay below per-IP ban thresholds.

Unlike VPN brute force attacks that target web-based login portals, SSH brute force attacks target the SSH protocol directly. A web application firewall (WAF) does not see them; they have to be stopped at the network or host level.

Why SSH Is a Common Target

SSH is one of the most common brute force targets on the internet, for several reasons:

• It is everywhere: SSH is the default remote management protocol for Linux servers, cloud instances, and many network appliances and IoT devices.
• Root is a known username: OpenSSH’s default for PermitRootLogin is prohibit-password, which blocks password logins as root. Some images and older configs set it to yes, and then a guessed root password gives full control with no privilege escalation needed.
• Passwords are on by default: OpenSSH’s default for PasswordAuthentication is yes. Key-only authentication has to be configured deliberately.
• Easy to identify: once a TCP connection opens, the server sends a version banner (for example SSH-2.0-OpenSSH_9.6p1), so scanners can confirm SSH and see the software version.
• Direct shell access: a VPN portal grants network access; SSH grants a command line on the server itself. One compromised SSH credential can mean control of the machine.

The Damage Beyond Compromised Servers

Even when attackers never guess a correct password, SSH brute force attacks cause significant operational damage:

CPU and Memory Load

Each SSH authentication attempt consumes CPU cycles on your server. The SSH daemon must accept the TCP connection, perform the SSH handshake, and process the authentication attempt. With many attempts per hour, this adds load, which is most noticeable on low-powered cloud instances and IoT devices with limited resources.

Log Flooding

Every failed SSH login writes entries to /var/log/auth.log (or /var/log/secure on RHEL-based systems, or the systemd journal). During a sustained campaign these logs grow quickly, use disk space, and bury the legitimate authentication events you actually need to find. If you ship logs to a service that charges by volume, the noise also costs money.

Fail2ban Overhead

Many administrators run Fail2ban to ban IPs after repeated failed logins. It works well against single noisy IPs, but it has to parse every log line and add a firewall entry per ban. With the plain iptables actions each ban is a separate rule, so long ban lists slow packet processing; the ipset and nftables set-based actions scale much better and are worth switching to if you ban many IPs.

Lateral Movement Risk

If an attacker does compromise one server over SSH, the damage rarely stops there. Private keys and known_hosts files on that server can point to, and sometimes unlock, other machines. Internal SSH is often configured less strictly than internet-facing SSH, which makes moving from one compromised host to the next easier. This is why key hygiene matters as much as stopping the first login.

SSH Defenses in Order of Impact

Start with the changes that remove password guessing outright, then add the layers that cut exposure and noise.

1. Key-Only Authentication

Disabling password authentication and requiring SSH keys is the most effective single change. With passwords off, password brute force cannot succeed because there is no password to guess, and the server stops offering the password method to clients.

To deploy: generate a key pair for each user (ssh-keygen -t ed25519), copy the public key to the server (ssh-copy-id or configuration management), and confirm you can log in with the key. Then set these in /etc/ssh/sshd_config (see the OpenSSH sshd_config manual):

• PasswordAuthentication no
• KbdInteractiveAuthentication no (older guides call this ChallengeResponseAuthentication, which OpenSSH 8.7 and later treat as a deprecated alias)
• PermitRootLogin no, or leave the default prohibit-password if root needs key-based access

sshd uses the first value it reads for each setting, and many distributions include /etc/ssh/sshd_config.d/*.conf near the top of the main file, so a drop-in file (for example one written by cloud-init) can override your change. Run sshd -t to check the syntax, sshd -T | grep -i passwordauthentication to see the value sshd will actually use, then reload the service. Keep your current session open until a fresh key login works.

2. Restrict Who Can Reach Port 22

If only known people and systems need SSH, allow port 22 only from their addresses at the cloud security group or firewall, or put SSH behind a VPN or a bastion host. Traffic from everyone else never reaches sshd, which removes most of the noise as well as the risk.

3. Fail2ban or CrowdSec

Fail2ban watches the SSH log and bans IPs that fail too many times within a time window. Its stock jail.conf defaults are 5 failures within 10 minutes for a 10-minute ban; put your own values in jail.local so package updates do not overwrite them. Longer bans and the incremental bantime.increment option help against IPs that come back.

CrowdSec does local detection in a similar way and can also apply a community blocklist built from detections shared by other CrowdSec users. Both are reactive at the local level: an IP has to misbehave on your server, or on others in the CrowdSec community, before it is blocked.

4. SSH Certificates (Larger Fleets)

Instead of managing individual public keys on every server, you run an SSH Certificate Authority (CA) that signs short-lived user certificates. Servers trust the CA through TrustedUserCAKeys, and users authenticate with certificates that expire after hours or days. This removes key sprawl and simplifies revocation, and like key-only auth it leaves no password to guess.

Tools such as HashiCorp Vault, Teleport, and Smallstep can issue SSH certificates. It is the most work of anything on this list, because it involves CA infrastructure, identity-provider integration, and changing how every user connects.

5. Change the SSH Port (Noise Reduction)

Moving SSH from port 22 to a non-standard port cuts the log noise from bots that only try the default port. Set Port in sshd_config, open the new port in your firewall before reloading sshd, and on SELinux systems label it with semanage port -a -t ssh_port_t -p tcp 2222. Some recent distributions start sshd through systemd socket activation, so check your distribution’s notes on changing the port.

6. Firewall IP Blocklist (Optional Extra Layer)

An IP blocklist loaded on your firewall, for example as an External Dynamic List (EDL), drops listed IPs at the perimeter so their connections never reach sshd. It only helps against IPs that are already on the list.

Be clear about what the ThreatListPro list is: it comes from real attacks on live production Palo Alto GlobalProtect VPN portals in the US, so it is not an SSH-specific feed. It covers SSH attackers only where the same sources also attack VPN portals. If you run a VPN portal as well as SSH servers, one firewall rule can apply it to both; see the firewall setup guides, or use the IP checker to see whether addresses from your own SSH logs are on the list.

Where Firewall-Level Blocking Fits

Each defense acts at a different point. Fail2ban blocks at the host, after sshd has already handled some failed attempts. Key-only auth rejects the login during the SSH handshake. A port change reduces noise but does not stop a targeted attacker. A firewall rule acts before the connection reaches the server at all.

That gives perimeter blocking (an allowlist for port 22, or a blocklist) some real advantages:

• Less server load: dropped connections never reach sshd, so they use no CPU or memory on the server
• Quieter logs: connections dropped at the firewall do not appear in your SSH authentication logs
• No server changes: it needs no software or SSH configuration change on each server
• Works with everything else: it runs alongside key-only auth, Fail2ban, and port changes without conflict
• Blocks before the first attempt: a listed IP is blocked on its first connection, which Fail2ban cannot do

A blocklist is not a replacement for key-only authentication or for restricting who can reach port 22. Do those first. A blocklist is worth adding where it overlaps the attackers you actually see.

SSH Brute Force Protection Methods Compared