The default SSH port is 22, registered with IANA in 1994 by Tatu Ylonen, the original author of the SSH protocol. Changing the port does not add real security — it adds obscurity that buys you minutes, not days, against a determined attacker. The team that treats port-knocking as a substitute for key-based auth has the wrong mental model. The team that uses port 22 with key-only auth, fail2ban, and a non-root user has the right model.
Table of contents
- Why port 22 specifically
- How to change the SSH port
- What you actually gain from changing the port
- Key-based auth is the real defense
- fail2ban for the remaining noise
- What about port knocking?
- FAQ
Why port 22 specifically
The number 22 is not arbitrary. Tatu Ylonen, the original author of SSH, asked IANA for a port assignment in 1994, and the IANA assigned 22 from the registered range. The port was registered formally in RFC 4250 (the SSH protocol assigned numbers) in 2006, but the de facto assignment dates to 1994. SSH replaced the unencrypted rsh, rlogin, and telnet protocols, and the port 22 assignment made it the default for all SSH implementations since.
The right answer for a server that exposes SSH to the internet is to keep port 22 unless you have a specific reason to change it. The reason to keep the default is operational: documentation, scripts, monitoring, and Ansible playbooks all assume port 22. The reason to change it is to reduce the volume of automated brute-force attempts, which mostly target port 22 because that’s where SSH is.
The change-port-only defense is weak because the scanner finds the new port in minutes. The right answer is to combine port change with key-based auth, fail2ban, and a non-root user. The combination is what actually reduces the attack surface.
How to change the SSH port
The right way to change the port is to edit /etc/ssh/sshd_config, find the #Port 22 line, and change it. For example, to move SSH to port 2222:
Port 2222Uncomment the line (remove the #) and change the number. Then reload sshd:
sudo systemctl reload sshdThe right verification is to open a new SSH connection on the new port in a separate session before closing the current one. If the new connection fails, the old one is still open and you can fix the config.
The wrong answer is to restart sshd. A restart drops the current connection if the new config has an error. A reload tells sshd to re-read the config without dropping connections. The right answer is always reload.
The right answer for the firewall is to update the rules. On Ubuntu with UFW:
sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo ufw reloadOn RHEL / Fedora with firewalld:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-port=22/tcp
sudo firewall-cmd --reloadThe wrong answer is to change the sshd config without updating the firewall first. The right answer is to allow the new port, verify it works, then remove the old port. Otherwise you lock yourself out of the box.
What you actually gain from changing the port
The honest answer is: a reduction in low-effort brute-force attempts. A scanner that targets port 22 will get a connection refused on a non-standard port. A scanner that probes the whole port range will find the new port in seconds.
The data on this is clear. The number of failed-login attempts on port 22 of an internet-exposed server is in the thousands per day, mostly from automated botnets. Moving SSH to a non-standard port cuts that to near zero for the same scanner. The attacks that remain are from scanners that probe non-standard ports or from attackers who have specific targets. The right answer is to assume that anyone who wants to find your SSH port will find it, and to focus on the things that actually stop them: key-based auth, fail2ban, non-root user, and a recent OpenSSH version.
The right answer for a defense-in-depth posture is to use a non-standard port AND a non-default port. Some operators use a high port above 10000, which most scanners do not probe in their default scan range. The right answer is to pick a port that is not in the typical nmap -p 1-65535 top-1000 list and not in any well-known service list. Ports like 2222, 22022, and 5022 are common and will be probed. Ports like 53829 or any random number in the 10000-65535 range are less likely to be hit.
Key-based auth is the real defense
The right answer for SSH security is key-based authentication. The right config in /etc/ssh/sshd_config:
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin noWith these three lines, password-based auth is disabled, root login is disabled, and the only way in is with an SSH key. The right answer is to also use AllowUsers or AllowGroups to restrict which accounts can SSH in. The wrong answer is to allow password auth and rely on the password being strong — the right answer is to not allow passwords at all.
The right answer for an existing fleet is to roll this out via configuration management. Ansible, Puppet, Chef, and Salt all have modules for the sshd_config. The right answer is to make this part of the baseline and verify it on every box.
The right answer for PermitRootLogin is no or prohibit-password. The prohibit-password variant allows key-based root login (useful for automation) but disallows password-based root login. The wrong answer is yes (the default on some distros) which allows root to log in with a password.
fail2ban for the remaining noise
The right answer for the volume of automated brute-force attempts that still arrive on port 22 (or your non-standard port) is fail2ban. Fail2ban watches the auth log, identifies failed-login patterns, and bans the source IP at the firewall level. The right config is the default jail for sshd:
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 600The maxretry = 5 means five failed login attempts within findtime = 600 seconds (10 minutes) results in a one-hour ban. The right answer is to tune these for your environment. A higher maxretry is more forgiving for legitimate typos. A longer bantime is more aggressive against persistent attackers. The right answer for most servers is the defaults.
The wrong answer is to install fail2ban and not configure the jail. The default install includes a config file but does not enable any jails. The right answer is to enable the sshd jail and verify it is working with sudo fail2ban-client status sshd.
What about port knocking?
Port knocking is a sequence of connection attempts to closed ports that opens a port for the source IP. The right answer for the security value of port knocking is: it is a less-portable version of “use a non-standard port.” It is obscurity, not security. The right answer for any serious security need is to use a VPN (WireGuard, Tailscale) and put SSH behind it. The VPN provides actual authentication (cryptographic) and makes the SSH port unreachable to anyone not on the VPN. Port knocking does not provide cryptographic authentication — it just adds a step.
The right answer for a home lab is port knocking if you want to learn how it works. The right answer for a production server is a VPN. The right answer for a publicly accessible server is key-based auth + fail2ban + non-root user + a non-standard port, and nothing more.
FAQ
Does changing the port break SCP and SFTP?
No, as long as the client knows the new port. The right answer for scp and sftp is to pass -P <port> (uppercase for scp, lowercase for sftp):
scp -P 2222 file.txt user@host:
sftp -P 2222 user@hostThe right answer for ~/.ssh/config is to set the port per-host:
Host myhost
HostName example.com
Port 2222
User aliceWith the config file, the client commands work without the -P flag.
Can I run SSH on multiple ports?
Yes. List multiple Port lines in sshd_config:
Port 22
Port 2222The right answer is to keep the default for the first few weeks after the change, while you verify the new port works for all your clients. The right answer for the long term is to drop the default and use only the non-standard port.
What port should I pick?
Any unused port above 1024. The wrong answer is 2222 — it is the most common non-standard SSH port and is in every scanner’s default list. The right answer is a random port in the 10000-65535 range. Pick a memorable number that is not 2222, 22022, 5022, 222, 22, or 22222. The right answer for a memorable port is a year, a birthday, or a phone number that has no other meaning.
My ISP blocks port 22. What do I do?
Move SSH to a non-standard port. Most ISPs allow port 22 for outbound connections, but some block inbound port 22 on residential connections. The right answer is to pick a non-standard port and update the firewall and the sshd config as above. The right answer for a server behind a CGNAT is to use a tunnel (Cloudflare Tunnel, Tailscale Funnel, ngrok) instead.
Is there a security difference between high and low ports?
No, in the sense that a port is just a 16-bit number. The right answer for picking a port is to pick one that is not in the typical scanner’s default list. The right answer for an attacker is that a port scan takes seconds, so any port you pick is findable. The right answer is to combine a non-standard port with key-based auth and fail2ban.
What if I forget the new port?
You do not lose access if you have console access to the box (IPMI, KVM, or a cloud provider’s serial console). The right answer is to connect to the console, log in, run sudo grep ^Port /etc/ssh/sshd_config, and see the configured port. The right answer for boxes without console access is to document the port in your runbook before you change it.
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: