EC2 Connection Timed Out, Refused or Denied: The Fix

Before you change anything, open your terminal and read the exact word in the error. It names the layer that failed. Connection timed out means your packet never reached the instance — that is a network problem, and your key is irrelevant. Connection refused means it did reach the instance and something rejected it — the network is fine, SSH is not listening. Permission denied means SSH answered you and your credentials failed — network and service both fine, it is your username or key. Three different investigations. Almost every guide hands you one checklist of thirty things instead.

Two hours on the wrong half of the problem

Jake's nephew is learning cloud, and he called on a Sunday because his instance had stopped letting him in. He had regenerated his key twice, downloaded it again, changed its permissions, tried a different terminal, and reinstalled his SSH client.

"None of it worked," he said. "I think the instance is broken."

"What does the error actually say?" Ethan asked. "The exact words."

"Connection timed out."

"Then your key was never the problem, and neither was your terminal. Timed out means nothing you sent ever arrived. You've spent two hours fixing the lock on a door your knock never reached."

His home internet had renewed its address that morning. The security group still allowed SSH from yesterday's address. One field, thirty seconds.

"Why did every guide have me checking the key first?"

"Because they list everything that can cause a connection failure, in no particular order. Nobody tells you the error message already eliminated two thirds of the list."

What each word rules out

The technical distinction, because it is worth understanding once rather than memorising three times:

When you connect, your machine sends an opening packet. If something in the network drops it silently, nothing ever replies and your client eventually gives up — that is a timeout. If the packet arrives and the host actively rejects it, you get an immediate refusal — that is "connection refused." The difference between silence and a slammed door.

Notice how much that third column saves you. "Permission denied" is good news — it proves your security group, your subnet, your route table and your SSH service are all working. You got all the way to the front desk. Only your ID was wrong.

"Connection timed out" — the network never let you in

Work down this list in order. It is arranged by how often each one is actually the cause, not by how technical it sounds.

1. Your own IP address changed

If this worked yesterday and fails today with nothing altered on the AWS side, start here. Most home internet connections hand out an address that changes on a reboot or on the provider's own schedule. Your security group rule still allows yesterday's address, and you are no longer at it.

Open the security group, look at the source on the SSH rule, and compare it to your current address. Update it and try again. This is the single most common cause of "it stopped working and I changed nothing," and it wastes an extraordinary number of evenings.

2. The security group never allowed SSH

If this is a new instance and it has never worked, this is your cause. The default security group for a VPC does not allow inbound SSH. People assume a default that permissive exists. It does not, and that is a good thing.

Add an inbound rule for TCP port 22 with your own address as the source. Not 0.0.0.0/0 — see the warning below.

3. There is no public route to the instance

Three things have to be true for an instance to be reachable from the internet, and missing any one produces an identical timeout:

• It has a public IP address. Check you are connecting to that and not the private one — addresses starting 10., 172.16–31. and 192.168. are private and will never answer from your home.
• Its subnet has a route to an internet gateway. A subnet without one is a private subnet by definition, whatever else is configured.
• The instance is running, not stopped, and passing its status checks.

If the instance is genuinely in a private subnet, stop trying to SSH to it and use Session Manager instead. That is the supported answer, not a workaround.

4. The network ACL — where "everything looks correct" lives

This one deserves its own explanation because it defeats people who have checked everything else properly.

A security group is stateful. Allow traffic in, and the reply is automatically allowed out. You do not think about the return journey.

A network ACL is stateless. It filters at the subnet level and it has no memory of what it allowed in. So an inbound rule permitting port 22 is not enough — the reply leaves from a high-numbered ephemeral port, and if your outbound rules do not cover that range, the reply is dropped on the way out.

The symptom is maddening: your packet arrives, the instance answers, and the answer never reaches you. From your side it is indistinguishable from a timeout caused by a closed port.

Most people never touch network ACLs and the default permits everything, so this only bites in environments where somebody has hardened them. If you are in a company account and everything else checks out, this is where to look.

5. Your own network is blocking outbound port 22

