Moving SSH off port 22 reduces noise but does not improve security in a meaningful way. The right pick: keep 22 if you have key-based auth and a firewall; move to a custom port if you want quieter logs.
Table of contents
- The case for moving
- The case for staying
- The right pick
- The right configuration
- What usually breaks
- The scan landscape
- The port knocking pattern
- FAQ
The case for moving
The botnets that scan the IPv4 internet look for port 22. A fresh server with SSH on 22 gets thousands of failed login attempts per day. Moving to a non-standard port (2222, 2200, 22022) makes the botnets skip the server entirely.
The benefit is operational, not security: the team’s auth.log is not full of noise from bots trying to brute-force password logins.
The case for staying
The case for staying on 22:
- Easier tooling. Most monitoring, automation, and configuration management tools default to 22. The team that uses a custom port has to configure every tool.
- No real security gain. A targeted attacker scans all ports and finds the open SSH. Moving to a custom port hides the server from script kiddies, not from real attackers.
- Easier to remember. 22 is the default;
ssh user@hostworks without config.
The team that stays on 22 should still harden: key-based auth, PasswordAuthentication no, fail2ban or similar.
The right pick
The right pick depends on the team’s tolerance for noise:
- High-traffic public-facing server. Move to a custom port; the noise reduction is worth the config cost.
- Internal VPC server. Stay on 22; the security group limits access, so the brute-force noise is minimal.
- Personal dev server. Move to a custom port; the noise reduction makes the logs readable.
- Compliance-mandated setup. Follow the compliance requirement; if it says 22, use 22.
The right configuration
If you move, the right config:
# /etc/ssh/sshd_config
Port 2222
PasswordAuthentication no
PermitRootLogin noThen sudo systemctl reload sshd. The team that forgets the reload ends up with the old config still running.
The client-side ~/.ssh/config:
Host myhost
HostName 1.2.3.4
Port 2222
User myuserThen ssh myhost works as usual.
What usually breaks
The four pitfalls:
- Forgot to open the new port on the firewall. Locked out.
- Forgot to update monitoring. The team that monitors port 22 reports the service as down.
- Forgot to update fail2ban or similar. The intrusion-prevention system is still watching 22.
- Forgot the IPv6 firewall. Opened 2222 on IPv4 but not IPv6; the service is reachable on IPv4 only.
The scan landscape
The reality of port scanning in 2026:
The team that runs a public-facing server is scanned thousands of times per day. The scans come from:
- Botnets. Constant scans looking for known vulnerabilities (Log4j, EternalBlue, default credentials).
- Penetration testers. Legitimate scans by security firms hired to test the team’s defenses.
- Researchers. Internet-wide scanners like Shodan, Censys, and Project Sonar.
- Attackers. Targeted scans looking for specific services.
The team that knows about these scans has the right threat model. The team that thinks “nobody scans” is surprised by the volume of attack traffic.
The defensive response:
- Run SSH on a non-standard port to reduce botnet noise.
- Use key-based auth to prevent brute-force.
- Use fail2ban or similar to rate-limit failed attempts.
- Monitor SSH logs for suspicious patterns (many failures from one IP, unusual login times, etc.).
The port knocking pattern
A more advanced defense: port knocking.
The server’s SSH port (e.g., 22) is closed by default. To open it, the client must send a sequence of connection attempts to specific closed ports (e.g., port 7000, 8000, 9000, in order). After the correct sequence, the SSH port opens for that IP.
Tools: knockd (server), knock (client).
The benefit: a port scanner sees no open SSH port. The cost: complexity, and the sequence is in the client’s config file (which is itself a secret).
The team that uses port knocking has additional defense against scanners. The team that doesn’t bother with port knocking and relies on key-based auth + fail2ban has the right balance for most use cases.
FAQ
Should I move SSH off port 22?
It’s a tradeoff. The team that wants quieter logs moves. The team that wants simpler tooling stays. Neither is wrong.
Does moving SSH improve security?
Marginally. The team that relies on port obscurity instead of key-based auth has a false sense of security.
What’s the best SSH port to use?
Anything high (above 1024), unused, and easy to remember. 2222 is the convention.
Can I run SSH on multiple ports?
Yes, with multiple Port lines in sshd_config. The team that does this is usually migrating from one port to another without downtime.
Is port knocking worth the complexity?
For most teams, no. Key-based auth + fail2ban + non-standard port is sufficient. The team that operates high-value targets (government, finance) uses port knocking.
Can I use port knocking with SSH agent forwarding?
Yes. Port knocking opens the port, then SSH connects normally. The agent forwarding happens after the connection is established.
What’s the best way to monitor SSH attacks?
Log to a SIEM (Splunk, Datadog Security, Elastic). Alert on suspicious patterns. The team that has SSH logs in a SIEM can correlate across the fleet and catch attacks early.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: