Defeating an SSH Brute Force Flood on Linux Servers

If your authentication logs are filling up with thousands of automated login attempts every second, this guide walks you through defeating an SSH brute force flood on a Linux server—detect, drop, harden, and verify—without guesswork.

This is written for Australian homeowners, small businesses, and sysadmins running Ubuntu or similar VPS/dedicated hosts who need remote, practical server support. Below you get real commands, a quick IP-drop approach, and clear points where DIY stops and specialist help from Fixwebnode Linux server support makes sense. We work remotely across Australia; see all service areas for coverage context.

Why an SSH brute force flood matters on your server

Open SSH on the public internet attracts credential-stuffing bots within minutes. Left alone, floods burn CPU on auth, bloat auth.log/secure, lock out real users after failed-password policies, and raise the chance that a weak account eventually succeeds. The goal is not exotic tooling: identify repeat offenders, drop them at the firewall, rate-limit or ban at the SSH layer, and lock authentication to keys so password guessing becomes useless.

Fixwebnode provides direct remote server support for this exact problem—brute force mitigation, login hardening, and cleanup if something already slipped through—not a freelance marketplace. When logs are noisy or you are unsure whether a ban list is safe, book a conversation via the landing link above or the CTA at the end.

How do I stop SSH brute force attacks flooding my server in Australia?

Watch failed password and invalid-user lines in the auth log, extract repeat source IPs, and drop them with nftables/iptables or fail2ban so packets never reach sshd. Then harden SSH (keys only, limited users, optional non-default port or allow-list) and confirm the flood rate collapses in the logs. If bans break legitimate access, rootkits are suspected, or the host is already compromised, use Fixwebnode for remote mitigation rather than stacking more rules blind.

Common issues during an SSH brute force flood

These problems show up repeatedly on Australian small-business and home-lab servers exposed on port 22. Each has a different root cause.

1. Auth logs saturated by invalid users and failed passwords

Symptoms: journalctl -u ssh or /var/log/auth.log scrolls with Failed password and Invalid user from many IPs; disk use on /var climbs; logrotate cannot keep up during peaks.

2. Real administrators locked out by aggressive bans or pam_tally

Symptoms: Your office or home IP gets banned because it shared a NAT with noisy traffic, or fail2ban/sshd MaxAuthTries locked the account; SSH returns connection refused or permission denied even with the correct key.

3. Password authentication still enabled after “installing fail2ban”

Symptoms: Bots keep trying root/admin passwords; fail2ban jails fire constantly; a weak secondary account remains guessable. The flood is mitigated only partially because the attack surface was never closed.

4. Flood hides a successful break-in or leftover malware

Symptoms: One Accepted password or unexpected Accepted publickey line among noise; new users, odd authorized_keys, or unfamiliar cron entries appear later. Dropping IPs alone does not remove persistence.

Issue 1 — Detect the flood and drop repeat offender IPs

Goal: prove the flood, list top sources, and drop them at the host firewall so sshd stops burning cycles. Prefer fail2ban for ongoing protection; a short one-shot drop helps during an active spike.

Step 1 — Confirm SSH auth noise

sudo journalctl -u ssh -u sshd --since "1 hour ago" | grep -E "Failed password|Invalid user" | tail -n 50
sudo grep -E "Failed password|Invalid user" /var/log/auth.log 2>/dev/null | tail -n 50

You should see repeating source IPs and usernames such as root, admin, ubuntu, or random strings.

Step 2 — Rank the noisiest source IPs

sudo grep -E "Failed password|Invalid user" /var/log/auth.log 2>/dev/null \
 | grep -oE "from [0-9.]+" | awk '{print $2}' \
 | sort | uniq -c | sort -nr | head -n 20

On journald-only hosts:

sudo journalctl -u ssh -u sshd --since "today" --no-pager \
 | grep -E "Failed password|Invalid user" \
 | grep -oE "from [0-9.]+" | awk '{print $2}' \
 | sort | uniq -c | sort -nr | head -n 20

Step 3 — One-shot DROP with nftables (preferred on modern Ubuntu)

Create a dedicated set and add the worst offenders (replace example IPs with yours). Do not ban your own public IP.

