2026年11月12日

SSH Port 22 Not Reachable From Outside: Causes and How to Check

Networking & Connectivity

This article is a localized edition of the Japanese original. Read the Japanese original

When you cannot connect to a server over SSH from outside, the quickest route is to look at the error message from the ssh command and tell apart "packets are not arriving (timeout)" from "they arrive but are not accepted (refused)." For the former, investigate the cloud and OS firewalls and the network you are connecting from; for the latter, check the state of sshd and the port it listens on. This article explains how to read the messages, the steps to check and fix causes in order of likelihood, and precautions to avoid locking yourself out while you work.

Before you start: preparing so you do not get locked out

When you touch firewall or sshd settings, a configuration mistake can cost you your only way in. Secure the following two things first.

Confirm a recovery path in advance: a way to log in without SSH, such as the console feature in your VPS control panel, or the EC2 Serial Console or Systems Manager Session Manager on AWS
If you already have an SSH session connected, leave it open rather than closing it, and after changing settings, connect anew from a different terminal to verify

Before editing a configuration file, keep a copy, as in sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.

Tell where the cause is from the error message

From the computer you are connecting from, connect with verbose output.

ssh -v -p 22 user@203.0.113.10

The message that appears near the end tells you roughly where the cause lies.

Connection timed out: Packets are being dropped somewhere. Suspect the cloud firewall, the OS firewall, the network you are connecting from, or a wrong IP address
Connection refused: The connection reaches the server, but no process is listening on that port (or it is being rejected with REJECT). Suspect that sshd is stopped or that the port number is different
No route to host: There is no route, or a rejection response is coming back along the way. Check the IP address and REJECT settings in the firewall
kex_exchange_identification: Connection closed by remote host or Connection reset by peer: TCP connected, but the connection is cut at sshd or just before it. Suspect blocking by fail2ban or similar, a limit on sshd's concurrent connections, or access control settings
Permission denied (publickey): You are connected to the port, and authentication fails. It is a problem with the key or username, not a port problem

On Windows, you can use PowerShell's Test-NetConnection 203.0.113.10 -Port 22 to check whether the TCP connection succeeds (whether TcpTestSucceeded is True). On Linux and macOS, nc -vz 203.0.113.10 22 serves the same purpose.

Cause 1: Closed by the cloud or VPS firewall

The most common reason you cannot connect from outside is a network-side firewall that sits in front of the OS. This includes AWS security groups and network ACLs, Google Cloud VPC firewall rules, Azure network security groups, and the packet filter in the control panel of a Japanese VPS provider.

What to check is whether the inbound rules allow TCP port 22 (or the port you changed to), and whether the allowed source IP address matches your current IP. It is common for people to find that their home or office connection's IP changed, so they fell outside the IP that was allowed before. You can look up your current IP from the computer you connect from, for example with a browser "what is my IP" service.

From a security standpoint, the basic approach is to avoid opening port 22 to all sources (0.0.0.0/0) and to narrow it to the range you need, such as your own IP or a VPN exit.

Cause 2: Closed by the OS firewall

# Ubuntu / Debian (ufw)
sudo ufw status verbose

# RHEL / AlmaLinux / Rocky Linux (firewalld)
sudo firewall-cmd --list-all

# If you use nftables directly
sudo nft list ruleset

If there is no allow rule, add one. When you enable ufw for the first time, if you do not add the SSH allow rule before enabling it, the connection is cut at that moment.

# ufw: allow SSH, then enable
sudo ufw allow OpenSSH
sudo ufw enable

# firewalld: allow the ssh service permanently and apply
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

If you have changed the port to something other than 22, allow it by port number rather than service name (for example, sudo ufw allow 2222/tcp).

Cause 3: sshd is not running, or is listening on a different port

For Connection refused, check the state of sshd and the port it is actually listening on.

# Service status (ssh or sshd depending on the distribution)
sudo systemctl status ssh
sudo systemctl status sshd

# The port and address actually being listened on
sudo ss -tlnp | grep -i ssh

# The final values of the configuration file (a syntax error shows up here)
sudo sshd -t
sudo sshd -T | grep -E "^(port|listenaddress) "

If the ss result shows only 127.0.0.1:22, the ListenAddress setting has disabled listening from outside. Also, on newer versions of Ubuntu (22.10 and later), the standard setup starts sshd through socket activation (ssh.socket), and after changing Port in sshd_config, you may need sudo systemctl daemon-reload and sudo systemctl restart ssh.socket. If you changed the setting but the listening port does not change, check this point.

If you changed the port on the RHEL family, SELinux may refuse listening on the new port. Register the port you use as an SSH port, as in sudo semanage port -a -t ssh_port_t -p tcp 2222.

Cause 4: Your IP is blocked by fail2ban or similar

If you suddenly could not connect after getting the password or key wrong several times, an intrusion-prevention tool such as fail2ban may be blocking your IP.

sudo fail2ban-client status sshd
# If your IP is included, unban it
sudo fail2ban-client set sshd unbanip 198.51.100.20

So that the same thing does not repeat after you unban it, check the key and username you use to connect before trying again.

Cause 5: Packets are not reaching the server

If you have not found the cause by now, look directly on the server side to see whether packets are arriving. Leave the following running in the console and try connecting from outside.

sudo tcpdump -ni any tcp port 22

If nothing is displayed, packets are being stopped before they reach the server. Besides rechecking the cloud firewall, check whether the destination IP address is correct (whether the public IP changed after you stopped and started the instance, or whether the DNS name points to an old IP), and whether the network you are connecting from blocks outbound port 22. Company and public Wi-Fi networks sometimes block outbound SSH. Trying from a different connection, such as smartphone tethering, helps isolate it. You may also be trying to connect over IPv6, so it is also effective to try restricting to IPv4 with ssh -4.

If packets are arriving but there is no response, go back and check the OS firewall or the sshd side.

What to review after recovery

Once you can connect, review the settings to prevent the same problem. The basic measures are switching to public key authentication and disabling password authentication, prohibiting direct root login, and narrowing the source IPs. Changing the port number reduces the attack attempts that show up in the logs, but that alone is not a defense, so combine it with other measures. The sshd defaults and startup methods of each distribution differ by version (as of October 2026), so also check the documentation for the version you use.

Summary

Use the ssh -v message to separate a timeout (not arriving) from a refusal (arriving but not accepted)
The most common cause is the cloud or VPS firewall. Check whether the allowed source IP matches your current IP
For the OS firewall, add the SSH allow rule before enabling it
Check the listening port and address with ss and sshd -T. Watch out for Ubuntu's ssh.socket and for SELinux
Before you start, secure a recovery path other than SSH, such as the console, and keep your existing session

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)