Changing the SSH port from the default 22 is a surprisingly ineffective security measure, often giving a false sense of security.

Let’s watch how it works with a live sshd_config and a connection attempt.

Imagine you have a server. You want to restrict access to it. The most basic layer of access control is what port the service listens on. SSH, the protocol for secure remote command-line access, defaults to port 22. This is well-known. Automated scanners constantly probe port 22 for vulnerable SSH servers. By changing the port, you move your SSH service off this well-trodden path.

Here’s a snippet from a typical sshd_config file on a Linux server:

# Package: OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
# ...
Port 22
# ...
PermitRootLogin prohibit-password
PasswordAuthentication yes
# ...

To change the port, you’d edit this file, usually located at /etc/ssh/sshd_config. You’d find the Port 22 line and change it to something else, say, Port 2222.

# Package: OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
# ...
Port 2222
# ...
PermitRootLogin prohibit-password
PasswordAuthentication yes
# ...

After saving the file, you need to tell the SSH daemon to reload its configuration. On most systemd-based systems, this is done with:

sudo systemctl reload sshd

Or, if you’re on an older init system:

sudo service ssh reload

Now, when you try to connect from a client, you must specify the new port:

ssh username@your_server_ip -p 2222

If you forget the -p 2222, your connection will fail because the SSH daemon is no longer listening on port 22. This is the "security" in action: you’ve made your SSH service invisible to basic port 22 scanners.

However, this change doesn’t fundamentally alter the security of your SSH authentication or encryption. It merely changes the "address" the service listens on. Sophisticated attackers, or even slightly more persistent automated scanners, will eventually discover your new port. They’ll scan all 65535 ports, or at least a wide range, and find your SSH service regardless of the port number.

The real security for SSH comes from strong authentication mechanisms and careful access control policies. This includes:

  • Disabling password authentication in favor of SSH key pairs.
  • Restricting root login (PermitRootLogin no).
  • Using strong, unique passwords if password authentication is absolutely necessary (though strongly discouraged).
  • Implementing a firewall (like ufw or firewalld) to limit access to the SSH port from specific IP addresses or ranges.
  • Using fail2ban or similar intrusion detection systems to block IPs that exhibit brute-force login attempts.

Changing the port is a minor obfuscation. It might stop the most basic, unthinking bots, but it’s akin to hiding your house key under the doormat instead of in a lockbox. It’s a small hurdle, not a fundamental security enhancement.

What most people don’t realize is that even if you change the port, the SSH daemon still needs to be configured to listen on that new port. If you have multiple network interfaces, and you only update the Port directive without specifying which interface to bind to (using the ListenAddress directive), the daemon will bind to all available interfaces on that new port. This means if your server has multiple IP addresses, SSH will be accessible on that new port on all of them, which might not be your intention. For example, to bind SSH only to a specific IP address 192.168.1.100 on port 2222, you would add:

Port 2222
ListenAddress 192.168.1.100

The next common pitfall after changing the SSH port is forgetting to update firewall rules to allow traffic on the new port, effectively locking yourself out.

Want structured learning?

Take the full Ssh course →