How SSH Brute Force Attacks Work

SSH brute force is one of the most common attack types on the internet. An attacker uses automated tools to repeatedly try username and password combinations against your SSH server (typically port 22), hoping to guess valid credentials.

A typical attack generates hundreds to thousands of login attempts per hour from a single IP address. Attackers use wordlists of common usernames (root, admin, ubuntu, test) combined with dictionaries of leaked passwords. Modern attack tools can distribute attempts across thousands of compromised machines (botnets) to avoid rate limiting.

The attack lifecycle typically follows a pattern: first, a scanner like masscan or ZMap identifies hosts with port 22 open across wide IP ranges. Next, dedicated brute-force tools such as Hydra, Medusa, or Patator are aimed at those targets. If a login succeeds, the attacker installs backdoors, cryptocurrency miners, or recruits the server into a botnet for further attacks. The entire chain from initial scan to compromise can happen in under a minute for servers with weak credentials.

What Does It Mean When an IP Is Flagged?

When WAYSCloud flags an IP for SSH brute force activity, it means one or more of our threat intelligence sources have observed that IP making repeated failed SSH login attempts against monitored servers. This could indicate:

Dedicated attack infrastructure — A server specifically set up to scan the internet for vulnerable SSH services. Often hosted on cloud platforms or bulletproof hosting providers that ignore abuse complaints.
Compromised device — A legitimate server or IoT device that has itself been hacked and is now being used as part of a botnet to attack others. The device owner typically has no idea their machine is participating in attacks.
Residential botnet — A home computer or router infected with malware, participating in distributed brute force campaigns without the owner's knowledge. These are harder to block because the IPs belong to legitimate ISPs.
Cloud instance abuse — Cheap or trial VPS instances on platforms like AWS, DigitalOcean, or Hetzner spun up specifically for scanning and brute-force campaigns, then abandoned before abuse reports are processed.

Current SSH Brute Force Activity

In the last 24 hours, WAYSCloud has detected SSH brute force attempts from approximately 97 unique IP addresses.

Our network of fail2ban reporters and threat intelligence feeds continuously monitor for SSH attacks in real time. Each flagged IP has been independently observed making unauthorized login attempts.

View today's most reported attacking IPs →

How to Detect SSH Brute Force in Your Logs

Check your SSH authentication logs:

# Linux - check auth log
grep "Failed password" /var/log/auth.log | tail -20

# Count failed attempts per IP
grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

# Check for "Invalid user" attempts (dictionary attack)
grep "Invalid user" /var/log/auth.log | tail -20

# On RHEL/CentOS, use /var/log/secure instead
grep "Failed password" /var/log/secure | tail -20

Signs of an active brute force attack:

Hundreds of "Failed password" entries from the same IP in minutes
"Invalid user" entries with common usernames (root, admin, test, oracle, postgres, pi)
Login attempts at unusual hours or from unexpected countries
Multiple IPs trying the same username in quick succession (coordinated attack)
Sudden spike in sshd process count or system load

How to Block SSH Brute Force Attacks

1. Use fail2ban (recommended first step)

fail2ban monitors your SSH logs and automatically bans IPs after a configurable number of failed attempts:

# Install on Debian/Ubuntu
sudo apt install fail2ban

# Enable SSH jail
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Check banned IPs
sudo fail2ban-client status sshd

# View currently banned count
sudo fail2ban-client status sshd | grep "Currently banned"

The default configuration bans an IP for 10 minutes after 5 failed attempts. For production servers, consider increasing the ban time and reducing the threshold. fail2ban can also be configured to report banned IPs to WAYSCloud, contributing to the shared threat intelligence network.

2. Use SSH key authentication (disable passwords entirely)

The most effective prevention — if password authentication is disabled, brute force becomes impossible regardless of how many attempts are made:

# In /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no

# Then reload SSH
sudo systemctl reload sshd

Before disabling password authentication, make sure you have a working SSH key pair configured and tested. Losing access to a server because you locked yourself out is a common mistake.

3. Change the default SSH port

Moving SSH to a non-standard port reduces automated scanning traffic by over 95%. While this is not a security measure by itself (determined attackers will port-scan), it eliminates the vast majority of opportunistic bots:

# In /etc/ssh/sshd_config:
Port 2222   # Pick any unused port above 1024

# Then reload SSH (keep your current session open!)
sudo systemctl reload sshd

# Connect with: ssh -p 2222 user@host

4. Use the WAYSCloud API for proactive blocking

Block known malicious IPs before they even attempt to log in:

# Check if an IP is known for SSH brute force
curl -s https://ip.wayscloud.services/api/v1/ip/185.220.101.1 | jq '.intelligence_data.categories'

# Quick bash script to block top threats
#!/bin/bash
for ip in $(curl -s https://ip.wayscloud.services/api/threats/live?limit=100 \
  | jq -r '.threats[].ip_address'); do
    iptables -A INPUT -s "$ip" -j DROP
done

# See the full integration guide:
# https://ip.wayscloud.services/integrate

Why SSH Brute Force Persists

Despite being one of the oldest attack types on the internet, SSH brute force remains remarkably effective because:

Default credentials — Many servers ship with password authentication enabled and weak default passwords. IoT devices, NAS boxes, and router firmware are especially prone to this. A surprising number of production servers still allow root login with common passwords.
Scale — Attackers scan the entire IPv4 address space (4.3 billion addresses) in hours using tools like masscan. At that scale, even a 0.001% success rate yields thousands of compromised machines.
Low cost — Compromised machines and cheap VPS providers make attack infrastructure nearly free. A $5/month VPS can launch thousands of brute force attempts per day before being shut down.
Automation — Tools like Hydra, Medusa, and custom Python/Go scripts automate the entire process from scanning to credential stuffing to post-exploitation.
Credential leaks — Billions of username/password combinations from data breaches are freely available, and many people reuse passwords across services including SSH.

Recommended Security Checklist

If you manage servers with SSH access, verify each of these:

SSH key authentication enabled, password authentication disabled
Root login disabled or restricted to key-only
fail2ban or similar intrusion prevention system installed and active
SSH port changed from default 22 (optional but effective against automated scans)
Firewall rules limiting SSH access to known IP ranges where possible
Regular review of /var/log/auth.log for unusual patterns
Threat intelligence feed integration for proactive IP blocking

What is SSH Brute Force?