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.
SSH Port Conflicts: How to Identify and Change Ports
SSH normally listens on TCP port 22, but real servers are not always that tidy. A cloud image may have SSH moved to 2222. A container host may publish several SSH-like services through different ports. A hardening script may have changed sshd_config months ago. Or sshd may simply fail to start because another process is already bound to the same address and port.
Port problems usually show up as Connection refused or Connection timed out. The difference matters: refused usually means you reached the host but nothing accepted the connection on that port. Timeout usually means a firewall, route, security group, or network path dropped the traffic.
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, a true bind conflict means sshd cannot listen on the configured address and port. A more common issue is simpler: SSH is listening on one port, while the client or firewall is using another.
Common Connection Issues Related to Ports
When troubleshooting SSH connectivity, port issues often manifest as:
- 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).
- 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, OpenSSH uses the default port 22 unless another included config file overrides it.
#Port 22
Port 2222
Also check included config snippets:
grep -R "^[[:space:]]*Port" /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null
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.
Using the ss command (Recommended on modern systems):
This command shows all TCP listeners (-t), including processes (-p), filtering for the SSH service (grep sshd).
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:
- Verify Firewall Access: Ensure that the new port is open in your host-based firewall (e.g.,
ufworfirewalld) before restarting the SSH service. - Edit Configuration: Modify
/etc/ssh/sshd_configto the new port number. - Test Configuration Syntax: Test the configuration syntax before restarting.
- Restart SSH Service: Apply the changes.
- Test Remote Connection: Immediately attempt to connect using the new port from a separate terminal session.
- 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 Reloading SSH Daemon
Always test the configuration file syntax before applying changes:
sudo sshd -t
If syntax is clean, reload or restart the service:
sudo systemctl reload sshd
# If your system uses the ssh service name instead:
# sudo systemctl reload ssh
Then check status:
sudo systemctl status sshd
Leave your current SSH session open and test the new port from a separate terminal before closing anything.
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 worked. Only then should you remove the old firewall rule.
Warning: If you change the port and fail to open it in the firewall, or if
sshdfails to reload, you can lock yourself out. Keep console, serial, cloud recovery, or another administrative path available.
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.
A Safer Way to Think About Port Changes
Do not trust the config file alone, and do not trust the firewall alone. Confirm all three layers: sshd_config says the port you expect, ss shows sshd actually listening there, and the firewall or cloud security group allows traffic to reach it. When those three agree, the client command is straightforward:
ssh -p 2222 username@your_server_ip
Changing the SSH port may reduce noisy automated scans on port 22, but it is not a replacement for key authentication, sane firewall rules, patched systems, and disabling password login where appropriate.