SSH (Secure Shell) is the standard way to remotely access Linux servers. By default, SSH listens on port 22, which makes it an easy target for automated scanning tools and bots constantly probing the internet for vulnerable servers. One simple but effective security measure is changing the default SSH port to reduce these automated attacks.

The Reality of Default SSH Ports

If you’ve ever examined the logs of a public-facing server, you’ve likely noticed the constant barrage of login attempts targeting SSH on port 22. These aren’t typically targeted attacks—they’re automated bots scanning the entire internet for any accessible SSH servers, then attempting common username and password combinations.

A 2023 study by GreyNoise Intelligence revealed that an average internet-connected server with SSH on port 22 receives approximately 2,000-3,000 unauthorized login attempts daily. The vast majority of these are from automated scanning tools rather than human attackers, but they still pose a risk if you’re using password authentication or have any unpatched vulnerabilities.

This steady stream of unwanted traffic isn’t just a security concern—it clutters logs, consumes system resources, and makes it harder to identify genuine threats among the noise. By changing your SSH port, you can eliminate as much as 95-99% of this background noise, making your logs more useful and your security monitoring more effective.

Why Change Your SSH Port?

Many attackers use automated tools that specifically target port 22. By changing to a non-standard port, you can:

• Drastically reduce the number of automated attacks in your logs
• Make your server less visible to casual scanning
• Add a simple layer of security through obscurity (not perfect, but helpful)

While changing your SSH port isn’t a complete security solution, it’s an easy first step that complements other security measures like key-based authentication and proper firewall rules.

Step-by-Step Guide to Changing Your SSH Port

Step 1: Edit the SSH Configuration File

The SSH server configuration file contains all the settings that control how your SSH server operates. This file is typically located at /etc/ssh/sshd_config on most Linux distributions. When making changes to critical system services like SSH, it’s always a good practice to create a backup of the configuration file first. This provides an easy way to revert changes if something goes wrong.

SSH operates as a privileged service, so you’ll need root or sudo access to modify its configuration. The configuration file follows a simple format where settings are specified as Option Value pairs. Comments are preceded by the # character, and many default settings are commented out, indicating that the service is using built-in defaults.

First, back up your SSH configuration file:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Then edit the configuration file:

sudo nano /etc/ssh/sshd_config

Find the line that says #Port 22. The # symbol means this line is commented out and the default port 22 is being used. Change it to a different port by removing the # and changing the number:

Port 2222

Choose a port number between 1024 and 65535 that isn’t being used by another service. Common alternate choices include 2222, 2022, or 22222.

Step 2: Adjust Your Firewall Rules

Firewalls act as gatekeepers for your server’s network traffic, controlling which ports are accessible from the outside world. When you change your SSH port, you need to update your firewall rules to allow traffic on the new port. Forgetting this step is one of the most common causes of being locked out after changing the SSH port.

Most Linux distributions come with a firewall installed and enabled by default. Ubuntu and many Debian-based distributions use UFW (Uncomplicated Firewall), while CentOS, RHEL, and other distributions might use firewalld or directly configure iptables. The commands below address the most common firewall configurations, but you should verify which firewall solution your system uses.

It’s crucial to add the new rule before restarting SSH. If you restart the SSH service first, you might find yourself unable to establish new connections if the firewall is blocking the new port.

For UFW (Ubuntu’s default firewall):

sudo ufw allow 2222/tcp

For iptables:

sudo iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
sudo iptables-save > /etc/iptables/rules.v4

Step 3: Test Your Configuration

Check your SSH configuration for errors:

sudo sshd -t

If there are no error messages, your configuration is valid.

Step 4: Restart the SSH Service

Now restart the SSH service to apply the changes:

sudo systemctl restart sshd

Step 5: Verify the New Port

IMPORTANT: Don’t close your current SSH session yet!

Open a new terminal window and try connecting to your server using the new port:

ssh -p 2222 username@your_server_ip

If you can connect successfully, then your port change worked. If not, you can still use your original session to troubleshoot.

Step 6: Optional – Disable the Old Port

Once you’ve confirmed that the new port works, you can close the original port 22 if it’s still open:

