Start with the network path, not the password. An SSH timeout means your client sent a connection request and received no response before the connection was established. Verify the hostname and port, test TCP reachability, then check cloud rules, routes, VPN or NAT paths, firewalls, and the SSH service itself.
A timeout normally indicates silent packet dropping or an unreachable destination. It is different from “connection refused,” which means the host answered but no service accepted the port. Work through the layers below in order, using read-only checks before changing access rules.
As an Amazon Associate I earn from qualifying purchases.
What an SSH timeout actually means
OpenSSH uses TCP port 22 by default, but administrators can configure another port. When you run ssh [email protected], the client first resolves the name, chooses an address, and attempts a TCP connection. Authentication does not begin until that connection succeeds. A message such as ssh: connect to host example.com port 22: Connection timed out therefore points to a failure during network establishment, not to an incorrect password or key.
Free tools Windows power users keep installed
One-click scans. No signup required.
Timeout versus connection refused
| Message | What the client learned | Likely layer |
|---|---|---|
| Connection timed out | No response arrived during connection establishment. | Wrong address, missing route, VPN or NAT problem, cloud policy, firewall drop, or a client network blocking the port. |
| Connection refused | The destination was reachable and actively rejected the connection. | Nothing is listening on that port, sshd is stopped, or a firewall is sending a reject instead of silently dropping traffic. |
| Permission denied | The TCP connection and SSH protocol exchange completed. | Account, key, password, or server authorization settings. |
Do not rotate keys or reset passwords while the error is a timeout. First prove that the intended address and TCP port can be reached.
#1 Best Overall
Why ping can work while SSH fails
Ping uses ICMP, whereas SSH uses TCP. A server, cloud network, or corporate firewall can allow ICMP echo requests while dropping TCP 22. The reverse is also possible: ICMP may be blocked even though SSH is reachable. A successful ping proves only that some IP-layer path responds; it does not prove that the SSH port is open.
Before changing a server setting
Record the exact command, destination, port, time, and network from which you are connecting. If a cloud rule must be changed, the source address is essential: a rule for an old home address will not match a laptop currently on mobile data or a VPN.
- Copy the hostname exactly, including any spelling, subdomain, or trailing domain.
- Determine whether the target should be a public address, a private address reachable only through a VPN, or an internal DNS name.
- Find your current public source address from your organization’s network information or a trusted network tool. Do not assume it remains fixed.
- Ask the server owner whether SSH uses port 22 or a custom port. Provider consoles and the server’s SSH configuration are authoritative.
- Keep a second access method available, such as a cloud serial console, provider console, or an existing session, before editing firewall or SSH settings.
Step 1: Confirm DNS, IP address, and SSH port
Resolve the name from the affected client
On Windows, run:
Resolve-DnsName example.comOn Linux or macOS, run:
dig +short example.comCompare the returned address with the server’s current public or private address. A stale DNS record, an address changed after a cloud restart, or a hostname that resolves to an unreachable IPv6 address can all look like an SSH timeout. If DNS returns both IPv4 and IPv6, test each address separately when possible and check whether your VPN or firewall supports the selected protocol.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Specify the port explicitly
Use the known port rather than relying on the default:
ssh -v -p 2222 [email protected]Replace 2222 with the configured value. A common mistake is opening TCP 22 in a security group while sshd listens on another port, or connecting to a custom port that was never forwarded through a router. Do not change the server to a new port merely to experiment; first confirm the intended configuration.
Step 2: Test TCP reachability from the client
Windows: Test-NetConnection
In PowerShell, run:
Test-NetConnection -ComputerName example.com -Port 22Read the TcpTestSucceeded value. True proves that a TCP connection to that address and port completed from this client; it does not prove that the intended SSH account will authenticate. False confirms a reachability problem but does not identify which firewall, route, or policy dropped the packets.
Linux and macOS: netcat
Run:
nc -vz -w 5 example.com 22A successful result means the TCP handshake completed. A timeout means no response was received within the specified wait. A refusal means the destination answered but no listener accepted the port. Some systems use a different netcat implementation; if the -w option is unavailable, omit it and interpret the result from the tool’s output.
Rank #2
Use verbose SSH output after the port test
Run:
ssh -vvv -o ConnectTimeout=10 [email protected]The verbose log shows name resolution, address selection, and the point at which the attempt stops. If it ends while connecting to an address and port, continue with network and firewall checks. If it reaches key exchange or authentication, the original timeout has been cleared and the problem has moved to SSH configuration or credentials.
Step 3: Check routes, VPNs, NAT, and intermediate firewalls
A reachable server still needs a complete forward and return path. Trace the route only as a clue; many routers suppress traceroute responses, so asterisks do not by themselves prove a broken route.
Verify the client’s route
On Windows, use:
tracert example.comOn Linux or macOS, use:
traceroute example.comFor a private address, confirm that the VPN is connected and that its route includes the server’s subnet. Split-tunnel VPNs may send ordinary internet traffic through the local network while omitting the private cloud range. If the target is public, verify that a corporate proxy or egress firewall permits outbound TCP 22.
Check NAT and port forwarding
For a server behind a home, office, or cloud edge router, the public address must forward the selected external TCP port to the server’s private address and listening port. Confirm that the forward points to the current internal address, not a lease that changed. The return traffic must also be allowed. Carrier-grade NAT or a provider that does not supply inbound connectivity can prevent unsolicited SSH connections even when the server itself is healthy.
Recommended Free Tools
Check intermediate security devices
Corporate firewalls, cloud firewalls, VPN gateways, web proxies, and ISP policies can drop TCP 22 without sending an error. Ask the network administrator whether outbound SSH is restricted and whether a source allowlist, proxy, or change request is required. Test from an approved network only; do not bypass organizational controls without authorization.
Step 4: Check cloud security groups, network ACLs, and route tables
AWS instances
For an EC2 instance, inspect all of these layers:
- Security group: Confirm an inbound rule permits TCP on the actual SSH port from the client’s current source address. A narrow single-address rule is safer than opening the port to the entire internet, but it must match the address the packet really uses.
- Network ACL: Because ACLs are stateless, allow the inbound SSH port and the outbound ephemeral return ports required by the client connection. A rule in either direction can cause a timeout.
- Subnet route table: A public instance needs a route to an internet gateway for internet-reachable SSH. A private instance needs a VPN, bastion, or another approved private path; an internet gateway does not make a private address directly reachable.
- Instance address: Verify that the public IPv4 address or assigned hostname still belongs to this instance. A stopped and restarted instance can receive a different public address unless a persistent address is used.
- Additional firewalls: Check host firewalls and any firewall appliances or load-balancer rules between the client and subnet.
Changing only the security group will not repair a missing route, a denied network ACL return path, or a stopped SSH service.
Oracle Cloud instances
Oracle Cloud uses security lists or network security groups together with subnet routing. Confirm that ingress permits TCP 22, the subnet has a reachable route, and the instance is in a public subnet when you are connecting from the public internet. An instance in a private subnet requires an approved private route, VPN, bastion, or other relay. Check the instance’s current public IP rather than relying on an old address.
Rank #3
- Used Book in Good Condition
Other cloud providers
The names differ, but the layers are the same: provider-level ingress policy, subnet ACLs, route tables, public or private addressing, and any edge firewall. Review the provider’s connection details for the exact port and source range, then check the operating-system firewall and sshd listener.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Step 5: Confirm the host firewall and SSH listener
Windows OpenSSH Server
Use an existing console or remote-management session on the Windows host. First check whether the service is running:
Get-Service -Name sshdCheck for a listener on the configured port:
netstat -an | findstr :22A line showing LISTENING on the server’s reachable address indicates that a process has opened the port. A listener bound only to 127.0.0.1 cannot accept connections arriving on the server’s LAN or public interface.
Review Windows Firewall rules:
Get-NetFirewallRule -Name *OpenSSH*If your approved policy requires a new inbound rule, an administrator can create a narrowly scoped TCP rule:
New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server (TCP-In)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22Use the actual configured port instead of 22, and apply a source restriction when your environment supports it. Validate the OpenSSH configuration before restarting anything:
sshd -tIf the service is stopped and you have verified the configuration, start it with Start-Service sshd. External routers, NAT devices, and cloud firewalls still need their own forwarding and allow rules; a Windows Firewall change alone cannot expose a private host to the internet.
Linux OpenSSH Server
Distribution names vary. Check both common service names:
sudo systemctl status ssh
sudo systemctl status sshdInspect listening sockets:
sudo ss -tlnp | grep ':22'Read the effective SSH configuration and validate syntax:
sudo sshd -tLook for the Port and ListenAddress directives in the active configuration. A custom port or a bind address limited to a private interface must match the address and port exposed by the cloud and network layers.
Check the host firewall using the tool enabled on the distribution:
sudo ufw status verbose
sudo firewall-cmd --list-all
sudo nft list rulesetAllow only the intended port and source range. Do not flush firewall rules as a first response; that can expose other services and remove the access path you need to recover the machine.
Step 6: Read SSH and system logs
Once the network path reaches the host, logs can distinguish a stopped service from a policy rejection. On systems using systemd, inspect the current boot:
sudo journalctl -u ssh -b
sudo journalctl -u sshd -bUse the service name that exists on the distribution. Traditional Linux installations may write to /var/log/auth.log or /var/log/secure. On Windows, inspect the OpenSSH operational log in Event Viewer under Applications and Services Logs, then OpenSSH. Also check the system firewall log if logging is enabled.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsIf the host log contains no connection attempt while the client times out, packets likely stop before the host: wrong address, route, cloud policy, NAT, or an upstream firewall. If the log records the attempt, focus on the host firewall, listener binding, or SSH configuration.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Step 7: Test from a second network
Try the same hostname, port, and user from an authorized second path: for example, a trusted VPN, another office connection, or a controlled mobile hotspot. Keep the destination constant so the comparison is meaningful.
- Works elsewhere: The original client network, proxy, ISP, VPN route, or egress firewall is the likely blocking layer. Give the network administrator the destination, port, timestamp, and your source address.
- Fails everywhere: Recheck the address and port, then investigate cloud policy, routing, host firewall, and sshd status from the server side.
- Works only by private address: Public DNS, internet routing, or the public firewall path is wrong; the service itself may be healthy on the private network.
- Works only by public address: The VPN route, private DNS, or internal firewall may be incorrect.
Do not treat a successful test from a different source as proof that the first source should be allowed broadly. Add the smallest approved source range needed for the real client.
Step 8: Use an alternate transport only when supported
Some client networks deliberately block outbound TCP 22. For Git hosting, HTTPS access is often the simplest alternative because it uses the transport the network already permits. GitHub also documents SSH connections over its HTTPS port for supported accounts and configurations.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallFor your own server, an alternate SSH port works only when sshd listens there and every intervening firewall, security group, ACL, NAT rule, and client policy permits it. Moving SSH to another port does not repair a missing route or a private-subnet design, and it must not violate organizational policy. Configure and test the alternate listener through an existing session so the original access path remains available until the new one is proven.
Match the fix to the failing layer
| Evidence | Most likely failing layer | Next action | Access impact |
|---|---|---|---|
| DNS resolves to an old or unexpected address | Destination identity | Correct the hostname, DNS record, or client entry; verify the current provider address. | Read-only until DNS is changed. |
Test-NetConnection or nc times out from one network but succeeds from another |
Client egress, proxy, ISP, or VPN | Request outbound TCP permission, correct the VPN route, or use an approved HTTPS-based method. | Usually no server change. |
| TCP test times out from every network | Cloud policy, route, NAT, host firewall, or stopped listener | Check security groups or ACLs, route tables, forwarding, firewall rules, and service status. | May require administrative changes. |
| TCP test is refused | No process listening or an active reject | Confirm the configured port, start or repair sshd, and inspect firewall behavior. | Server-side change likely. |
| TCP succeeds but verbose SSH stops during authentication | SSH configuration or account authorization | Review keys, allowed users, authentication methods, and SSH logs. | Do not alter network rules. |
| Private address works, public address times out | Public route, public IP, edge firewall, or NAT | Use the approved private path or correct public exposure and forwarding. | Prefer private access where required by policy. |
Common situations and the correct response
“I can ping the server, but port 22 times out”
Run the TCP test from the same device and network, then inspect the cloud ingress rule and host firewall. ICMP reachability does not open TCP 22, so ping alone cannot identify a healthy SSH path.
“The server was reachable yesterday”
Check for a changed public IP after a restart, an expired VPN session, a changed home or office source address, a modified security-group rule, or a stopped sshd service. Compare the current address and policy with the last known working session.
“Only one employee cannot connect”
Compare that user’s resolved address, VPN state, source IP, local firewall, and TCP test with a working employee. A source-specific allowlist or a local network policy is more likely than a server-wide outage.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →“Everyone times out after a firewall change”
Use the provider console or an existing out-of-band session to restore the last known-good rule. Confirm the port, source range, return traffic, and rule order. Avoid broad temporary exposure unless it is approved and time-limited.
“Changing the port did not help”
Changing a client command without changing the server listener and every network policy creates another timeout. Verify the active Port directive, the listener output, cloud rules, ACLs, NAT forwarding, and the client command as one set.
Quick Recap
Safe recovery order
- Write down the exact hostname, resolved address, port, client network, and timestamp.
- Run the TCP test and verbose SSH command from the affected client.
- Confirm the server address, public versus private design, and configured SSH port.
- Check VPN state, routes, NAT, proxy, and outbound firewall policy.
- Check cloud security groups, network ACLs, route tables, and provider address assignments.
- From a console or existing session, verify the host firewall, sshd service, listener binding, configuration syntax, and logs.
- Retest from the original network, then from a second authorized network.
- Only after the path is understood, make the smallest approved rule or routing change and keep a rollback path.
If you prefer an automated Windows-maintenance shortcut after the network checks, Outbyte PC Repair can look for broken system elements, invalid redirects, shared DLL problems, configuration issues, and excess temporary or cache files. It runs on Windows 11, 10, 8, and 7, offers a free trial by category for at least two days before a paid subscription, complements an antivirus rather than replacing one, and results vary; no tool repairs every SSH timeout or crash.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
