Port 22 Explained: Check SSH Connectivity Without Guessing

When an SSH connection fails, “port 22 is open” can mean several different things. A service might be listening on the server but blocked by a firewall, or a TCP connection might succeed without the service being SSH at all.

The useful distinction is between listening locally, reachable over the network, and able to authenticate. Each is a separate check.

What port 22 is for

Port 22 is the default port for SSH, the protocol used for encrypted remote access. Standard SSH connections use TCP. The port number is a default, not a requirement: an administrator can configure the SSH server to listen on a different port.

SFTP and SCP commonly use the same SSH connection, so they normally use the server’s SSH port too. They don’t need separate default ports when they run over SSH. If SSH is listening on a custom port, clients for these protocols generally need to connect to that port as well.

A port number routes network traffic to a service on a machine: the IP address gets traffic to the host, and the port helps direct it to the relevant program. Port 22 is assigned to SSH, but seeing a listener on 22 alone doesn’t prove that the listener is actually an SSH server.

For more on the transport distinction, see why standard SSH uses TCP rather than UDP.

Check whether the server is listening

On the Linux server, use ss to check for a listener on exactly port 22:

sudo ss -ltn 'sport = :22'

If a service is listening, the output includes a local address ending in :22 and a LISTEN state. No output means nothing is currently listening on that exact port. To include the process name, add -p:

sudo ss -ltnp 'sport = :22'

The exact port filter matters. A loose search for :22 can also match ports such as 2222 or 22022, producing a false positive.

This check only tells you what’s listening on the server itself. It doesn’t confirm that a remote computer can reach the service through host firewalls, cloud security rules, or the network between the two machines. For a broader look at local listeners, check open ports on Linux with ss.

Test reachability from another machine

From a client machine, you can test whether a TCP connection to the host and port completes without attempting SSH authentication:

nc -vz example.com 22

This checks the TCP connection, not your username, key, or password. A successful result means something accepted a connection at that address and port; it does not prove that you can log in, or even that the service is SSH.

On Windows, PowerShell has a built-in TCP test:

Test-NetConnection -ComputerName example.com -Port 22

Look for TcpTestSucceeded. True means the TCP connection succeeded. It does not verify SSH credentials or authorization.

If the server is configured to send its SSH identification string, connecting may also show a banner such as SSH-2.0-OpenSSH_.... That’s evidence the service speaks SSH, but it still isn’t an authentication test.

Read the error before changing settings

Connection failures provide clues about which layer to check next:

• Connection refused: The host responded but rejected the connection. Often, nothing is listening on that port, or a firewall is actively rejecting the traffic.
• Connection timed out: You got no response before the attempt expired. A firewall or cloud security rule may be dropping packets, but a wrong address, failed route, or offline host can look similar.
• Authentication error: The network connection reached an SSH service, but login failed. Check the username, key, and server-side authentication settings rather than treating this as a port-reachability problem.

These are clues, not proof of one specific cause. For example, a timeout doesn’t establish that a firewall is responsible. Check the host address and network path too. If the server is listening locally but remote tests fail, investigate the firewall rules and any cloud network controls between the client and server.

Is it safe to leave port 22 reachable?

An internet-accessible SSH server will often receive automated login attempts. That’s common scanning activity, not by itself evidence that the server has been compromised. The important questions are how SSH is configured, who is allowed to connect, and whether the software is kept up to date.

Useful safeguards include:

• Prefer key-based authentication; where appropriate, disable password authentication in the SSH server configuration.
• Disable direct root login and use a normal account with sudo for administrative work.
• Keep OpenSSH patched.
• Restrict SSH to trusted source addresses or a VPN when practical.
• Consider tools such as fail2ban to throttle repeated failed attempts.

Changing SSH to a non-default port may reduce routine scanner noise, but it is not a substitute for authentication and access controls. A scanner can find a service on a different port too.

The short version

Port 22 is SSH’s usual TCP port, and SFTP and SCP commonly use that same SSH port. Check the server locally with ss, then test network reachability from another machine with nc or PowerShell’s Test-NetConnection. A successful TCP check establishes reachability—not that SSH login will work. Diagnose listening, network access, and authentication as separate steps.

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.