EC2 Instance Connect "Error Establishing SSH Connection": Every Cause, Fixed (Prefix List, Endpoint, RHEL)

"Failed to connect to your instance. Error establishing SSH connection to your instance. Try again later." is what the EC2 console says when its browser-based EC2 Instance Connect client cannot reach your instance on port 22. Trying again later almost never helps, because the cause is one of five fixed things: the instance has no public IP, the security group does not allow SSH from the EC2 Instance Connect prefix list for your Region, the instance's operating system does not have the Instance Connect package, your IAM identity cannot push a key, or the browser itself is blocked from AWS's proxy. Here is the part that surprises almost everyone: a security group rule that allows SSH from your own IP address does nothing for this button. The console connects from AWS's own address range, not from your laptop, and it needs its own rule.

Jake runs a phone repair shop, and the booking page for it lives on one EC2 instance that Ethan set up. Jake can log in to the AWS console, he can see the instance, and the big orange Connect button is right there. He pressed it, chose the EC2 Instance Connect tab, and got the error above, three times, with a minute between each try because the message told him to. His security group already allowed SSH from his home IP, which Ethan had added months earlier so Jake could use a terminal. That rule was the reason it looked fine and the reason it was not. This page is the order Ethan walked him through, from the two-minute checks that find which of the five things is wrong, to each fix, to the quieter option when the instance has no public address at all.

What the button actually does, and why your own IP rule is irrelevant

EC2 Instance Connect is not a magic door in the console. When you click Connect, the EC2 Instance Connect service generates a one-time SSH key pair, pushes the public half to your instance's metadata where it lives for 60 seconds, and then opens an SSH session to port 22 of your instance from AWS's own servers, relaying it to your browser over a WebSocket on port 443. On the instance, the SSH daemon has been told to look up keys with a small script, eic_run_authorized_keys, which reads that metadata, finds the fresh key, and lets the session in.

Read that again and the error explains itself. The SSH connection comes from AWS, not from your laptop. So the security group rule that lets you in on port 22 is the wrong rule for this button; the instance needs to allow port 22 from the EC2 Instance Connect service's address range, which AWS publishes as a managed prefix list per Region. The instance needs a public address, because the service reaches it over the internet. The operating system needs the script that reads keys from metadata. And you need permission to push the key in the first place. Miss any one of those and the console shows the same two sentences and tells you to try again later.

There is one more quiet requirement. The browser side of the session goes to prod.REGION.oneclickv2-proxy.ec2.aws.dev on port 443. A corporate VPN or an aggressive firewall that blocks that hostname kills the connection before the instance is ever involved, and the error looks identical.

Jake: "But I can SSH in from my laptop. The port is obviously open."

Ethan: "Open to you. The button is not you. It is an AWS server knocking from an address your rule has never heard of, and that is the whole bug."

Five checks, two minutes, before you change anything

Work through these in order. Each one takes seconds and each one rules out one of the five causes.

1. Is the instance running and healthy? On the Instances page, the state must be running and the status check column must read 2/2. A freshly launched instance can take a few minutes to accept connections; a failed status check means the operating system itself is the problem.
2. Does it have a public address? On the Details tab, look for a public IPv4 address or an IPv6 address. If both are empty, the console client cannot reach it, and you want the Instance Connect Endpoint section below rather than any security group change.
3. Does the security group allow SSH from the prefix list? On the Security tab, look at the inbound rules. You are looking for port 22 with a source that reads pl- something and a description naming com.amazonaws.REGION.ec2-instance-connect. A source of your own IP, or even 0.0.0.0/0, is a different rule; the second one happens to work, and the first one does not.
4. Which operating system is it? Check the AMI name on the Details tab. Amazon Linux 2023 and Ubuntu 20.04 or later are fine. RHEL, CentOS Stream, Debian, Rocky, and older Ubuntu images do not ship the package.
5. Can you push a key? From a terminal with the same identity, run aws ec2-instance-connect send-ssh-public-key as shown in the CLI section. An AccessDenied here is an IAM problem, not a network one.

Jake's answer was in step three. His rule said port 22 from one home address, which is exactly right for a laptop and exactly wrong for the button.

The security group rule the console actually needs

AWS manages the address ranges its services use as prefix lists, and the EC2 Instance Connect service has one per Region, in two flavors. For IPv4 the name is com.amazonaws.REGION.ec2-instance-connect, and for IPv6 it is com.amazonaws.REGION.ipv6.ec2-instance-connect; in US East (N. Virginia) the IPv4 one is com.amazonaws.us-east-1.ec2-instance-connect. You never type the addresses. You pick the list as the source of a rule, and AWS keeps it current.

