1. Allowing Password Authentication
If your server allows SSH password login, it will be attacked. Brute-force and credential-stuffing attacks are automated and constant.Why this is dangerous
- Passwords can be brute-forced or reused from leaks
- Credential-stuffing bypasses strong password policies
- Attack noise hides real intrusions
How to fix it
Edit/etc/ssh/sshd_config:
sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication noRestart SSH
sudo systemctl restart sshd2. Enabling Root Login Over SSH
Allowing direct SSH access asroot is one of the fastest ways
to lose a server. A successful login equals full system control.
Why attackers love it
- The username is always known
- No privilege escalation is required
- No accountability trail
How to fix it
sshd_config
PermitRootLogin nosudo instead.
3. Reusing the Same SSH Key Across Multiple Servers
Reusing one SSH key everywhere creates a single point of failure. If one server is compromised, all others become reachable.- One stolen key compromises multiple servers
- No way to revoke access selectively
- No clear ownership of keys
4. Never Rotating SSH Keys
SSH keys often live for years. That means stolen or leaked keys remain valid indefinitely.- Former employees retain access
- Stolen laptops become permanent backdoors
- No security lifecycle for credentials
5. Leaving SSH Open to the Entire Internet
By default, SSH listens on all interfaces. Attackers constantly scan the internet for open SSH ports.Reduce exposure
Ubuntu / Debian (UFW)
sudo ufw enable
sudo ufw allow from <YOUR_TRUSTED_IP> to any port 22 proto tcp
sudo ufw default deny incoming
sudo ufw status verboseRHEL / Rocky / Alma (firewalld)
sudo firewall-cmd --permanent \
--add-rich-rule='rule family="ipv4" source address="<YOUR_TRUSTED_IP>" service name="ssh" accept'
sudo firewall-cmd --reloadVerify If Your SSH Port Is Exposed
Even after applying firewall rules and hardening SSH, it’s important to verify that your server is not unintentionally exposed to the internet. Misconfigurations, cloud security groups, or forgotten rules can still leave port 22 reachable.
A simple way to validate this is by checking your server from the outside, the same way an attacker would.
You can use this public tool to quickly test whether your SSH port is open or reachable:
https://www.singlejump.com/tools/
The tool allows you to verify SSH exposure from an external perspective, helping confirm that firewall rules, IP allowlists, and network policies are actually working as intended.
This kind of external validation should be part of any SSH hardening checklist, especially after configuration changes or infrastructure updates.
6. Relying Only on Logs You Never Check
SSH logs exist, but are often ignored. Logs are reactive—they tell you something happened, not what is happening.Check SSH logs
# Debian / Ubuntu
sudo tail -n 200 /var/log/auth.log
# RHEL-based
sudo tail -n 200 /var/log/secure7. No Visibility Into What Users Actually Do
Traditional SSH logs show authentication events, not the commands executed inside sessions. This lack of visibility makes incident response, auditing, and compliance extremely difficult.8. No Access Revocation Strategy
If a contractor leaves or a key leaks, you must be able to revoke access instantly.- Manual key cleanup does not scale
- Missed servers lead to lingering access
- Access control must be centralized
9. Security Through Obscurity (Changing the SSH Port)
Changing the SSH port reduces noise, but does not stop real attackers. Port changes are fine as a minor improvement, but never as a primary security control.10. Treating SSH as “Just a Tool”
SSH is direct production access. If it isn’t controlled, audited, and revocable, it becomes a critical security liability.Quick SSH Hardening Checklist
- Disable password authentication
- Disable root login
- Restrict SSH access by IP
- Use unique SSH keys
- Rotate keys regularly
- Monitor authentication events
- Ensure session accountability
Leave a Reply