When an SSH connection fails, it’s easy to jump straight to authentication. But first, check the port: SSH normally uses TCP port 22, and a server configured for another port won’t respond to a client trying the default.
The client and server need to agree on the port. Here’s how to connect, save a custom port, and check whether the network path is open.
The default: TCP port 22
If the server uses its default SSH configuration, connect without specifying a port:
ssh user@example.com
SSH uses TCP, not UDP. Port 22 is a convention, not a requirement: a server can listen on another TCP port, such as 2222. The port number itself doesn’t determine whether the connection is encrypted; SSH’s protocol and configuration do. For more on the transport distinction, see why SSH uses TCP rather than UDP.
If the server listens on port 2222, specify it with lowercase -p:
ssh -p 2222 user@example.com
That only works if the server is actually listening on that port and the network allows traffic to reach it.
Use the right port syntax for each tool
SSH-related commands don’t all use the same flag for a port:
# SSH: lowercase -p
ssh -p 2222 user@example.com
# SFTP and SCP: uppercase -P
sftp -P 2222 user@example.com
scp -P 2222 report.txt user@example.com:/tmp/
The case matters. In scp, lowercase -p is used to preserve file timestamps, so uppercase -P specifies the port instead.
For Git, use the ssh:// URL form to include a custom port:
git clone ssh://user@example.com:2222/path/to/repo.git
SFTP and SCP run over SSH, so they use the same SSH port—there isn’t a separate SFTP port to open for these commands.
Save the port in SSH config
If you connect to the same host often, put its details in ~/.ssh/config:
Host myserver
HostName example.com
User deploy
Port 2222
Then connect with the alias:
ssh myserver
OpenSSH uses that host entry for matching connections, including SFTP, SCP, and Git commands that use OpenSSH. Keep the entry specific: a Host pattern applies to the connections that match it.
Check whether the port is reachable
Test the port from your own machine. Use the configured port rather than assuming it’s 22:
# Linux or macOS
nc -zv example.com 22
# Windows PowerShell
Test-NetConnection -ComputerName example.com -Port 22
Replace 22 with the server’s actual SSH port if it has been changed. A successful port test shows that the network connection reached that port; it doesn’t prove that SSH authentication will succeed.
Pay attention to the failure type. A connection refused usually means the destination actively rejected the connection—for example, because no service is listening there. A timeout often means there was no response, which can point to a firewall, routing problem, incorrect address, or cloud network rule. Check the server’s listening port and any host, router, or cloud firewall rules before changing SSH keys.
Changing the server port is a separate task
The client-side -p option doesn’t change where the server listens. The server’s SSH daemon configuration and network rules must allow the chosen port, and the client must use that same port to connect.
Changing a remote server’s SSH port can lock you out if you apply the change before allowing the new port through the firewall or if the service doesn’t start with the new configuration. If you need to move a server off port 22, follow a careful sequence: change the SSH port without locking yourself out.
Does using another port make SSH more secure?
Moving SSH to a non-default port may reduce routine scanning noise in authentication logs, but it does not replace security controls. A scanner can look for SSH on other ports, and changing the port doesn’t change SSH’s encryption or authentication.
Use a non-default port if it makes your setup easier to manage, not as your main defense. Restrict network access where practical, use strong authentication, and keep OpenSSH updated.
Quick recap
- SSH normally uses TCP port 22.
- For a custom port, use
ssh -p PORT user@host. - SFTP and SCP use uppercase
-Pfor the port. - Add
Port PORTto a matching~/.ssh/configentry to avoid repeating it. - Confirm the server listens on that port and that firewalls allow the connection.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)