1. In the EC2 console, open Security Groups and select the group attached to the instance, or create a new one just for this.
2. Choose Edit inbound rules, then Add rule.
3. For Type, choose SSH. The port fills in as 22.
4. For Source, leave Custom, click into the field, and type ec2-instance-connect. Pick the prefix list for the Region the instance is in. If your users connect over IPv6, add a second rule with the ipv6 list.
5. Save. There is nothing to restart; security groups apply immediately.

Keep your own-IP rule if you also SSH from a terminal. The two rules do different jobs and live happily side by side. What you do not need is 0.0.0.0/0 on port 22; it works, because it allows everything, and it leaves the instance answering SSH to the whole internet to fix a problem that one prefix list solves. If your security group is in a different Region from the instance, the prefix list you picked is for the wrong Region, and the rule is silently useless.

Jake: "So the fix was one rule, picked from a dropdown."

Ethan: "One rule. And now you know why the console said try again later: it had no way of telling you that the door it was knocking on was locked only to it."

No public IP: why the console client cannot help, and what can

The browser client connects over the internet, so the instance must have a public IPv4 or IPv6 address and sit in a subnet whose route table sends traffic to an internet gateway. An instance that Ethan deliberately placed in a private subnet, which is the sensible place for most servers, has neither, and the console's Connect using a Public IP option will fail every time with the same two sentences. AWS also charges for every public IPv4 address now, which is one more reason not to add one just for a login.

Two things worth knowing before you go hunting for an Elastic IP. First, the default public subnet AWS creates routes IPv4 to the internet but not IPv6, so an instance with only an IPv6 address needs a ::/0 route added by hand. Second, the fix for a private instance is not a public address at all. It is an EC2 Instance Connect Endpoint, which lets the console and the CLI reach a private IP without a bastion host and without the VPC having any internet connectivity. That is its own section below, and it is the one Ethan chose for Jake's second server.

The operating systems that have it, and installing it on the ones that do not

The console button only works if the instance's SSH daemon knows to look for keys in metadata, which the ec2-instance-connect package sets up. AWS preinstalls it on the Amazon Linux 2023 standard image, Amazon Linux 2 from version 2.0.20190618 onward, Ubuntu 20.04 and later, and recent macOS images. Everything else needs a manual install, which means you need some other way in first: an SSH key pair from launch time, Session Manager, or the serial console.

On RHEL and CentOS Stream the package is two RPMs, one for the scripts and one for SELinux, from AWS's download bucket. Pick the OS version and the CPU architecture; this is the RHEL 9 x86_64 pair.

mkdir /tmp/ec2-instance-connect
curl https://amazon-ec2-instance-connect-us-west-2.s3.us-west-2.amazonaws.com/latest/linux_amd64/ec2-instance-connect-2.0.0-5.rhel9.x86_64.rpm -o /tmp/ec2-instance-connect/ec2-instance-connect.rpm
curl https://amazon-ec2-instance-connect-us-west-2.s3.us-west-2.amazonaws.com/latest/linux_amd64/ec2-instance-connect-selinux-2.0.0-5.noarch.rpm -o /tmp/ec2-instance-connect/ec2-instance-connect-selinux.rpm
sudo yum install -y /tmp/ec2-instance-connect/ec2-instance-connect.rpm /tmp/ec2-instance-connect/ec2-instance-connect-selinux.rpm

For RHEL 8 swap rhel9 for rhel8; for ARM instances swap linux_amd64 for linux_arm64 and x86_64 for aarch64. If the instance reaches the internet through a proxy, export http_proxy and https_proxy in the shell first, or the downloads hang.

Whatever the OS, the proof that it worked is in the SSH daemon's configuration. On Amazon Linux it is in /etc/ssh/sshd_config; on RHEL 9 and CentOS 9 in /etc/ssh/sshd_config.d/60-ec2-instance-connect.conf; on RHEL 8 and Ubuntu in a systemd drop-in under the ssh service. You are looking for two lines.

AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys %u %f
AuthorizedKeysCommandUser ec2-instance-connect

Here is the catch that bites people who have hardened their servers. If AuthorizedKeysCommand was already set to something else, for a corporate key server say, the Instance Connect installer leaves it alone, and Instance Connect simply never works on that machine. There is room for only one key-lookup command in sshd, and if yours is taken, this feature is not for that instance; use your key pair or Session Manager instead.