Corporate networks, university networks and some public Wi-Fi block outbound SSH entirely. Nothing on the AWS side is wrong and no amount of configuration will fix it.

The ten-second test: try from your phone's hotspot. If it connects there, the problem was never AWS. That single check has saved more hours than any configuration change on this page, and almost nobody thinks to do it first.

"Connection refused" — you arrived, and SSH said no

Good news buried in bad: your entire network path works. Security group, route table, subnet, ACL — all fine, proven by the fact that something answered you. Stop checking them.

The problem is on the instance, and there are four candidates.

It is still booting. The most common cause and the least interesting. An instance can report as running before SSH is ready to accept connections. Wait two minutes and try again before investigating anything.

The SSH service is not running. It crashed, was disabled, or failed to start after a configuration change. You cannot SSH in to fix SSH, which is the joke that stops being funny quickly — use Session Manager or Instance Connect to get a shell another way.

SSH is listening on a different port. If somebody hardened this instance, port 22 may have been moved. Your security group would also need to allow the new port.

A firewall on the instance itself is rejecting you. The operating system has its own firewall, separate from anything in AWS, and a hardened image may block by default. This is a second layer people forget exists because the AWS console gives no hint of it.

And one that catches people at the worst moment: a full disk. A root volume with no space left can prevent services starting, including SSH. If this instance has been running a long time and logs were never rotated, check that before anything clever.

"Permission denied (publickey)" — the good failure

"How is that the good one?" Jake asked.

"Because you got all the way there. Network, routing, firewall, SSH — every one of them worked, and the service replied to you personally. Only your credentials were wrong, and credentials are the cheapest thing on this page to fix."

1. The wrong username — by far the most common

People assume the username is root, or reuse whatever worked on a different image. It varies by image family:

Check the AMI description rather than trusting any list, including this one. It usually states the default user, image conventions change, and a stale list costs you the exact time it was meant to save.

2. Your key file is too readable

SSH refuses to use a private key that other accounts on your computer could read. That is a safety feature, not a bug, and the error can look like a rejection rather than a warning.

On Linux and macOS, set the key to be readable only by you. On Windows, open the file's Properties, go to Security, disable inheritance, and remove every account except your own. The graphical dialog does the job perfectly well — you do not need a command for it.

3. It is simply the wrong key

Easy to do with several instances and several downloads called something like key(2).pem. Check the key pair name shown on the instance's details page and match it to the file you are actually passing.

The two routes that skip SSH entirely

Both are worth knowing before you need them, because the day you need them is the day you cannot get in.

Session Manager — no inbound port at all

The agent on the instance opens an outbound encrypted tunnel, and your session travels back down it. That means no inbound port 22, no public IP address, and no key file. It is the recommended way to reach instances in private subnets, and it needs the agent running and an instance role that permits it.

Ethan's opinion, and he will not soften it: this should be your default, not your fallback. An instance with no inbound SSH port cannot have its SSH port attacked. Most people only discover Session Manager on the day SSH breaks, which is exactly the wrong day to be learning something new.

EC2 Instance Connect — a browser shell, no key file

Pushes a temporary key to the instance for one session and opens a shell in your browser. It needs the relevant package on the instance and port 22 reachable from the service's address range for your Region.

Its best use is diagnostic: if Instance Connect works and your own SSH does not, the instance is fine and the problem is on your side — your key, your client, or your network. That single comparison eliminates half this article in one attempt.

If you have genuinely lost the key

Be clear about this, because people search for a download button that does not exist: AWS never had your private key and cannot give it to you. It was generated once and handed over once.

You are not locked out, though, as long as you still control the account. Use Session Manager if the agent is running. Use Instance Connect if it is available. Failing both, stop the instance, detach the root volume, attach it to a second instance, add your public key to the authorised keys file on it, reattach, and start up. That works, and it is a genuine hour of careful work rather than a trick.

If you are connecting from Windows

Most EC2 tutorials assume you are on Linux or a Mac, which leaves Windows users with a set of failures nobody has described to them. Two of them look like AWS problems and are not.

