As an IT professional who manages Linux servers, you‘re likely very familiar with SSH. It‘s the secure, encrypted protocol we use to administer remote systems. But while SSH itself provides a secure tunnel, the default port it runs on, TCP port 22, is a well-known attack vector. Changing that port is a simple way to eliminate many basic brute force attempts.
In this comprehensive guide, I‘ll walk you through the entire process to change your SSH server‘s listening port to drastically improve security. We‘ll cover:
- How SSH works and the prevalence of attacks
- Why changing ports significantly enhances security
- Step-by-step guide to change the port
- Additional configuration tips
- In-depth technical analysis and best practices
Follow along and you‘ll have a more secure server, better protected from all manner of SSH-based attacks.
SSH and Ports Explained
SSH runs as a server process on your Linux systems, listening for client connections on a TCP port, almost always 22 by default. This designated port acts as a doorway that clients can use to access that service.
The client knows which doorway to knock on because standards bodies have assigned certain ports to common services like SSH. That‘s why even with no prior setup, an SSH client knows to talk to port 22.
But while convenient, this standardization is also why changing ports can meaningfully improve security. Attackers often rely on those defaults when scoping out targets. Changing the port means the door they expect won‘t work.
SSH Under Attack
Industry reports show SSH-based attacks have exploded in recent years. Brute force credential stuffing, exploitation of vulnerabilities, and man-in-the-middle hijacking are increasingly common.
F-Secure‘s recent threat landscape report noted SSH account takeovers increased 100x in 2021 alone. Port 22 is the most targeted SSH vector precisely because it‘s simple and expected. Attackers have industrialized attacks on that port.
By changing the default port, the noise from unsophisticated port scanners, botnets, and brute forcing tools targeting SSH drops considerably. You eliminate the bulk of automated, high-volume attacks – a huge security win.
Why Change Ports?
By running SSH on a non-standard port, you avoid discovery from most opportunistic scanning and brute forcing. This breaks scripts designed to just knock on a few common doors like 22.
That eliminates up to 90% of basic automation – things like Mirai botnet drones seeking SSH servers for DDoS or cryptomining. Such attacks spawn endless SSH sessions on every internet-wide IP looking for port 22. Changing ports defeats this entire class of distributed threat.
Obscurity alone shouldn‘t be your only defense, but it‘s an easy change that breaks common patterns. Doing so protects against broad reconnaissance and drive-by attacks to buy you overall risk reduction. Security teams recommend it universally as quick-win best practice.
Choosing a Port
The range of TCP ports available go from 1 to 65535, but only ports 1024 and higher should be considered to avoid conflicts with reserved system ports. While any number in that range will work, the 49152 to 65535 range is designated specifically as dynamic/private ports for custom services like this.
Within this range, randomly choosing a 5 digit number is fine. Just be sure to document it for your future reference. You‘ll specify this when connecting via SSH clients.
Avoid predictability through true randomness however – patterns like incrementing up from the default 22222 are easily guessable as well.
Additional Port Considerations
Other options like using an extremely high port like 60443 may provide further obscurity. But best practice is to use the standard dynamic range to avoid conflicts while still hiding from bulk attackers.
Some administrators use port knocking techniques in addition to obscure ports. But limiting access vectors with the right firewall rules is likely sufficient rather than that complexity.
If your SSH server is within a container platform or Kubernetes, ensure your network and port mapping configs allow traffic to the new port from outside. Network security layers should focus access rules only to that node hosting SSH.
The Step-by-Step Process to Change Your Port
Ready to harden your SSH server with a new port? Follow these steps:
-
Connect to your server via SSH on the default port 22 using key authentication
-
Backup your SSH server config just in case:
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak -
Give yourself root edit permissions on the config file:
$ sudo su -
Open config file in editor (We‘ll use vi here but use what you prefer):
# vi /etc/ssh/sshd_config -
Find the Port line, remove comment if needed, change 22 to your new desired port:
Port 58210 -
Also confirm that PasswordAuthentication is disabled
-
Save changes and exit editor
-
Have SSH re-read config and restart:
# systemctl reload sshd -
Verify SSH process restarted correctly
# systemctl status sshd -
Keep session open, test connectivity on new port from a separate terminal
$ ssh user@host -p 58210 -
Validate both IPv4 and IPv6 connectivity if enabled
-
Update firewall rules to only allow the new port
$ ufw allow 58210/tcp $ ufw default deny -
Finish documentation on the non-standard port selection before closing original session
Validating Changing SSH Port Success
Once confirmed working on the new port from multiple client IPs, the changed port is active for all new logins. Finish documentation and close original session.
Before considering the job done though, be absolutely sure to verify you can still login on that non-standard port. Confirm the standard port 22 no longer works from external connections as well.
Following validation, ensure all admins or automation relying on SSH update their tools and scripts to specify the new non-standard SSH port.
Tips for Changing SSH Ports
Beyond just altering the port, follow these additional best practices:
- Whitelist new port in firewall rules immediately after changing
- Keep an SSH session open on standard 22 when testing
- Check for failure restarting SSHD after config changes
- Validate both IPv4 and IPv6 connectivity
- Use unrelated non-standard port numbers vs small increments
- Document the new port choice within system inventories
Potential Issues to Watch For
If your SSH configuration references port 22 specifically outside of the main value, modifying only the main Port line may not be sufficient. Scan the rest of your SSH server config for areas that point to the old port.
Take care that existing automation expecting SSH on 22 has appropriate error handling if that main port suddenly stops responding. You may want to temporarily keep port 22 open until other tools are updated.
Monitor for any failures of the SSH daemon after changing ports. Some environments may require additional changes to handle multiple or non-standard listener ports properly.
Adjust as needed and revert changes if unable to get a stable SSHD service running on the new port quickly.
A Note on Obscurity vs Security
While changing the default port measurably improves security, it‘s still partially based on "security through obscurity" which is controversial…
Some argue that real security should not depend on attackers not knowing a secret detail like what port you run SSH on. But obscurity remains a simple extension of the defense-in-depth approach. Modern cryptographic standards behind SSH, proper keys, configuration hardening and firewall rules provide the underlying security. Changing ports augments that critical hygiene to eliminate orthogonal attack volume.
Obscurity alone protects against automation but organized adversaries can always discover and adapt to custom ports. The key is recognizing this as just one layer of security- not the only protection against targeted threats.
In Sum: Significantly More Secure
Done consistently across an environment, altering SSH ports provides immense risk reduction. By selecting and properly configuring a custom port you can send thousands of opportunistic probes a day packing, thereby securing your server inventory measurably.
Combine a non-standard SSH port with strong passwords, keys, strict firewall rules and ongoing patching to reliably detect and defeat tenacious adversaries. Use this guide‘s industry best practices to change ports with confidence and significantly enhance your security posture.
