Could Your SSH Service Withstand Password Spraying?
Every Linux administrator enables SSH because it is the fastest and most secure way to manage remote systems. However, the same service is also one of the most targeted attack surfaces on the Internet.
Unlike traditional brute-force attacks that repeatedly try many passwords against a single account, password spraying is much stealthier. Attackers test a small number of common passwords across hundreds or thousands of usernames, making it much harder to detect and often avoiding account lockout policies.
The question is simple:
If someone started password spraying your SSH server today, would it survive?
In this guide, you'll learn how password spraying works, how attackers perform it, how to detect it, and the best ways to secure your Linux server.
What Is Password Spraying?
Password spraying is a cyberattack where an attacker tries one common password against many user accounts instead of trying many passwords against one account.
Example
Instead of:
- admin
- 123456
- password
- admin123
Against one user:
atul
The attacker tries:
- atul : Welcome@123
- john : Welcome@123
- root : Welcome@123
- ubuntu : Welcome@123
- developer : Welcome@123
Then waits several hours before trying another common password.
Because login attempts are spread across multiple accounts, many security systems fail to recognize the attack.
Why Attackers Love SSH?
SSH is usually exposed on:
- Cloud VPS
- AWS EC2
- Azure Virtual Machines
- Google Cloud
- DigitalOcean
- Home Labs
- Raspberry Pi
- Enterprise Linux Servers
If password authentication is enabled, attackers continuously scan the Internet looking for SSH services.
Popular targets include:
- Ubuntu
- Debian
- Kali Linux
- CentOS
- Rocky Linux
- AlmaLinux
How Password Spraying Works
If any account uses that password, the attacker gains access.
Signs Your SSH Server Is Under Attack
Common symptoms include:
- Numerous failed SSH login attempts
- Authentication failures from multiple IP addresses
- Repeated attempts targeting many usernames
- High activity in SSH logs
- Unexpected CPU spikes due to authentication processing
Check SSH Logs
- Ubuntu/Debian
- sudo cat /var/log/auth.log
CentOS/RHEL
- sudo cat /var/log/secure
- Search for failed logins:
- grep "Failed password" /var/log/auth.log
Example:
- Failed password for invalid user admin
- Failed password for root
- Failed password for ubuntu
- Failed password for developer
This pattern often indicates automated attacks.
View Failed SSH Attempts
Count failed logins:
- grep "Failed password" /var/log/auth.log | wc -l
Find attacking IPs:
- grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr
How to Protect SSH
1. Disable Password Authentication
SSH keys are significantly more secure than passwords.
Edit:
- sudo nano /etc/ssh/sshd_config
Set:
- PasswordAuthentication no
- PubkeyAuthentication yes
Restart SSH:
- sudo systemctl restart ssh
2. Disable Root Login
Never allow direct root logins.
- PermitRootLogin no
3. Use Strong SSH Keys
Generate an Ed25519 key:
- ssh-keygen -t ed25519
Copy it to the server:
- ssh-copy-id user@server-ip
4. Change the Default SSH Port
Although changing the default port won't stop determined attackers, it reduces noise from automated bots.
Example:
- Port 2222
Remember to update your firewall rules accordingly.
5. Install Fail2Ban
Install:
Ubuntu
- sudo apt install fail2ban
Start service:
- sudo systemctl enable fail2ban
- sudo systemctl start fail2ban
Check status:
- sudo fail2ban-client status sshd
Fail2Ban blocks IP addresses after repeated failed login attempts.
6. Enable Two-Factor Authentication
Even if a password is compromised, MFA can prevent unauthorized access.
Popular options:
- Google Authenticator
- Authy
- Duo Security
7. Restrict Users
Limit SSH access to specific users.
- AllowUsers atul admin
8. Use a Firewall
With UFW:
- sudo ufw allow 22/tcp
- sudo ufw enable
For a custom SSH port:
- sudo ufw allow 2222/tcp
9. Monitor Login Attempts
View active sessions:
- who
Recent logins:
- last
Current SSH connections:
- ss -tnp | grep ssh
10. Keep OpenSSH Updated
Update packages regularly:
Ubuntu
- sudo apt update
- sudo apt upgrade
Kali
- sudo apt full-upgrade
Common Mistakes
Avoid these risky configurations:
- ❌ Weak passwords
- ❌ Root login enabled
- ❌ Password authentication enabled
- ❌ No firewall
- ❌ No monitoring
- ❌ Ignoring SSH logs
- ❌ Not updating openSSH
Security Hardening Checklist
- Disable root login
- Disable password authentication
- Use SSH keys
- Install Fail2Ban
- Enable MFA
- Restrict SSH users
- Change the default port (optional)
- Monitor logs regularly
- Keep OpenSSH updated
- Back up SSH configuration before changes
Final Thoughts
Password spraying remains one of the most effective techniques attackers use against exposed SSH services because it exploits weak password practices rather than software vulnerabilities.
A secure SSH configuration should rely on public key authentication, strong account policies, monitoring, and defense-in-depth controls such as Fail2Ban, firewalls, and multi-factor authentication. Regularly reviewing authentication logs and keeping OpenSSH up to date significantly reduces the risk of compromise.
If your server is still using password-based SSH authentication, now is the time to harden it before attackers find it.
Frequently Asked Questions (FAQ)
Q1. What is SSH password spraying?
- It is an attack where a single common password is tested against many different user accounts instead of trying many passwords on one account.
Q2. Is password spraying the same as brute force?
- No. Brute-force attacks target one account with many passwords, while password spraying targets many accounts with a small set of common passwords.
Q3. Can Fail2Ban stop password spraying?
- Fail2Ban helps block repeated failed login attempts from the same IP address, but it should be combined with SSH keys, MFA, and proper monitoring for stronger protection.
Q4. Should I disable SSH password authentication?
- Yes. Using SSH key-based authentication instead of passwords is one of the most effective ways to protect SSH access.
Q5. Does changing the SSH port improve security?
- Changing the default port can reduce automated scanning and log noise, but it should not be considered a replacement for proper authentication and server hardening.