sudo nft add table inet ssh_guard 2>/dev/null || true
sudo nft add set inet ssh_guard brute_ipv4 '{ type ipv4_addr; flags interval; }' 2>/dev/null || true
sudo nft add chain inet ssh_guard input '{ type filter hook input priority 0; policy accept; }' 2>/dev/null || true
sudo nft add rule inet ssh_guard input ip saddr @brute_ipv4 tcp dport 22 drop 2>/dev/null || true
sudo nft add element inet ssh_guard brute_ipv4 '{ 203.0.113.10, 198.51.100.25 }'
sudo nft list set inet ssh_guard brute_ipv4

Step 4 — Equivalent one-shot DROP with iptables + ipset

sudo apt-get update && sudo apt-get install -y ipset
sudo ipset create ssh_brute hash:ip timeout 86400 -exist
sudo iptables -C INPUT -m set --match-set ssh_brute src -j DROP 2>/dev/null \
 || sudo iptables -I INPUT -m set --match-set ssh_brute src -j DROP
sudo ipset add ssh_brute 203.0.113.10 -exist
sudo ipset add ssh_brute 198.51.100.25 -exist
sudo ipset list ssh_brute

Step 5 — Install and enable fail2ban for continuous bans

sudo apt-get update && sudo apt-get install -y fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo tee /etc/fail2ban/jail.d/sshd.local >/dev/null <<'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 4
findtime = 10m
bantime = 1h
ignoreip = 127.0.0.1/8 ::1
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Add your static admin IP to ignoreip before enabling aggressive bans. Verify with sudo fail2ban-client status sshd that the jail is active and banned IP count rises during the flood.

When to call Fixwebnode: cloud security groups or provider firewalls sit in front of the VM and host rules never see the traffic; or you need coordinated remote changes without risking lockout. Use Brute Force Attack Mitigation & Login Hardening Australia for that path.

Issue 2 — Recover access when bans lock out the real admin

Root cause is usually your public IP landing in a ban set, or sshd/PAM rejecting after too many failures—not “SSH is broken.”

Step 1 — Use provider console or serial/VNC

Open the hosting panel console (not SSH). Log in locally so firewall and fail2ban state can be fixed without the network path.

Step 2 — Unban your IP in fail2ban

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip YOUR.PUBLIC.IP.HERE
sudo fail2ban-client set sshd addignoreip YOUR.PUBLIC.IP.HERE

Step 3 — Remove a mistaken nft/ipset ban

sudo nft delete element inet ssh_guard brute_ipv4 '{ YOUR.PUBLIC.IP.HERE }'
# or
sudo ipset del ssh_brute YOUR.PUBLIC.IP.HERE

Step 4 — Confirm sshd is listening and allow your IP temporarily

sudo ss -tlnp | grep -E ':22|:2222'
sudo nft add element inet filter allow_admin '{ YOUR.PUBLIC.IP.HERE }' 2>/dev/null || true

If you use UFW:

sudo ufw status verbose
sudo ufw allow from YOUR.PUBLIC.IP.HERE to any port 22 proto tcp
sudo ufw reload

Step 5 — Test from a second session before closing console

ssh -v youruser@YOUR.SERVER.IP

Keep the console open until a new SSH session succeeds. Soften bantime or raise maxretry only after ignoreip is correct.

When to call Fixwebnode: no console, panel locked, or the only access path is the same SSH you just banned. Remote recovery is safer than guessing firewall rules over a half-dead link.

Issue 3 — Harden sshd so password floods stop mattering

Dropping IPs reduces noise; disabling password authentication removes the prize. Do this only after key-based login works from your admin machine.

Step 1 — Install your public key (from your laptop)

ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@YOUR.SERVER.IP
ssh youruser@YOUR.SERVER.IP 'echo key-ok'

Step 2 — Edit sshd_config safely

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
AllowUsers youruser
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2
EOF

Replace youruser with the real account. If you must keep a break-glass password user temporarily, do not set PasswordAuthentication no until keys are proven.

Step 3 — Validate config and reload

sudo sshd -t && sudo systemctl reload ssh || sudo systemctl reload sshd

Step 4 — Verify password auth is rejected

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no youruser@YOUR.SERVER.IP

That attempt should fail immediately. A normal key login should still work in another terminal.

Step 5 — Optional rate limit at sshd (with care)

