SSH Brute Force Protection: IP Blocklists and Best Practices

By ThreatListPro Security Team · Published March 14, 2026 · Last verified: March 14, 2026

Every Linux server connected to the internet faces a relentless barrage of SSH brute force attacks. Within minutes of exposing port 22, automated botnets begin hammering your SSH daemon with credential-guessing attempts—thousands per day, from IPs scattered across the globe. An SSH brute force attack is one of the oldest and most common threats on the internet, yet it remains devastatingly effective against servers that rely on password authentication alone.

This guide explains exactly why SSH is targeted, what damage these attacks cause, and—most importantly—the fastest ways to stop them, ranked by deployment speed.

What Is an SSH Brute Force Attack?

An SSH brute force attack is an automated attempt to gain shell access to a server by rapidly guessing username and password combinations against the SSH daemon running on port 22. Attackers deploy botnets—networks of thousands of compromised machines—to scan the entire IPv4 address space for open SSH ports and then launch sustained credential-guessing campaigns against every server they find.

The attack is simple but effective. The bot connects to port 22, attempts a login with a common username (root, admin, ubuntu, deploy) and a password from a dictionary of common or leaked credentials, then repeats. A single botnet node might try 100 passwords per minute. Multiply that across thousands of nodes, and the scale becomes overwhelming.

Unlike VPN brute force attacks that target web-based login portals, SSH brute force attacks target the SSH protocol directly. This means they bypass any web application firewall (WAF) and can only be stopped at the network or host level.

Why SSH Is the #1 Target

SSH accounts for roughly 65% of all brute force attacks observed on the internet. Port 22 is second only to port 443 in terms of malicious scanning volume. There are several reasons SSH is disproportionately targeted:

• Ubiquity: Port 22 is open on nearly every Linux server, cloud instance, IoT device, and network appliance on the internet. It is the default management protocol for the vast majority of internet infrastructure.
• Root login often enabled: Many Linux distributions ship with root login enabled over SSH by default. A successful brute force against the root account gives the attacker complete control of the machine—no privilege escalation needed.
• Password authentication is the default: Despite years of best-practice recommendations, a large number of SSH servers still accept password authentication. Key-based auth requires deliberate configuration.
• Easy to scan for: Port 22 responds to TCP SYN probes with a distinctive banner (e.g., SSH-2.0-OpenSSH_8.9p1), making it trivial to identify SSH servers and even determine the exact software version.
• Direct shell access: Unlike a VPN portal that provides network access, SSH gives direct command-line access to the server. One compromised SSH credential can mean full control of the machine immediately.

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. At thousands of attempts per hour, this creates measurable CPU load—particularly on smaller instances or IoT devices with limited resources. Some organizations report SSH brute force traffic consuming 5-15% of CPU on their servers during sustained campaigns.

Log Flooding

Every failed SSH login generates entries in /var/log/auth.log (or /var/log/secure on RHEL-based systems). During a sustained attack, these logs can grow by hundreds of megabytes per day, filling disk space and making it difficult to find legitimate authentication events. Log aggregation services charge by volume, so this also has a direct cost impact.

Fail2ban Overhead

Many administrators deploy Fail2ban to reactively ban IPs after failed login attempts. While effective against small-scale attacks, Fail2ban struggles at scale. It must parse every log entry in real time, maintain a database of banned IPs, and issue iptables or nftables commands for each ban. When facing thousands of unique attacker IPs per day, Fail2ban itself becomes a performance bottleneck, and the iptables chain grows to thousands of entries, slowing packet processing for all traffic.

Lateral Movement Risk

If an attacker does compromise one server via SSH, the damage rarely stops there. SSH keys stored on the compromised server often grant access to other machines. Internal networks typically have weaker SSH security than perimeter servers, enabling rapid lateral movement. A single compromised SSH server can lead to a full infrastructure breach within hours.

Solutions Ranked by Deployment Speed

Here are the most effective SSH brute force defenses, ranked by how quickly you can deploy them:

