SSH Brute Force Attacks: How They Work, How to Detect Them and How to Stop Them

Key takeaways

• Key-based login with passwords disabled removes the attack, because there is no password to guess.
• Failed password lines in /var/log/auth.log or /var/log/secure show an attack; a success after many failures is urgent.
• Fail2ban, ufw limit and firewall source restrictions cut the noise; changing the port alone is not a defence.
• Test password strength only on machines you own or have written permission to test; unauthorised attempts are an offence under India's IT Act.

This page covers what a system administrator or student needs: how SSH brute force works, how to see it in your logs, and how to stop it. SSH does not let anyone log in "without having to know any passwords", and Metasploit's Meterpreter is a post-exploitation payload, not a password guesser.

Legal note. Guessing passwords against a server you do not own or have written permission to test is unauthorised access under India's IT Act, 2000. Practise only against virtual machines you control, such as your own Linux VM or Metasploitable on a host-only network.

How does SSH brute force work?

An attacker, usually a script, tries many username and password pairs against the SSH service on port 22. Two variants are common:

• Brute force: tries every combination, which is slow and only works against short passwords.
• Dictionary or credential stuffing: tries common passwords such as "admin123", or passwords leaked from other sites. This is far more successful, because people reuse weak passwords.

Any server with SSH open to the internet is scanned within hours of going online. It is background noise, not a sign that you were targeted. Whether it becomes a breach depends only on whether you allow password logins and whether any password is weak.

What does an attack look like in your logs?

Each failed attempt writes a line to the authentication log. On Debian and Ubuntu that is /var/log/auth.log; on RHEL, Rocky and AlmaLinux it is /var/log/secure; on systemd systems you can also use journalctl.

Failed password for invalid user admin from 203.0.113.45 port 51522 ssh2
Failed password for root from 203.0.113.45 port 51530 ssh2
Invalid user test from 203.0.113.45 port 51536

Signs of brute force: many failures within seconds, from one or a few addresses, for many different usernames. Useful commands:

# count failures per source IP (Debian/Ubuntu)
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

# on RHEL-family systems
sudo grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

# recent failed logins
sudo lastb | head

A success line after many failures from the same address ("Accepted password for...") is the most serious signal. Investigate it immediately.

How to protect SSH, in order of impact

1. Turn off password login and use keys

This removes the attack entirely, because there is no password to guess. Create a key pair on your own machine and copy the public key to the server:

ssh-keygen -t ed25519
ssh-copy-id user@your-server

Protect the private key with a passphrase. Confirm that key login works in a second terminal before disabling passwords, otherwise you can lock yourself out.

2. Harden sshd_config

Edit /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers alice bob

Test the syntax with sudo sshd -t, then reload the service (sudo systemctl reload ssh on Debian and Ubuntu, sudo systemctl reload sshd on RHEL-family). Keep your current session open until you have confirmed a new login works. The options are documented in the OpenSSH manual.

3. Rate-limit and ban repeat offenders

Fail2ban reads the log and bans an address after repeated failures. A minimal /etc/fail2ban/jail.local:

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

Check it with sudo fail2ban-client status sshd. On Ubuntu with ufw, sudo ufw limit 22/tcp temporarily blocks addresses that open too many connections in a short time. Be careful with long bans if you are behind a shared NAT, since one bad user can lock out a whole office.

4. Limit who can reach SSH

Allow port 22 only from your office or VPN addresses using the firewall, or put SSH behind a VPN or a bastion host. A server that does not answer the internet cannot be brute-forced from it. In a cloud account, do the same with a security group.

5. Add a second factor for important servers

You can require a time-based one-time code in addition to the key, using PAM modules such as Google Authenticator's PAM module. Read the module documentation carefully and test with a spare session.

6. Keep it patched and monitored

Update OpenSSH with the system. Send authentication logs to a central place or a SIEM and alert on spikes of failures or a success after many failures.

What about changing the port?

Moving SSH to a different port cuts log noise because simple scripts only try 22. It does not stop a determined attacker, who can scan all ports. Treat it as a minor convenience and do not count it as a defence.

What about Windows servers?

The same principle applies, and on Windows the more common target is Remote Desktop (RDP) rather than SSH. Use a strong password policy and an account lockout policy, require multi-factor authentication, keep RDP off the public internet and reach it through a VPN or gateway, and watch for repeated failed logons (Event ID 4625) in the Security log. If you do enable OpenSSH on Windows, apply the same sshd_config rules above.

How do professionals test this legally?

In an authorised assessment, a tester checks whether a service allows weak passwords and whether lockout or detection works. Tools used for this include Hydra, Medusa and Metasploit's auxiliary SSH login scanner. Used correctly it means a small, agreed wordlist, a defined scope and a time window, with the client's monitoring team told in advance. The output that matters is not "we got in", it is "your logs showed it, and fail2ban banned us after five tries" or "nothing alerted". To practise, run your own SSH VM, point a scan at it from a second VM on a host-only network, and then read your own logs the way the section above describes.

Common mistakes

• Leaving password login on with a short or reused password on any internet-facing server.
• Allowing direct root login.
• Using the default cloud username and a weak password on a test server that later becomes real.
• Ignoring the logs because failures are "just bots".
• Disabling passwords before checking that key login works.

Next steps

To learn how defenders and testers work together, WebAsha's VAPT course covers authorised testing from scoping to reporting. Related reading: what the ssh command is and how to use it and Hydra for ethical password testing.