SSH connections to a self-hosted server fail when the public IP cannot reach the internal service, typically due to misconfigured port forwarding, restrictive firewall rules, or ISP-level blocking of standard ports. This guide provides a systematic troubleshooting workflow to restore external access by verifying network topology, router configuration, and host security settings.
Verify Your Public IP Address
The first step is confirming that you are actually connecting from an external network and that your client knows the correct destination address. Many users attempt to connect using their local private IP (such as
192.168.1.x) while outside their home network, which will always fail because private addresses are not routable on the internet. To verify your current public IP, visit a service like
ifconfig.me or
whatismyipaddress.com from the machine attempting to connect. If this IP matches the one displayed in your router’s WAN status page, you have the correct target address. If they differ, you may be behind a Carrier-Grade NAT (CGNAT), which prevents direct port forwarding entirely. In such cases, you must use a tunneling solution like Tailscale or ZeroTier instead of traditional port forwarding.
Configure Router Port Forwarding Correctly
Port forwarding directs traffic arriving at your router’s public interface to the specific internal IP address of your server. Log into your router’s administrative interface, usually found at
192.168.1.1 or
192.168.0.1, and locate the Virtual Server, Port Forwarding, or NAT section. Create a new rule that maps an external port to the internal SSH port (default 22). For example, if your server’s internal IP is
192.168.1.50, you might forward external port 2222 to internal port 22 on that IP. Save the configuration and restart the router if necessary. It is critical to ensure that the internal IP assigned to your server is static; otherwise, DHCP changes may break the forwarding rule after a reboot.
Check Host Firewall Rules
Even with perfect port forwarding, the operating system on your server may block incoming connections. On Linux systems, check the status of
ufw (Uncomplicated Firewall) or
iptables. If
ufw is enabled, allow SSH traffic by running
sudo ufw allow ssh or specifying the port explicitly with
sudo ufw allow 22/tcp. On Windows servers, ensure that the Windows Defender Firewall allows inbound connections on the SSH port. You can verify this by temporarily disabling the firewall for testing purposes only, but remember to re-enable it and create a proper exception rule afterward. A common mistake is allowing SSH on localhost but forgetting to permit it on the public interface.
Address ISP Blocking and CGNAT
Many residential Internet Service Providers block port 22 to prevent users from running public-facing servers, citing security concerns or bandwidth management policies. If your port forwarding is configured correctly but connections still time out, try changing the external port in your router settings to a non-standard number, such as 2222 or 443, and map it to internal port 22. When connecting, specify this custom port explicitly:
ssh -p 2222 user@your_public_ip. If this works, your ISP is likely blocking standard SSH ports. Alternatively, if you are behind CGNAT, as mentioned earlier, standard port forwarding will never work, and you should switch to a virtual private network overlay tool.
Test Connectivity Step-by-Step
Use diagnostic tools to isolate where the connection breaks down. From an external machine, run
telnet your_public_ip 22 or
nc -vz your_public_ip 22 to test basic TCP connectivity. If the connection is refused, the server is reachable but the SSH service is down or the firewall is blocking it. If the connection times out, the packet is being dropped somewhere between the internet and your router, indicating a port forwarding or ISP issue. If successful, proceed to test the actual SSH handshake with verbose output:
ssh -vvv user@your_public_ip. This detailed log will show exactly where the authentication or protocol negotiation fails.
For more details on managing SSH keys securely, see
Closing SSH Connection with Keygen. If you recently changed routers, refer to
Unable to Access Internet after Changing Router: Troubleshooting SSH Connection in Proxmox.
Frequently Asked Questions
Why does SSH work locally but not remotely?
This discrepancy usually indicates that port forwarding is missing or incorrect on your router, or that your local network uses a different routing table. Ensure your router forwards the external port to the server's specific local IP address. Additionally, verify that the server's firewall allows connections from the LAN interface, not just localhost.
Can I use Dynamic DNS for my SSH connection?
Yes, Dynamic DNS (DDNS) is highly recommended for home servers with changing public IPs. Configure your router to update a DDNS provider like No-IP or Dynu automatically. Then, connect using the domain name instead of the IP address, ensuring your router updates the record whenever the ISP assigns a new IP.
What if my ISP blocks port 22 completely?
If port 22 is blocked, change your router's port forwarding rule to map an external high-numbered port (e.g., 2222) to internal port 22. Connect using
ssh -p 2222. If all outbound ports are blocked, consider using SSH over HTTPS (port 443) or a tunneling service like Cloudflare Tunnel to bypass ISP restrictions.
How do I know if I am behind CGNAT?
Compare your public IP shown on
whatismyip.com with the WAN IP listed in your router’s status page. If they do not match, you are behind CGNAT. Standard port forwarding will not work in this scenario, and you must use a VPN-based solution or contact your ISP for a static public IP assignment.
Is it safe to expose SSH directly to the internet?
Exposing SSH directly carries risks such as brute-force attacks. Mitigate these risks by disabling password authentication and using key-based login only. Install fail2ban to automatically ban IPs with repeated failed attempts, and consider changing the external port to a non-standard number to reduce automated scanning noise.