SSH Connection Timeout

Last updated: April 2026

A connection timeout means RockTerm sent a TCP SYN packet but never received a response. Unlike "Connection refused" (which returns an immediate RST), a timeout indicates that packets are being silently dropped or never reaching the destination. This article covers the most common causes and how to diagnose each one.

1. DNS Resolution Delays

If the hostname takes a long time to resolve — or fails to resolve entirely — the connection will appear to hang before timing out. This is especially common in environments with misconfigured DNS servers or split-horizon DNS issues.

Test DNS Resolution

From Windows PowerShell:

Resolve-DnsName server.example.com

From a command prompt or Linux terminal:

nslookup server.example.com

If resolution is slow (more than a few seconds) or returns an error, the issue is DNS-related. Possible fixes:

• Use the IP address directly in RockTerm instead of the hostname to bypass DNS entirely.
• Check your DNS server configuration in your network adapter settings.
• Try an alternative DNS server (e.g., nslookup server.example.com 8.8.8.8) to rule out a problem with your primary DNS server.
• Flush your local DNS cache: ipconfig /flushdns (Windows) or sudo systemd-resolve --flush-caches (Linux with systemd-resolved).

2. Network Routing Issues

Even if DNS resolves correctly, packets may not reach the destination due to routing problems, asymmetric routing, or black holes in the network path.

Trace the Route

From Windows:

tracert server.example.com

From Linux:

traceroute server.example.com

Examine where the trace stops or where you see * * * (request timed out). The last responding hop is usually the point closest to the problem. Common findings:

• Trace stops at your default gateway: local routing issue, check your gateway and subnet configuration.
• Trace stops at an intermediate router: a routing policy, ACL, or link failure at that hop.
• Trace completes but SSH still times out: a host-level firewall is dropping SSH specifically (ICMP used by traceroute may be allowed while TCP 22 is not).

Test TCP Connectivity Directly

From Windows PowerShell:

Test-NetConnection -ComputerName server.example.com -Port 22

If TcpTestSucceeded returns False but PingSucceeded returns True, a firewall is specifically blocking TCP port 22.

3. Reverse DNS Lookup by sshd

By default, many SSH server configurations perform a reverse DNS lookup on the connecting client's IP address. If the reverse lookup is slow or fails (common with private IPs or misconfigured PTR records), the login prompt will be delayed by 10–30 seconds or more. This appears to the user as a timeout or a very slow connection.

Fix: Disable UseDNS on the Server

Edit /etc/ssh/sshd_config on the remote host:

UseDNS no

Then restart the SSH service:

sudo systemctl restart sshd

This has no security impact in most environments. The UseDNS option was historically used to enable hostname-based access control in authorized_keys and sshd_config, but IP-based controls are more reliable.

4. Firewall Silently Dropping Packets (DROP vs. REJECT)

Firewalls can be configured to either REJECT or DROP unwanted traffic:

• REJECT sends an ICMP unreachable or TCP RST back to the client, producing an immediate "Connection refused" error.
• DROP silently discards the packet with no response, causing the client to wait until its connection timeout expires.

If you suspect a firewall DROP rule is responsible:

• Check the host firewall: sudo iptables -L -n -v (look for DROP rules on port 22).
• Check cloud security groups (AWS, Azure, GCP) for missing inbound rules.
• Check intermediate firewalls (Cisco ASA, Palo Alto, etc.) by reviewing deny logs and access-list hit counts.

5. RockTerm Connection Timeout Settings

RockTerm has a configurable connection timeout that controls how long it waits for the initial TCP handshake to complete.

1. Open Settings > Connection.
2. Adjust the Connection Timeout value. The default is 30 seconds.
3. For hosts on high-latency networks (satellite links, international WAN), consider increasing this to 60 or 90 seconds.

Note: Increasing the timeout does not fix the underlying problem — it only gives the connection more time to succeed. If connections are consistently slow, investigate the network path.

6. Session Keepalive for Idle Disconnections

If your SSH sessions connect successfully but disconnect after a period of inactivity, the issue is not a connection timeout but an idle timeout. Stateful firewalls, NAT devices, and load balancers often drop idle TCP connections after a period (commonly 5–15 minutes).

Client-Side Keepalive (RockTerm)

Configure RockTerm to send periodic keepalive packets:

1. Open the connection profile for the target host.
2. Under Connection > Keepalive, enable Send keepalive packets.
3. Set the Interval to 60 seconds (or lower if your firewall has an aggressive idle timeout).

This is equivalent to setting the following in an OpenSSH ~/.ssh/config file:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

This sends a keepalive message every 60 seconds. If 3 consecutive keepalives receive no response, the client disconnects (total dead-peer detection time: 180 seconds).

Server-Side Keepalive

You can also configure the SSH server to send keepalives. In /etc/ssh/sshd_config:

ClientAliveInterval 60
ClientAliveCountMax 3

Restart sshd after making changes. Using both client-side and server-side keepalives provides the most robust protection against idle disconnections.

NAT and Firewall Idle Timeouts

If you manage the network infrastructure, you can also adjust the idle timeout on the stateful device itself. For example, on a Cisco ASA:

timeout conn 1:00:00

This sets the idle connection timeout to 1 hour. On a Linux firewall using conntrack:

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7200

Diagnostic Summary

• Timeout on initial connect: DNS, routing, or firewall DROP rule.
• Slow connect (10–30 second delay) then succeeds: reverse DNS lookup on the server (UseDNS).
• Connects fine, drops after idle period: stateful firewall idle timeout; enable keepalives.
• Intermittent timeouts: network instability, packet loss, or overloaded intermediate device.

← Back to Support Articles

Still need help?

If you're still experiencing issues, contact us or email info@rockriverresearch.com.