PuTTY will not accept your key file

AWS gives you a .pem file. PuTTY does not read .pem files — it wants its own .ppk format, and the error it gives you when you try is not especially clear about that.

Convert it with PuTTYgen, which ships alongside PuTTY: load the .pem, save it as a private key, and point PuTTY at the .ppk. Nothing is wrong with your key; it is a format difference and a five-second conversion.

Worth knowing: you may not need PuTTY at all any more. Windows 10 and 11 both include OpenSSH, so you can run ssh straight from Command Prompt, PowerShell or Terminal exactly as the AWS documentation describes. If you are following a guide written for Linux, using the built-in client means every command in it works verbatim — and our guide to opening a Command Prompt properly covers getting there if the terminal is unfamiliar territory.

The key permissions error on Windows

If you use the built-in client, SSH applies the same rule it does on Linux: it refuses a private key other accounts could read. On Windows the fix is not a command — right-click the key file, Properties → Security → Advanced, disable inheritance, remove every entry except your own account, and apply.

People try to translate the Linux permission command literally and get nowhere. There is no direct equivalent; the properties dialog is the equivalent.

Reading the instance's own log without connecting

This is the step almost nobody takes, and on a "connection refused" it frequently answers the question outright.

In the EC2 console, select the instance and look for the option to view its system log or console output. This is what the machine printed while booting, captured by the hypervisor, and you can read it without any network access to the instance at all. No SSH, no key, no security group involvement.

What you are looking for:

• Did it finish booting? A log that stops partway means the instance never reached a state where SSH could start, and no amount of security group work will help.
• Filesystem errors — a root volume that filled up or failed a check will say so here, and that is a common cause of services refusing to start.
• SSH host key messages, which normally appear near the end of a healthy boot. If they are absent, the service did not start.

"So the machine tells you what's wrong," Jake said, "and nobody looks?"

"Nobody looks because it is not where you would think to look. The console feels like where you launch things, not where you read them. But that log is written before any of your configuration matters, which is exactly what makes it trustworthy when everything else is in doubt."

If the boot itself is the problem rather than the connection, that is a different article — but the log is where you find out which of the two you are dealing with, and it takes about a minute.

Questions people actually ask about this

What does connection timed out mean on EC2?

It means your connection attempt never reached the instance at all. Something in the network path dropped it silently, so nothing ever answered. That points at the security group, the network ACL, the route table, or the instance being in a private subnet with no path in. It does not point at your key, your username or SSH itself, so you can stop checking those.

What is the difference between connection timed out and connection refused?

Timed out means your packet was dropped before it arrived and nothing responded. Refused means your packet did arrive, the host answered, and it actively rejected the connection. That single difference tells you which half of the problem to investigate. Timed out is a network problem. Refused means the network is fine and something on the instance is not listening on that port.

Why does my EC2 connection say permission denied publickey?

Because you reached SSH successfully and it rejected your credentials. The network is fine and the service is running. The usual causes are the wrong username for that image, the wrong key file, or a key file with permissions that are too open. Try the username that matches your AMI family before anything else, because that is the most common cause by a distance.

What username should I use to connect to my EC2 instance?

It depends on the image, and guessing wastes time. Amazon Linux commonly uses ec2-user, Ubuntu uses ubuntu, Debian uses admin, and many marketplace images use something specific to that vendor. The AMI description usually states it. If you are unsure, try the family default first, because permission denied with the wrong username looks identical to permission denied with the wrong key.

Why did my EC2 connection stop working when nothing changed?

Your home IP address probably changed. Most consumer internet connections hand out a dynamic address that changes on reboot or on the provider's schedule, and if your security group allows SSH only from your old address the rule no longer matches you. Nothing on the AWS side changed at all. Update the source in the security group to your current address and it works again.

Does the default security group allow SSH?

No. The default security group for a VPC does not permit inbound SSH, which surprises people launching their first instance. You have to add an inbound rule for port 22 with a source that includes your address. Restrict it to your own address rather than opening it to the whole internet, because an SSH port open to everything will be found and attacked within minutes.

