Fixing AWS EC2 SSH Connection Timed Out After Launching an Instance

An SSH timeout on a freshly launched EC2 instance is a statement about the network path, not about your key pair or the instance’s SSH daemon. A timeout means your TCP connection attempt received no answer at all. Somewhere between your client and the instance, packets were dropped, never routed, or had no reachable address to travel to. Authentication problems behave differently, because they require a working connection first and usually produce an explicit error such as ‘Permission denied’.

This guide teaches the path as a chain of independent controls and then checks each link in a fixed order: public IP, security group, route table, internet gateway and network ACL. Each check exists because it can fail independently, and each should produce evidence before you change anything. The guide assumes an isolated or non-production environment. Statements about AWS behaviour are general platform knowledge that has not been verified against version-specific documentation in this draft; they are listed for human review in the research metadata.

#Learning Objectives

• Distinguish a timeout from a refusal and from an authentication failure, and explain what each implies about the network path.
• Describe the components in the path from a client to an instance and the trust boundary each one enforces.
• Run read-only checks in a sensible order and interpret the output as evidence.
• Apply a minimal, reversible fix and prove it worked.
• Explain which of these actions need elevated permissions in production and when to escalate.

#Prerequisites

• An isolated or non-production AWS account or VPC where you may launch a disposable instance.
• Permissions to read EC2 and VPC resources and, for the exercise, to edit a security group you own. Confirm these before starting rather than assuming them.
• The AWS CLI configured for that account, and an SSH client. Confirm the CLI and client versions you use, because output formats can differ between releases.
• Basic familiarity with IP addresses, CIDR notation and TCP ports.

#Content

#

The mental model: a path with several gatekeepers

SSH uses TCP, by convention on port 22. For a connection from the public internet to succeed, a sequence of conditions must all hold. The instance needs an address reachable from the internet. Traffic must be permitted to enter at the instance, and the subnet must permit it too. The subnet needs a route that sends internet-bound traffic to an internet gateway. The reply must be able to return along the same path. If any single condition fails, the symptom from your laptop is identical: the client waits, then times out. That is why order and evidence matter. The symptom does not identify the cause.

#

Terminology

• Security group: a stateful virtual firewall attached to an instance’s network interface. Stateful means that if inbound traffic is allowed, the reply is allowed automatically. Rules only allow traffic; there are no explicit deny rules, so unmatched traffic is dropped.
• Network ACL (NACL): a stateless filter attached to a subnet. Stateless means inbound and outbound rules are evaluated separately, so replies need their own allow rule, typically for ephemeral ports. Rules are numbered and evaluated in order and can deny.
• Route table: the set of destination-to-target rules that a subnet uses. A subnet is conventionally called public when its route table sends 0.0.0.0/0 to an internet gateway.
• Internet gateway (IGW): the VPC component that connects the VPC to the internet. It must be attached to the VPC and referenced by a route.
• Public IPv4 address: the internet-routable address that lets outside clients reach the instance. A private address alone is not reachable from the internet.

#

Why the order is public IP, security group, route table, IGW, NACL

The order moves from cheapest and most common to rarer causes, and from the instance outward. A missing public address makes every later check irrelevant, so it comes first. Security group rules are the most frequent cause on a new instance, because a default group often has no inbound SSH rule. Routing and the gateway come next because a subnet without an internet route silently fails. The NACL comes last because default NACLs usually allow all traffic, so it is rarely at fault unless someone has customised it. Treat this ordering as a heuristic, not a law, and keep the evidence from every step.

#

Trust boundaries and least privilege

The security group is your primary boundary. The tempting fix is to allow port 22 from 0.0.0.0/0, which exposes SSH to the entire internet. A safer fix is a single rule for your own source address in /32 form, or access through a managed alternative where your organisation provides one. Residual risk remains even then: your address may change, and a shared address may admit other people. Correctness here includes security, not only connectivity.

#Examples

#

Worked example: reading the evidence

