01
Start with the resolved endpoint
Print the effective configuration and compare the hostname, port, and proxy path with the intended server. A stale alias can point to an old address while the key and current server are both correct.
Then make one verbose attempt with a short connection timeout. Keep the relevant ending of the log and its timestamp. ConnectTimeout is useful for setup and initial protocol negotiation; it is not a runtime limit for a command after authentication.
ssh -G app-server
ssh -v -o ConnectTimeout=5 -o ConnectionAttempts=1 app-server02
Interpret refusal and silence differently
An immediate Connection refused suggests that the endpoint actively rejected the TCP attempt, often because nothing is listening there. A timeout can have several causes, including a network path that drops traffic. Neither result establishes a password or public-key problem.
Our closed test port immediately refused the connection. A different test listener accepted TCP but never spoke SSH; the client timed out during banner exchange. A successful TCP probe alone therefore did not prove that the endpoint was a working SSH service.
# OpenBSD/macOS-style netcat; check nc options on your platform.
nc -vz -w 5 server.example.com 2203
Inspect the server through an independent access path
When a console or existing authorized session is available, inspect the SSH listener and service logs without restarting blindly. On Linux, ss -ltn can show whether the expected port is listening and on which address.
Our real daemon was on a third port and authenticated successfully with the unchanged key. Comparing the three endpoints prevented a banner failure from being mistaken for a rejected identity.
# Linux server console:
ss -ltn
# Ubuntu example; service naming differs across distributions.
sudo journalctl -u ssh --since '10 minutes ago' --no-pager04
For a cloud host, follow the actual network path
For EC2 specifically, AWS directs users to check such components as the instance state, the source allowed by the security group, routes, and network ACLs. A changed client public IP can invalidate a previously narrow source rule.
Apply that guidance only to the network you are using. A private host reached over VPN or a jump host follows a different path from a public instance. Verify the actual source and target before changing a rule; opening SSH to every address is not a diagnostic requirement.
05
Verify the repaired stage, then continue forward
Repeat the same bounded command after the narrow repair. Confirm that it advances past the prior failure, and then test authentication separately. Reaching a public-key rejection is progress beyond a silent transport failure, even though the login still needs work.
Keep the old and new endpoint values and log endings in the investigation notes. If the only change was a different key but the timeout remains before authentication, revisit the evidence rather than cycling through more credentials.
Know the limits
The lab compares a closed port, a TCP listener that sends no SSH banner, and a working SSH daemon. It does not reproduce an EC2 security group, a real packet-drop firewall, or every possible timeout cause.
Sources & further reading
A technical publication by CoreTrailKit.
Browse all articles