What is a network ACL and why does it break connections that look correct?

It is a firewall at the subnet level, and unlike a security group it is stateless. A security group automatically allows the reply to traffic it permitted. A network ACL does not, so you need an outbound rule covering the ephemeral port range for the reply to get back to you. This is the classic case where every setting looks correct and the connection still times out.

How do I connect to an EC2 instance in a private subnet?

Use Session Manager rather than SSH. It works through an outbound encrypted tunnel opened by the agent on the instance, so it needs no inbound port and no public address at all. That makes it the recommended route for private instances and, frankly, the better default for most instances. The alternative is a bastion host, which is more moving parts and more to secure.

What is EC2 Instance Connect and when should I use it?

It lets you open a browser-based shell without managing a key file, by pushing a temporary key to the instance for a single session. It needs the relevant package present on the instance and port 22 reachable from the service address range for your Region. It is useful when you have lost your key but still control the account, and it is a good way to rule out whether your local SSH setup is the problem.

What if I lost my EC2 key pair?

You cannot recover the private key, because AWS never had it. You can regain access another way: use Session Manager if the agent is running, use Instance Connect if it is available, or stop the instance, detach its root volume, attach it to another instance, add your public key to the authorized keys file, and put it back. Say plainly that there is no way to download the original key later, because people waste hours looking.

Why does my connection work and then drop after a few minutes?

That is a different problem from failing to connect, and it usually points at an idle timeout somewhere in the path rather than at SSH. A firewall, NAT device or load balancer between you and the instance may be closing sessions it considers idle. Enabling a keepalive in your SSH client is the normal fix, and it is worth doing before assuming the instance is unstable.

Do I need to reboot my EC2 instance if I cannot connect?

Rarely, and it is worth resisting as a first move. Rebooting hides the evidence and, on an instance with an instance-store volume, can lose data. Work through the layers first. If you do reboot, check the system log afterwards, because a service that fails to start will usually say why there and that log is readable from the console without connecting.

Why is my key file permissions error stopping SSH?

SSH refuses to use a private key that other users on your machine could read, which is a safety feature rather than a bug. Set the file to be readable only by you and the warning disappears. On Windows the equivalent is removing the inherited permissions and leaving only your own account with access, which the graphical properties dialog can do.

How do I check whether the problem is my network or AWS?

Try connecting from a completely different network, such as a phone hotspot. If it works there, the problem is your own network or your security group source address rather than anything on the instance. Corporate and campus networks frequently block outbound port 22 entirely, which produces a timeout that looks exactly like a misconfigured security group.

Should I open SSH to the whole internet to test it?

No, and not even temporarily. An SSH port open to every address is found by automated scanners within minutes and attacked continuously. If you need to rule the security group out, add your own address as a second rule rather than opening it to everything, and if you truly must widen it, narrow it again the moment the test is done.

What it was, in the end

One field. His home connection had renewed its address overnight, and the security group still allowed the old one. Thirty seconds, once he knew which thirty seconds.

"And the two hours before that?"

"Spent on the key, which the error message had already ruled out in its first word."

"So the fix was reading."

"The fix is nearly always reading. Everything else is guessing with extra steps."

Keep the three words. Timed out is the network. Refused is the service. Denied is your key — and it is the best of the three, because it means everything else already worked.

Published 9 August 2026. If you arrived here at the wrong end of a long evening, with something depending on that instance, the thing worth taking away is smaller than it feels right now: three words, and each one clears most of the list away. You have not broken anything. An instance that refuses to let you in is almost never an instance that is lost — and if the key is the part you are worried about, there are three separate ways back in above, none of which need it. Where a detail shifts over time, such as service address ranges, this page points you at where to check rather than handing you a number that will quietly go out of date underneath you. And if your error is not one of these three words, please write in through the contact page and tell us exactly what the screen said. Error text is the one thing we cannot guess at, and the next person searching that exact string will be very glad you did.