Input: you launch an instance and run ssh -i key.pem ec2-user@203.0.113.10. The command hangs and ends with ‘Connection timed out’. Your first read-only check is the instance description, queried for public address, subnet and security groups. Suppose the output shows a public IP of 203.0.113.10, subnet subnet-EXAMPLE and group sg-EXAMPLE. Interpretation: the address check passes, so you move on. You then read the group’s inbound rules and see only one rule, allowing all traffic from the group itself. Interpretation: that rule admits instances in the same group and nothing from outside, so inbound TCP 22 from your address is dropped. That fully explains the timeout without checking further. You still verify the later layers after the fix, because a second fault could be hiding behind the first.

#

Worked example: a second, hidden fault

After adding a rule for your address, the timeout persists. Evidence from the route table for subnet-EXAMPLE shows only a local route for the VPC range. Interpretation: the subnet has no path to the internet, so even permitted packets cannot reach it or return. The correction is a route for 0.0.0.0/0 targeting the attached internet gateway, once you confirm that this subnet is meant to be public.

#Exercises

#

Exercise: diagnose and fix a disposable instance

Objective: locate and correct the cause of an SSH timeout using ordered evidence. Setup: in a non-production VPC, launch one small disposable instance in a subnet you own, with a new security group that has no inbound rules. Record the group, subnet and instance identifiers in your notes. Do not use shared or production networks.

1. Attempt SSH once and note the timeout. Purpose: this establishes the baseline symptom to compare against later.
2. Run the read-only describe commands in the order listed in the technical section. Purpose: each produces evidence for one control. Write down the result before moving on.
3. Identify the first failing control. Add one inbound TCP 22 rule limited to your own address in /32 form. Purpose: the smallest change that addresses the cause, with the narrowest exposure.
4. Retest. If the timeout persists, return to the evidence and continue down the chain. Change one control at a time so you know which change worked.

Expected evidence: before the change, the group shows no matching inbound rule. After it, SSH either connects or fails with an explicit message, such as a key error, which proves the network path works. Pass condition: the TCP connection is established and the failure, if any, is no longer a timeout. Stop conditions: stop if the resources turn out to belong to a shared or production environment, if you lack permission to edit the group, or if a fix would require opening SSH to 0.0.0.0/0. Escalate to the network owner instead. Cleanup: remove the rule you added, restore any route or ACL you changed to its recorded original state, and terminate the disposable instance and the group you created for it.

#Validation Guidance

Validate with evidence at the layer you changed, then end to end. Run nc -vz against port 22 from your client; success shows the TCP handshake completes, independent of SSH keys. Then run SSH itself. Treat a ‘Permission denied’ result as progress: it proves routing, filtering and addressing are correct, and the remaining issue is the key, the username or file permissions on the key. Confirm that your final rule is as narrow as intended by reading the group again. Record before and after output so a reviewer can see what changed.

Remember that an operating-system firewall or a stopped SSH daemon can also drop or refuse connections, though a refusal usually returns immediately rather than timing out. If all five AWS-side checks pass and you still time out, check whether your own network blocks outbound port 22, and escalate with your collected evidence.

#Common Mistakes

• Opening 0.0.0.0/0 to ‘test’. Cause: impatience. Correction: use your /32 address. Recovery: remove the broad rule immediately and review access logs where available.
• Editing several controls at once. Cause: guessing. Diagnosis: you cannot tell which change helped. Correction: change one thing, then retest. Recovery: revert to your recorded state.
• Assuming a private-only instance is reachable. Symptom: timeout with no public IP. Correction: use an approved access path or assign an address only where policy allows.
• Forgetting NACL statelessness. Symptom: inbound rule exists yet timeout persists. Cause: no outbound allow for return traffic. Correction: add the narrowest matching return rule and record it.
• Blaming the key pair. A wrong key gives an authentication error, not a timeout.
• Changing shared route tables. A route change affects every subnet that uses the table. Check associations first.

#Key Takeaways

• A timeout means no reply, so check addressing, filtering and routing before keys.
• Work in order: public IP, security group, route table, internet gateway, network ACL, recording evidence at each step.
• Prefer a /32 source rule over opening SSH to the world, and accept that residual risk remains.
• In production, request changes through the owner of the network, because route and ACL edits can affect other workloads.

Before you close the work, verify three things: the TCP handshake to port 22 succeeds, the security group contains only the rule you intended, and routes and ACLs match the state you recorded. If any change must be undone, remove the added rule or restore the recorded route first, retest, and only then decide whether to escalate with your evidence.