sudo ufw deny 22/tcp

Or for iptables:

sudo iptables -D INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables-save > /etc/iptables/rules.v4

Understanding the Security Implications

Changing your SSH port falls under a security practice sometimes called “security through obscurity.” While this approach alone is not sufficient for protecting a system, it can be an effective component of a larger security strategy when implemented correctly.

The main benefit comes from avoiding the automated scanning that targets port 22 specifically. Most automated attacks are designed for efficiency and will only check default ports. By moving to a non-standard port, you essentially become invisible to these basic scans, which account for the vast majority of SSH intrusion attempts.

However, it’s important to understand the limitations of this approach. A determined attacker performing a targeted attack against your specific server will likely run a full port scan and discover your SSH service regardless of which port it’s using. Sophisticated attackers can use tools like nmap to identify SSH services running on non-standard ports by analyzing the response patterns.

This is why changing your SSH port should be viewed as a first step in a comprehensive security strategy rather than a complete solution. Think of it as similar to changing the default administrator username on a website—it won’t stop sophisticated attacks, but it eliminates a significant portion of low-effort, automated attempts.

Adjusting Your SSH Client for the New Port

When connecting to your server in the future, you’ll need to specify the port:

ssh -p 2222 username@your_server_ip

To avoid typing the port every time, you can add it to your SSH config file on your local machine:

nano ~/.ssh/config

Add these lines:

Host myserver
    HostName your_server_ip
    Port 2222
    User your_username

Now you can simply type ssh myserver to connect.

Common Issues and Troubleshooting

Problem: Locked Out of Server

If you’ve locked yourself out, you’ll need to access your server through other means:

1. Use the web console provided by your hosting company
2. Connect directly to the physical machine if possible
3. Contact your hosting provider for assistance

Problem: SELinux Blocking the New Port

If you’re using SELinux and it’s blocking your new port:

sudo semanage port -a -t ssh_port_t -p tcp 2222

Problem: Forgot the New Port

If you’ve forgotten which port you set:

sudo grep "Port " /etc/ssh/sshd_config

Final Security Considerations

Changing your SSH port is a good start, but for comprehensive security, also consider:

1. Using SSH keys instead of passwords: Significantly more secure than password authentication
2. Implementing fail2ban: Automatically blocks IPs with too many failed login attempts
3. Keeping your system updated: Regular updates patch security vulnerabilities
4. Limiting user access: Only give SSH access to users who truly need it

Building a Layered SSH Security Approach

Cybersecurity experts often emphasize the importance of defense in depth—implementing multiple layers of security controls that work together to protect a system. Changing your SSH port represents just one layer in what should be a comprehensive approach to securing SSH access.

Consider enhancing your SSH security with these additional measures:

Key-based authentication eliminates the vulnerability of password-based systems to brute force attacks. When properly implemented, SSH keys provide cryptographically strong authentication that is extremely difficult to compromise. Even if an attacker discovers your non-standard SSH port, they won’t be able to gain access without the correct private key.

Two-factor authentication (2FA) adds another verification step beyond just possessing the SSH key. This could involve a time-based one-time password (TOTP) generated by an app like Google Authenticator or Authy.

Restricted user access limits SSH logins to specific user accounts that require server access, rather than allowing all system users to log in remotely. Consider creating a dedicated jump host or bastion server that serves as the single entry point to your infrastructure.

IP allowlisting restricts SSH access to specific trusted IP addresses or ranges, which is particularly effective for servers that only need to be accessed from certain locations like a corporate office.

When these measures are combined with a non-standard SSH port, you create a robust security posture that addresses multiple attack vectors simultaneously.

Conclusion

Changing your SSH port is a simple security measure that can significantly reduce automated attacks against your server. While it’s not a complete security solution on its own, it’s an easy first step that works well alongside other security practices. By following this guide, you’ve taken a worthwhile step toward better server security.

The most effective server security comes from implementing multiple complementary measures rather than relying on any single approach. As you become more comfortable managing your server’s security, consider gradually implementing the additional protective measures mentioned in this guide to create a truly robust defense system for your infrastructure.