Ubuntu has a special case worth a line: AWS's own troubleshooting page says that if Instance Connect fails on an Ubuntu instance, the ec2-instance-connect package may simply be out of date, and apt update && apt upgrade from another way in fixes it.

The permission that pushes the key

Everything the console does on your behalf, it does with your IAM identity. Pushing the one-time key is the action ec2-instance-connect:SendSSHPublicKey, and the console also needs ec2:DescribeInstances to show you the instance, plus ec2:DescribeVpcs if you connect over IPv6. The interesting part is the condition key ec2:osuser: a policy can say "this person may push keys only for the user ec2-user", and if you then type root or ubuntu in the username box, the push is denied and the console shows you the same unhelpful error.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2-instance-connect:SendSSHPublicKey",
      "Resource": "arn:aws:ec2:us-east-1:111122223333:instance/i-1234567890abcdef0",
      "Condition": { "StringEquals": { "ec2:osuser": "ec2-user" } }
    },
    {
      "Effect": "Allow",
      "Action": ["ec2:DescribeInstances", "ec2:DescribeVpcs"],
      "Resource": "*"
    }
  ]
}

Name the instances you mean. A policy with Resource: * lets that person push a key to every instance in the account, which is rarely what anyone intended. Tags work too: a condition on aws:ResourceTag/Environment lets a developer reach the dev instances and nothing else. The Describe actions have to stay on *, because those API calls do not support resource-level permissions.

The clean test for IAM is the CLI, because it fails loudly where the console fails vaguely. Push a key by hand and read the answer.

ssh-keygen -t ed25519 -f my_key
aws ec2-instance-connect send-ssh-public-key --region us-east-1 --availability-zone us-east-1a \
  --instance-id i-1234567890abcdef0 --instance-os-user ec2-user --ssh-public-key file://my_key.pub

An AccessDeniedException here is your answer. A success means IAM is fine and the problem is network or operating system, and you now have 60 seconds in which ssh -o IdentitiesOnly=yes -i my_key ec2-user@PUBLIC-DNS will work from your own terminal, which is a useful second test of the instance side.

The username box, and the rules nobody reads

The console fills in ec2-user and most people never touch it. If your image is Ubuntu, the user is ubuntu; Debian is admin; Rocky is rocky; Bitnami images are bitnami; RHEL accepts ec2-user or root. A wrong username means the key is pushed for a user whose authorized keys sshd never consults, and the login fails after everything else succeeded. The name also has to follow Instance Connect's own rules: a letter, digit or underscore first, up to 31 characters, and only letters, digits, @ . _ - after that.

Jake: "Why would I change the username at all?"

Ethan: "You would not, on Amazon Linux. The day you launch an Ubuntu image and leave it on ec2-user is the day you will remember this paragraph."

Connecting from the AWS CLI instead of the browser

If you have AWS CLI version 2, you can skip the console and let the CLI do the same key push and the SSH in one line. The ssh subcommand is v2 only, so a v1 install reports it as unknown.

aws ec2-instance-connect ssh --instance-id i-1234567890abcdef0
aws ec2-instance-connect ssh --instance-id i-1234567890abcdef0 --connection-type eice
aws ec2-instance-connect ssh --instance-id i-1234567890abcdef0 --private-key-file /path/to/key.pem

By default the CLI tries the public IPv4 address directly, then the private IPv4 address through an Instance Connect Endpoint, then IPv6 directly. AWS warns that the default order may change, so if you care which path is used, say so with --connection-type direct or eice. One detail for the direct path: now the connection is from your machine, so the security group needs port 22 from your IP, and the prefix list rule is the one that does not apply. Two buttons, two rules.

Your own key works too. Push its public half with send-ssh-public-key as above, then SSH within 60 seconds, and add -o IdentitiesOnly=yes so the client does not wander through every key in your agent first. RSA at 2048 or 4096 bits and ED25519 are accepted. If the instance has only a private address and you have Direct Connect, a VPN or VPC peering to reach it, this method works over that private path as well; the key push goes to the Instance Connect service endpoint over the internet, the SSH goes over your private route.

One thing the console and the CLI share: once the SSH session is open, it stays open until you end it, even after your IAM credentials expire. If you need sessions to die on their own, wrap the command, timeout 3600 ssh ..., and remember that processes you started keep running after the session ends.

EC2 Instance Connect Endpoint: reaching a private instance with no public IP and no bastion

