← Blog · May 23, 2026 · ssh, security
What's a Safe SSH Port to Use in 2026?
Short answer — port 22 is still safe if you disable password auth, use SSH keys (Ed25519 preferred), and run fail2ban. Moving to a non-standard high port (anywhere in 49152–65535, or simple favorites like 2222, 22022, 22222) is security theater at best — but it is good hygiene because it removes 99%+ of automated bot noise from your auth log.
The numbers from a real internet-facing box
A 30-day sample from a single VPS in Frankfurt with sshd on port 22:
- ~412,000 failed login attempts
- ~38,000 unique source IPs
- ~99.3% from automated scanners (Mirai variants, generic brute-force botnets)
- 0 successful logins from those attempts (key-only auth)
Move the same sshd to port 22222. Same 30 days:
- ~1,100 failed attempts
- ~80 unique IPs (almost all from shodan-style scanners that probe full port ranges)
- 0 successful
Same security outcome. Two orders of magnitude less log noise. That is the entire case for changing the port.
Picking a port
| Range | Use? | Why |
|---|---|---|
| 0–1023 (well-known) | Avoid | Reserved for system services. Already mapped (port 80, 443, 25, etc). |
| 1024–49151 (registered) | OK, with care | Many assigned to specific apps. Avoid common ones (3306 MySQL, 5432 Postgres, 6379 Redis, 8080 HTTP-alt). |
| 49152–65535 (ephemeral / dynamic) | Recommended | Free-for-all range. Bots rarely scan up here unless specifically looking for hidden SSH. |
| 2222 | Don't | The most-scanned alternate SSH port on the entire internet. Worse than 22 in terms of noise-per-bot. |
| 22222, 22022 | Marginal | Still in the common "double the digits" list. Better than 22 but not by much. |
For a real example, 54321, 61234, or 50000 are all fine. Pick something memorable to your team and put it in a password manager.
The hardening that actually matters
Changing the port is item #5 on the list, not item #1.
- Disable password auth. In
/etc/ssh/sshd_config:PasswordAuthentication noandPermitRootLogin prohibit-password. This single change defeats every brute-force botnet on the planet. - Use Ed25519 keys.
ssh-keygen -t ed25519. Smaller, faster, and not vulnerable to the same weaknesses as RSA-1024. - Install fail2ban. Bans IPs after N failed attempts. Default is 5 retries → 10 min ban. Aggressive admins set 3 retries → 24 hr ban.
- Use a firewall. If you can scope SSH to specific source IPs (VPN, office, jump host), do that and you can leave port 22 alone.
- Then, if you want — change the port. Drop the log noise. That's the actual benefit.
Things people get wrong
"A non-standard port is more secure." No. nmap finds open SSH on any port in under 5 seconds. A targeted attacker doesn't care what port you're on. Only automated mass scanners do, and those don't threaten a well-configured server anyway.
"Ports above 1024 don't require root." True — and that's actually a downside. If sshd ever crashes and respawns on a non-privileged port, any local user could in principle bind a fake sshd to it. Use a port > 1024 but also harden init/systemd so only the sshd unit can bind it.
"I should also rate-limit at the firewall." Yes. iptables or nftables limit rules + fail2ban + key-only auth = belt, suspenders, and a third backup belt.
The one-line config change
In /etc/ssh/sshd_config:
Port 54321 PasswordAuthentication no PermitRootLogin prohibit-passwordThen systemctl reload sshd and update your ~/.ssh/config on clients. Don't forget to open the new port in your firewall before closing port 22, or you'll lock yourself out.