On hosts that support it, pair fail2ban with cloud allow-lists rather than exotic Match blocks you cannot reverse. Prefer firewall rate limits you understand:

# nft example: limit new SSH handshakes per IP
sudo nft add rule inet filter input tcp dport 22 ct state new limit rate 10/minute accept

Test thoroughly; overly tight limits can block CI or multiple jump-host users.

When to call Fixwebnode: managed panels (Plesk, cPanel, custom images) overwrite sshd snippets, or several staff keys need controlled rollout. Hardening plus ongoing ban policy is covered under the same brute-force mitigation service link above.

Issue 4 — After the flood: check you were not already breached

IP drops do not undo a successful login. Treat any unexpected “Accepted” line as incident response, not housekeeping.

Step 1 — Search for successful authentications

sudo grep -E "Accepted password|Accepted publickey" /var/log/auth.log 2>/dev/null | tail -n 100
sudo journalctl -u ssh -u sshd --since "7 days ago" | grep -E "Accepted password|Accepted publickey"

Step 2 — Review users, sudo, and SSH keys

getent passwd | awk -F: '$3>=1000 || $1=="root" {print}'
sudo grep -E '^[^#].*ALL' /etc/sudoers /etc/sudoers.d/* 2>/dev/null
sudo find /home /root -name authorized_keys -type f -exec ls -la {} \; -exec echo '---' \; -exec cat {} \;

Step 3 — Inspect persistence points

sudo crontab -l; sudo ls -la /etc/cron.*
systemctl list-units --type=service --state=running
ls -la /etc/systemd/system /lib/systemd/system | head
sudo ss -tulnp

Step 4 — If anything looks wrong

Isolate the host (provider firewall deny-all except your admin IP), preserve logs, rotate credentials from a clean machine, and do not “just reinstall fail2ban” over a compromised box. For hidden backdoors and malicious cron cleanup, use Hidden Backdoor & Malicious Cron Job Disinfection Australia.

When to call Fixwebnode: unknown keys, unexplained listeners, modified sshd binaries, or cron entries you did not create. That is specialist incident work, not a weekend firewall tweak.

Quick verification checklist after mitigation

1. fail2ban sshd jail shows bans: sudo fail2ban-client status sshd
2. Top failed-IP list shrinks over the next hour (re-run the uniq -c pipeline).
3. sshd -t is clean; key login works; password login fails.
4. No unexpected Accepted lines since hardening.
5. Your admin IP is on ignore/allow lists so you are not locked out overnight.

sudo fail2ban-client status sshd
sudo journalctl -u ssh -u sshd --since "10 min ago" | grep -cE "Failed password|Invalid user" || true
sudo sshd -t && echo "sshd config OK"

When DIY is enough vs when to book Fixwebnode

DIY is enough when you still have console or working key access, the flood is pure noise with no Accepted logins, and you can install fail2ban, drop a short IP list, and turn off password authentication safely.

Book Fixwebnode when lockouts block all remote entry, provider edge rules conflict with host firewalls, multiple servers need the same hardening, logs suggest a successful intrusion, or you want a remote specialist to implement ban policy and login hardening without trial-and-error on a live production host. Fixwebnode is a direct provider for Australian server support—remote-first—not a place to post projects or collect bids.

Geography is Australia-wide remote work; details sit on the service areas page. For Ubuntu and general Linux break-fix work tied to this class of outage, start from the Linux support landing linked below.

Talk to Fixwebnode about your SSH flood

If authentication logs are still screaming, bans are unstable, or you need hardened SSH rolled out cleanly on production hosts, start a conversation with Fixwebnode. Bring a redacted snippet of failed-login lines and whether you have provider console access—that shortens diagnosis.

Next step: open Fixwebnode Ubuntu Linux server support and book a remote session focused on defeating the SSH brute force flood, locking down logins, and confirming the host is clean afterward. For dedicated mitigation, use Brute Force Attack Mitigation & Login Hardening Australia; if persistence is suspected, pair it with backdoor and malicious cron disinfection.

Stop the flood at the firewall, close password guessing at sshd, verify the logs go quiet, and escalate early if anything looks like a successful break-in. That is the complete, practical path to defeating an SSH brute force flood on your server.