This is the fix for the private subnet, and it is the one most people have not met yet. An EC2 Instance Connect Endpoint is an identity-aware TCP proxy that AWS places inside your VPC. You create one endpoint in one subnet; it gets a network interface there; and from then on the console and the CLI can open SSH, or RDP for Windows, to any instance the endpoint can route to, using its private address. The instance needs no public IP. The VPC needs no internet gateway. Every connection, successful or not, lands in CloudTrail. And there is no charge for the endpoint itself, only the usual data transfer if the endpoint and the instance are in different Availability Zones.

The limits are small and worth knowing before you plan around it: one endpoint per VPC, one per subnet, five per Region, 20 concurrent connections per endpoint, and a connection lasts at most one hour. It is meant for management traffic, and AWS says it throttles bulk data transfer through it.

1. In the VPC console, open Endpoints, choose Create endpoint, and pick the EC2 Instance Connect Endpoint type. Choose the VPC, a subnet, and a security group for the endpoint. A service-linked role is created for you the first time.
2. Give the endpoint's security group an outbound rule: TCP 22 to the instances' security group, or to the VPC's CIDR. Inbound rules on the endpoint do not matter; traffic to it comes from the service and is allowed regardless.
3. Give the instances' security group an inbound rule: TCP 22 from the endpoint's security group. With no other SSH rules, the instances now accept SSH only through the endpoint, which is a quietly excellent place to end up.
4. Wait for the endpoint to reach create-complete.
5. In the EC2 console, select the instance, choose Connect, the EC2 Instance Connect tab, and this time Connect using a Private IP. Pick the endpoint, check the username, set a tunnel duration, and connect.

From a terminal, the endpoint works as an SSH proxy with your own key, which is how Ethan uses it day to day.

ssh -i my-key-pair.pem ec2-user@i-1234567890abcdef0 \
  -o ProxyCommand='aws ec2-instance-connect open-tunnel --instance-id i-1234567890abcdef0'

# or listen locally and connect as many times as you like
aws ec2-instance-connect open-tunnel --instance-id i-1234567890abcdef0 --local-port 8888
ssh -i my-key-pair.pem ec2-user@localhost -p 8888

# Windows instances: tunnel RDP instead
aws ec2-instance-connect open-tunnel --instance-id i-1234567890abcdef0 --remote-port 3389 --local-port 5555

With your own key pair you can use any Linux image at all, because the key is yours and nothing on the instance needs to read metadata. Only the console route and the keyless CLI route need the Instance Connect package installed. Two endpoint-specific failures to recognize: the endpoint's IP type must match the instance's, so an IPv4-only endpoint cannot reach an IPv6-only instance, and if your IAM policy sets a maxTunnelDuration condition, you must pass --max-tunnel-duration on the command or you get AccessDeniedException for a reason that has nothing to do with the instance.

Client IP preservation is the one setting worth a decision. Off, which is the default, every connection appears to the instance to come from the endpoint's own address, so the instance's rule can simply allow the VPC range or the endpoint's security group. On, the instance sees your real client address, which is nice for audit, requires the instances to be in the same VPC as the endpoint, does not work on a handful of old instance families or through a transit gateway, and means the instance's inbound rule must allow your clients' public addresses instead.

Jake: "So the second server never needed a public address at all."

Ethan: "Never. It has one endpoint in front of it, one rule that trusts that endpoint, and nothing else on port 22. That is the setup I would have started with if the console had let me."

The quieter causes when the five big ones check out

Your browser cannot reach AWS's proxy. The console session rides a WebSocket to prod.REGION.oneclickv2-proxy.ec2.aws.dev on port 443, and a corporate VPN, a proxy allow-list, or a privacy extension can block it. Try from a personal network or a different browser before touching the instance; if it works there, the instance was never the problem.

Rotated host keys. If you regenerated the instance's SSH host keys, the console's client fails host key validation because the new keys were never uploaded to AWS's trusted database. Connect another way and run eic_harvest_hostkeys, which lives in /opt/aws/bin/ on Amazon Linux and /usr/share/ec2-instance-connect/ on Ubuntu. It prints nothing on success.

The SSH daemon itself. A full root volume, a broken sshd_config edit, or an instance that failed its status checks will refuse every method equally. The EC2 serial console or Session Manager are the ways in that do not depend on sshd.

A managed instance. Instances that EC2 itself manages on behalf of another service show Managed: true on their details, and user-initiated connections to them are not allowed at all. No rule will change that.

A network ACL. Security groups are stateful; network ACLs are not. A subnet ACL that allows inbound 22 but blocks outbound ephemeral ports 1024 to 65535 lets the SYN in and drops the reply, which looks exactly like a timeout.

The wrong Region in the address bar. The prefix list, the endpoint and the security group are all regional. A console tab that drifted to another Region shows you an instance that does not exist, or rules that do not apply.

