How to stop SSH brute force attacks

Check whether you are being attacked

The SSH daemon logs every failed attempt. Count the last 24 hours, then see which addresses send the most:

sudo journalctl --since "24 hours ago" | grep -cE "Failed password|Invalid user"

sudo journalctl --since "24 hours ago" \
  | grep -E "Failed password|Invalid user" \
  | grep -oE "from [0-9a-fA-F.:]+ port" | awk '{print $2}' \
  | sort | uniq -c | sort -rn | head -20

Hundreds or thousands of lines a day is normal for a server on a public IP. If the journal is not kept between reboots, the same lines are in /var/log/auth.log on Debian and Ubuntu and in /var/log/secure on the RHEL family.

Set up SSH keys and test them first

Everything that follows turns passwords off, so a working key comes first. On your own computer, create a key, copy it to the server and log in with it. Replace deploy with your user and SERVER_IP with the server's address.

ssh-keygen -t ed25519 -C "laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@SERVER_IP
ssh -i ~/.ssh/id_ed25519 deploy@SERVER_IP

The last command must log you in without asking for the account's password (it may ask for the key's passphrase, which stays on your computer).

Create a sudo user before disabling root

If you log in as root today, create a normal user with sudo rights first, and give it the same keys.

sudo adduser deploy
sudo usermod -aG sudo deploy

sudo useradd -m deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

sudo mkdir -p /home/deploy/.ssh
sudo cp /root/.ssh/authorized_keys /home/deploy/.ssh/
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

sudo restorecon -R /home/deploy/.ssh

From the second terminal, log in as the new user and run sudo -v: it must accept the user's password. Only then go on.

Disable password login and root login

Current Debian, Ubuntu, RHEL 9 family and Fedora read extra files from /etc/ssh/sshd_config.d/. Check that yours does:

grep -i '^Include' /etc/ssh/sshd_config

If it prints Include /etc/ssh/sshd_config.d/*.conf, write the settings in a file of their own. SSH keeps the first value it reads for each setting, and the files are read in name order, so the 00- prefix wins over files such as 50-cloud-init.conf, which on some cloud images turns passwords back on.

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 4
LoginGraceTime 30
EOF

If there is no Include line (RHEL 8 and its rebuilds), set the same six lines in /etc/ssh/sshd_config itself, replacing the existing ones. Then test the configuration and look at the values SSH will actually use:

sudo sshd -t && echo "config OK"
sudo sshd -T | grep -Ei '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin|maxauthtries) '

Each line must show the value you set. If root still has to log in with a key, for a backup job for example, use PermitRootLogin prohibit-password instead of no. Reload SSH: open sessions stay connected.

sudo systemctl reload ssh

sudo systemctl reload sshd

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password deploy@SERVER_IP

Change the SSH port, knowing what it does not do

Moving SSH off port 22 cuts the noise in the logs, because most bots only try 22. It does not make SSH safer: port scanners find a new port within hours, and a targeted attacker finds it at once. With key-only login the port does not matter much. Do it for cleaner logs, not for security, and only after the steps above.

Pick a port (2222 here), open it in the firewall and, on the RHEL family, tell SELinux that SSH may use it:

sudo ufw allow 2222/tcp

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

Open the port in your provider's cloud firewall or security group too. Then set the port and restart SSH:

echo "Port 2222" | sudo tee /etc/ssh/sshd_config.d/01-port.conf
sudo sshd -t && echo "config OK"

On Ubuntu 24.04 and later SSH can be started by ssh.socket: if the first command below prints active, run all four lines; otherwise only the last one.

systemctl is-active ssh.socket
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo systemctl restart ssh

sudo systemctl restart sshd

ssh -p 2222 deploy@SERVER_IP

Ban repeat offenders with fail2ban or sshguard

With passwords off, guesses cannot succeed, but banning the addresses that keep trying cuts the load and the noise. fail2ban reads the log and bans an address at the firewall after a number of failures.

sudo apt update
sudo apt install -y fail2ban python3-systemd

sudo dnf install -y epel-release
sudo dnf install -y fail2ban

On RHEL itself and Oracle Linux, enable EPEL as their documentation says, then install fail2ban. On Fedora it is in the main repositories. Amazon Linux 2023 cannot use EPEL: use the firewall rate limit below instead.

Settings go in jail.local, never in jail.conf, which updates overwrite. Check that you do not have one already, then create it. Replace YOUR_OFFICE_IP with the fixed addresses you work from, or delete it, and set port to your SSH port if you changed it.

ls -l /etc/fail2ban/jail.local

sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 YOUR_OFFICE_IP
bantime = 1h
bantime.increment = true
findtime = 10m
maxretry = 5

[sshd]
enabled = true
backend = systemd
port = ssh
EOF

This bans an address for one hour after 5 failures in 10 minutes, and for longer each time it comes back. backend = systemd reads the journal, which works on Debian 12 and later where /var/log/auth.log may not exist.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Under attack, Total failed and Currently banned grow within minutes. If Total failed stays at 0 while the journal shows failed logins, the jail is not reading the right log. To lift a ban:

sudo fail2ban-client set sshd unbanip 203.0.113.7

sshguard, the lighter alternative

sshguard does the same job with less configuration and is packaged for Debian and Ubuntu (and in EPEL). Put your own addresses in its whitelist first, then watch sudo journalctl -u sshguard -f during an attack to see the blocks. Use one of the two, not both.

sudo apt install -y sshguard
echo "YOUR_OFFICE_IP" | sudo tee -a /etc/sshguard/whitelist
sudo systemctl restart sshguard

Rate limit or restrict SSH at the firewall

On Ubuntu and Debian with ufw, limit refuses an address that opens 6 or more connections in 30 seconds. It replaces a plain allow 22/tcp rule. If sudo ufw status also shows an OpenSSH rule, delete it once the limit is in place (sudo ufw delete allow OpenSSH): it would match before the limit.

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

firewalld's rich rules have a limit, but it counts all sources together, so an attack can use up the allowance and lock you out too. On the RHEL family, use fail2ban for per-address limits.

Allow SSH only from your addresses

The strongest step, when you work from fixed addresses or a VPN: nobody else can even reach SSH.

sudo ufw allow from YOUR_OFFICE_IP to any port 22 proto tcp
sudo ufw delete limit 22/tcp
sudo ufw status numbered

sudo firewall-cmd --permanent --zone=trusted --add-source=YOUR_OFFICE_IP
sudo firewall-cmd --reload
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --reload

Questions

Is changing the SSH port enough to stop brute force?

No. It cuts the number of attempts in the logs, because most bots only try port 22, but scanners find the new port quickly. Key-only login is what makes the guesses useless.

Should I use fail2ban or sshguard?

Either works for SSH. fail2ban has more filters for other services and more options; sshguard needs less configuration. Run one, not both, so they do not fight over the same addresses.

I disabled passwords and still see failed logins. Is something wrong?

No. Bots keep trying because they do not know passwords are off. The attempts fail before any password is checked. Bans and rate limits reduce the noise.