1. IP Blocklist (5 Minutes)

The fastest solution. An IP blocklist configured as an External Dynamic List (EDL) on your firewall blocks known SSH attackers at the network perimeter, before malicious traffic ever reaches your SSH daemon. The attacker’s TCP SYN packet is dropped at the firewall—your server never even sees the connection attempt.

ThreatListPro provides a curated blocklist of IP addresses actively engaged in SSH brute force attacks. You paste the URL into your firewall’s EDL configuration, bind it to a deny rule targeting port 22, and commit. Total deployment time: under 5 minutes. The blocklist updates automatically, so newly identified attacker IPs are blocked without any ongoing effort from your team.

2. Key-Based Authentication (30 Minutes)

Disabling password authentication and requiring SSH keys is the single most effective long-term hardening measure. With password auth disabled, brute force attacks become impossible—there is no password to guess. The attacker’s connection is rejected immediately because the server does not offer the password authentication method.

To deploy: generate SSH key pairs for all users, distribute public keys to servers (via ssh-copy-id or configuration management), then set PasswordAuthentication no and ChallengeResponseAuthentication no in /etc/ssh/sshd_config. For a single server with a few users, this takes about 30 minutes. For larger environments with many servers and users, plan for a phased rollout.

3. Change SSH Port (5 Minutes)

Moving SSH from port 22 to a non-standard port (e.g., 2222, 8022, or a random high port) dramatically reduces automated scanning noise. Most brute force bots only scan the default port 22. Changing the port can reduce failed login attempts by 90% or more overnight.

4. Fail2ban (1 Hour)

Fail2ban monitors SSH authentication logs and automatically bans IPs that exceed a configured number of failed login attempts within a time window. It is effective against low-volume attacks from individual IPs but struggles against distributed botnets that rotate through thousands of IPs, each making only a few attempts.

Configuration takes about an hour to install, tune the ban thresholds, set up email alerts, and test. The main limitation is that Fail2ban is reactive—each attacker IP must be allowed to fail multiple times before being banned, and the ban is temporary by default. It also adds processing overhead as the banned IP list grows.

5. SSH Certificate Authority (Days)

The enterprise-grade solution. Instead of managing individual SSH keys across servers, you deploy an SSH Certificate Authority (CA) that signs short-lived certificates for users. Servers trust the CA, and users authenticate with certificates that expire after hours or days. This eliminates key sprawl, simplifies revocation, and makes brute force impossible.

Tools like HashiCorp Vault, Teleport, and Smallstep handle SSH certificate issuance. Deployment typically takes days to weeks, as it requires setting up the CA infrastructure, integrating with your identity provider, configuring all servers to trust the CA, and rolling out certificate-based workflows to users.

Why Firewall-Level Blocking Is the First Step

Every solution above has its place. But the critical insight is where you block the attack. Fail2ban blocks at the host level—after the SSH daemon has already processed the connection. Key-based auth rejects invalid credentials—after the SSH handshake has completed. Port changes reduce noise but do not stop targeted attacks.

Firewall-level IP blocking stops attacks at the network perimeter, before a single packet reaches your server. This is the most efficient approach because:

• Zero server load: Blocked traffic never reaches your SSH daemon, consuming no CPU, memory, or disk I/O on your servers
• No log flooding: Connections dropped at the firewall do not generate entries in your SSH authentication logs
• Immediate protection: Deploy in 5 minutes, not hours or days. No SSH configuration changes, no software installation, no user impact
• Complements every other solution: Blocklists work alongside key-based auth, Fail2ban, and port changes. There is no conflict
• Handles botnet scale: Unlike Fail2ban, an EDL-based blocklist preemptively blocks known attacker IPs before they send a single packet, even if they rotate through thousands of addresses

An IP blocklist is not a replacement for key-based authentication. You should absolutely disable password auth as a long-term measure. But a blocklist gives you immediate, zero-effort protection while you plan and execute that hardening project across your infrastructure.