What EC2 Instance Connect is, in one honest paragraph

If you came here asking what EC2 Instance Connect is before asking why it failed, here is the short version. It is a way to open an SSH session to a Linux instance without managing a long-lived key pair: AWS mints a key that lives for one minute, your IAM policy decides who may do that and for which instances and usernames, and every push is an API call that CloudTrail records. Compared with a .pem file in a shared drive, that is a real improvement, which is why the console makes it the first tab. It is still SSH underneath, so port 22 still has to be reachable from wherever the session starts, and the instance still needs a working SSH daemon. Session Manager is the other AWS way in; it uses no SSH and no open port at all, needs the SSM Agent and an instance role instead, and is the better default for a whole fleet. Instance Connect is the better fit for the one server you want to reach from a browser in ten seconds.

Windows instances, and connecting from a Windows laptop

Two different questions hide behind "EC2 Instance Connect Windows". If your laptop is Windows, nothing changes: the console button is a browser, and the CLI route needs AWS CLI version 2 plus the OpenSSH client that Windows 10 and 11 include. If the instance is Windows, the browser client does not apply, because it is an SSH client and a Windows instance speaks RDP. What you can do is reach a private Windows instance through an EC2 Instance Connect Endpoint: open a tunnel to port 3389, point your RDP client at localhost and the local port, and sign in with the administrator password you decrypted with your key pair.

aws ec2-instance-connect open-tunnel --instance-id i-1234567890abcdef0 --remote-port 3389 --local-port 5555
# then connect your RDP client to localhost:5555

The endpoint's security groups need port 3389 in that case rather than 22, and the one-hour tunnel limit applies to RDP just as it does to SSH.

What any of this costs

EC2 Instance Connect has no price. The browser client, the key push, the CLI commands and the Instance Connect Endpoint are all free of charge. What you pay for are the things around them. A public IPv4 address on a running instance is billed by the hour, and for Jake's small server that charge alone is a reason to prefer the endpoint over "just give it a public IP so the button works". An endpoint reaching an instance in a different Availability Zone pays the usual cross-AZ data transfer, which for a terminal session is pennies. And a bastion host, the thing the endpoint replaces, was a whole instance running all month for the privilege of being a stepping stone; deleting it is usually the first saving this feature produces.

Jake: "So the fix for my second server actually made the bill smaller."

Ethan: "By one public address and one bastion. The endpoint costs nothing, and the server is harder to reach from outside than it was before. That is the rare fix that is both cheaper and safer."

Which way in, for which instance

By now there are four doors, and picking the right one is most of the battle. The table is the version Ethan keeps pinned.

If you only remember one row, make it the second one. An Instance Connect Endpoint and a security group that trusts only that endpoint gives you a server with no public address and no port 22 open to the world, that you can still reach from the console in two clicks. That is the ending Jake's booking server got.

The fix order I would use on a real server

1. Confirm the instance is running with 2/2 checks and that your console tab is in its Region.
2. Look at the addresses. Public IP present: continue. Private only: create an Instance Connect Endpoint and connect through it; stop reading the security group for the public path.
3. Add the SSH rule from com.amazonaws.REGION.ec2-instance-connect, and the IPv6 list if you use IPv6. Try the button again now; this fixes most cases.
4. Check the image. Install the package on RHEL, CentOS Stream or old Ubuntu from another way in; on Ubuntu, update it. Confirm the two AuthorizedKeysCommand lines, and accept that a server with its own key command cannot use this feature.
5. Test IAM with send-ssh-public-key. Fix the policy or the ec2:osuser condition if it is denied.
6. Check the username against the image's default.
7. Then the quiet causes: your network's reach to the proxy, rotated host keys, a broken sshd, a managed instance, a network ACL.

Do not open port 22 to 0.0.0.0/0 to make the button work. It will work, and you will have traded one prefix list for a server that every scanner on the internet can see.

Questions people type when the button fails

If the orange button has just failed on you, the message is less mysterious than it reads: the console knocks from an address your rule has never met, and it needs its own rule, its own path, and a package on the far end. Jake's booking server took one prefix list rule. His second server never got a public address and never will; it sits behind an Instance Connect Endpoint with a security group that trusts nothing else, and the Connect button works on it anyway. That is the version of this fix worth keeping.

Revision note. Written October 8, 2026, with the Instance Connect Endpoint limits and the IPv6 prefix lists as AWS lists them today. If the button has failed on you three times this afternoon, the rule in the first section is the one to try before anything else.