SSH Port Numbers: The Default, the Risks, and the Safer Choices

SSH uses port 22 by default. Moving it to a non-standard port cuts 95% of the brute-force noise (the botnets scan 22; they don’t scan 2222). The right pick is a high port that is easy to remember and not used by another service.

Table of contents

• Why 22 is the default
• Why move off 22
• The right port to pick
• The configuration
• What usually breaks
• The honeypot trap
• The bastion host pattern
• FAQ

Why 22 is the default

Port 22 was assigned to SSH by IANA in 1995. Before that, it was used for SSH-related experimental services. The IANA registry still lists SSH on 22; the de facto standard has held for 30 years.

Why move off 22

The brute-force traffic on port 22 is constant. A fresh server with SSH on 22 gets thousands of failed login attempts per day within hours. The botnets scan the entire IPv4 range looking for open 22s.

Moving to a non-standard port does not improve security in a meaningful way (anyone who scans your IP will find the open port). But it cuts the noise: the botnets that scan 22 won’t scan 2222, so the failed-login log is empty.

The right port to pick

The three rules:

• High. Pick a port in the 10000-65535 range. The low ports (below 1024) require root to bind; the team that picks a high port avoids that.
• Unused. Verify the port is not used by another service on the host. ss -tlnp shows what’s listening.
• Easy to remember. A custom port that the team has to look up is worse than 22. Common picks: 2222, 2200, 22022, 222.

The team’s SSH config (in ~/.ssh/config) makes the port easy to remember:

Host myhost
    HostName 1.2.3.4
    Port 2222
    User myuser

Then ssh myhost works as usual; the custom port is hidden in the config.

The configuration

On the server: /etc/ssh/sshd_config:

Port 2222

Then sudo systemctl reload sshd. The team that forgets the reload (vs restart) ends up with the old config still running.

The team that also wants to disable password authentication (which is the bigger security win) sets PasswordAuthentication no in the same file.

What usually breaks

The four pitfalls:

• Forgot to update the firewall. The team that changes the SSH port but does not open the new port on the firewall locks themselves out.
• Forgot to update fail2ban or similar. The intrusion-prevention system is still watching 22.
• Forgot to update monitoring. The team’s external monitoring probes 22 and reports the service as down.
• Forgot the IPv6 firewall. The team that opens 2222 on IPv4 but not IPv6 has a half-broken config.

The honeypot trap

The trap the team falls into:

Moving SSH to a high port feels like security through obscurity. The reality: a targeted attacker who scans your IP finds the open port regardless of what port it’s on. The team that relies on port obscurity instead of key-based auth has a false sense of security.

The right defense:

1. Key-based auth. ssh-keygen on the client, public key in ~/.ssh/authorized_keys on the server. Disable password auth.
2. PermitRootLogin no. Even with key auth, root shouldn’t log in directly.
3. fail2ban or similar. Rate-limit failed login attempts.
4. MFA for human users. SSH keys for service accounts; MFA for human logins (via a bastion host).

The team that has all four has real security. The team that just moved the port has reduced log noise but no real security improvement.

The bastion host pattern

The right pattern for production SSH access:

1. SSH bastion (jump host). The only host with port 22 open to the public (or to the corporate VPN). All other hosts are only reachable from the bastion.
2. SSH agent forwarding. The developer adds their key to the bastion, then forwards the agent to the target host. No need to copy the private key to the bastion.
3. MFA on the bastion. The bastion requires a TOTP code in addition to the SSH key. AWS Session Manager, Cloudflare Tunnel, and Tailscale all provide this.

The team that runs a bastion has a single audit point for SSH access. The team that exposes SSH on every host has 50 audit points.

FAQ

Does changing the SSH port improve security?

Marginally. It cuts brute-force noise. The real security improvements are key-based authentication and PasswordAuthentication no.

What’s the best SSH port to use?

Whatever is high, unused, and easy for the team 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.

Should I disable SSH on port 22 entirely?

If you only listen on 2222, yes. The botnets scanning 22 will see nothing. The team that leaves both open is the team that still gets the brute-force noise.

How do I know if my SSH port change took effect?

From a remote host, ssh -p <new-port> user@server. If it connects, the change worked. If it times out, the firewall is blocking the new port.

Can I run SSH on both 22 and a custom port?

Yes, with multiple Port lines in sshd_config. The team that does this is usually migrating and wants to test the new port before removing 22.

What’s the best custom SSH port?

Whatever is high (above 1024), unused, and easy to remember. 2222 is the convention.

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:

• Ssh Ports
• Ssh Port Number
• Ssh Private Key Denied
• Introduction