SSH Port Conflicts: How to Identify and Change Ports

Resolve frustrating SSH connection issues caused by port conflicts. This guide details how to definitively identify the active SSH port using system commands (`ss`/`netstat`) and provides a step-by-step, safe methodology for modifying the configuration file (`sshd_config`) and updating firewalls to switch to a new port number, preventing lockouts.

34 views

SSH Port Conflicts: How to Identify and Change Ports

The Secure Shell (SSH) protocol is the bedrock of secure remote access and management for servers worldwide. By default, SSH operates on TCP port 22. However, in complex network environments, multi-server setups, or environments prioritizing security through obscurity, this default port might be reassigned. When a system attempts to connect to an SSH server that is running on a non-standard port—or when two different services try to bind to the same port—a port conflict occurs, often resulting in frustrating errors like "Connection refused" or timeouts.

This guide will walk you through the essential steps to diagnose if an SSH port conflict is the root cause of your connectivity issues. More importantly, we provide practical, actionable instructions on how to safely verify the current active SSH port and how to change it within the main configuration file, ensuring smooth, secure remote management.


Understanding SSH Port Conflicts

A port conflict arises when two distinct network services attempt to listen for incoming connections on the exact same TCP or UDP port number. Since only one process can bind to a specific port on an IP address at any given time, the second service attempting to start will usually fail or default to a different port if configured to do so.

For SSH, if the default port 22 is already in use by another service (though rare for standard OS installations), the SSH daemon (sshd) will fail to start, leading to connection failures. Conversely, if you manually configured sshd to use a custom port (e.g., 2222) but are still trying to connect using port 22, the connection will be rejected by the firewall or simply time out.

When troubleshooting SSH connectivity, port issues often manifest as:

  1. Connection Refused: This usually means the target machine is reachable, but no service is actively listening on the specified port (either the wrong port was used, or the SSH service failed to start).
  2. Connection Timeout: This often indicates that traffic destined for that port is being blocked by a firewall (either host-based or network-based) or that the host itself is unreachable.

Step 1: Identifying the Currently Active SSH Port

Before making any changes, you must confirm what port the SSH daemon is actually using. This requires administrative access (usually via console or an existing successful connection).

A. Checking the SSH Configuration File

The primary location for SSH configuration is the sshd_config file. The port directive specifies which port sshd listens on.

Location: /etc/ssh/sshd_config (Common on Linux/Unix systems)

Use a text editor like nano or vim to inspect the file:

sudo nano /etc/ssh/sshd_config

Look for the line starting with Port. If it is commented out (starts with a #), it defaults to 22. If a number is present, that is the active port.

#Port 22  <-- Defaults to 22 if uncommented or if this line is missing entirely
Port 2222 <-- This server is configured to use port 2222

B. Checking Listening Sockets with netstat or ss

The most authoritative way to confirm what port the service is currently bound to is by checking the operating system's network listening sockets. The modern tool is ss, but netstat is still widely available.

This command shows all TCP listeners (-t), including processes (-p), filtering for the SSH service (grep sshd).

# Show TCP listening ports, including the process ID using the port
sudo ss -tlpn | grep sshd

Example Output (Default Port):

LISTEN 0      128    0.0.0.0:22               0.0.0.0:*    users:(("sshd",pid=1234,fd=3))

Example Output (Custom Port 2222):

LISTEN 0      128    0.0.0.0:2222             0.0.0.0:*    users:(("sshd",pid=1234,fd=3))

Using netstat (Alternative):

sudo netstat -tulpn | grep sshd

Once you identify the port (e.g., 2222), you must use that port number when connecting from a remote client.


Step 2: Changing the SSH Port Safely

Changing the SSH port is a common security hardening practice. Crucially, never change the port before ensuring your new configuration works, or you risk locking yourself out.

A. The Safe Sequence for Changing Ports

Follow these steps precisely to avoid losing access:

  1. Verify Firewall Access: Ensure that the new port is open in your host-based firewall (e.g., ufw or firewalld) before restarting the SSH service.
  2. Edit Configuration: Modify /etc/ssh/sshd_config to the new port number.
  3. Test Configuration Syntax: Test the configuration syntax before restarting.
  4. Restart SSH Service: Apply the changes.
  5. Test Remote Connection: Immediately attempt to connect using the new port from a separate terminal session.
  6. Remove Old Port Rule (Optional): Once verified, close the old port (22) in the firewall.

B. Modifying /etc/ssh/sshd_config

Use your preferred editor to open the configuration file:

sudo nano /etc/ssh/sshd_config

Locate the Port line. Change the existing value or uncomment/add a new Port directive. Let's change from 22 to 2222.

# Change this line:
Port 2222

Save and close the file.

C. Updating Host-Based Firewalls (Crucial Step)

If you skip this, your connection will fail with a timeout after the service restarts.

Using UFW (Ubuntu/Debian):

# 1. Allow the new port
sudo ufw allow 2222/tcp

# 2. If you wish to remove the old port rule later (after testing):
# sudo ufw delete allow 22/tcp

sudo ufw status verbose

Using Firewalld (RHEL/CentOS/Fedora):

# 1. Allow the new port permanently
sudo firewall-cmd --permanent --add-port=2222/tcp

# 2. Reload firewall rules
sudo firewall-cmd --reload

D. Testing and Restarting SSH Daemon

Always test the configuration file syntax before restarting the service. This prevents syntax errors from locking you out.

# Test configuration syntax (specific implementation may vary by distro)
# On systems using systemd, this often isn't explicitly required if reload works, 
# but a simple restart is safer if you made major changes.

sudo systemctl restart sshd

# Check status to ensure it started successfully without errors
sudo systemctl status sshd

E. Connecting via the New Port

From your client machine, you must now explicitly specify the new port using the -p flag with the ssh command:

ssh username@your_server_ip -p 2222

If the connection succeeds, the port change was successful! You can now safely remove the old port rule from your firewall if necessary.

⚠️ Warning on SSH Port Changes: If you change the port and fail to open it in the firewall, or if the sshd service fails to restart, you will be locked out. Always ensure you have console or alternative administrative access (like a VNC session) when modifying these core networking services.


Troubleshooting Connection Failures After Changing Ports

If you receive an error after changing the port, follow this quick checklist:

Error Symptom Likely Cause(s)
Connection Refused 1. sshd failed to start (check systemctl status sshd). 2. You specified the wrong port in the client command. 3. The firewall is allowing traffic on the old port (22) but blocking the new port (2222).
Connection Timeout 1. Host is down. 2. The host firewall (UFW/firewalld) is actively dropping packets for the new port. 3. Network infrastructure firewall is blocking the port.

To confirm the daemon is listening, re-run sudo ss -tlpn | grep sshd on the server side.

Conclusion

SSH port conflicts, while sometimes subtle, are easily resolved by understanding where the service configuration lives (/etc/ssh/sshd_config) and verifying the active socket binding using tools like ss or netstat. By following a cautious, systematic approach—especially regarding firewall updates before restarting the service—you can securely change your SSH port to enhance server security without risking administrative lockout.