Introduction

Connection closed by ... during SSH to an EC2 instance means the TCP connection reached something that then terminated the session. That is different from a pure timeout, and it usually points to one of three areas: network controls, the SSH service on the instance, or an authentication or user-environment problem after the connection starts. The fastest way to fix it is to check those layers in order instead of guessing.

Start With The Network Path

First verify that the instance is actually reachable on port 22.

Check:

• the instance is running
• the security group allows inbound TCP 22 from your IP
• the subnet route table is correct for the instance's networking model
• network ACLs are not blocking inbound or outbound SSH traffic

A basic SSH command should look like this:

ssh -i my-key.pem [email protected]

Use the correct default username for the AMI family. Common examples are ec2-user, ubuntu, and admin.

If you use the wrong username, the connection can appear to start and then close quickly after authentication fails.

Use Verbose SSH Output

The client-side debug logs are often enough to show where the connection dies.

ssh -vvv -i my-key.pem [email protected]

This helps distinguish between:

• no route or blocked port
• key rejection
• server-side disconnect after session setup begins

Without the verbose output, "connection closed" is too generic to diagnose accurately.

Confirm The SSH Service On The Instance

If the network path is open but the session still closes, the next suspect is sshd or the instance state itself. Use one of AWS's out-of-band access methods if you cannot log in directly.

Good recovery options include:

• EC2 Serial Console, if enabled for the account and AMI
• AWS Systems Manager Session Manager
• a rescue flow where you detach the root volume and inspect it from another instance

Once you have shell access, inspect:

sudo systemctl status sshd
sudo journalctl -u sshd --no-pager

If sshd is down, misconfigured, or crashing on startup, direct SSH will never become stable.

Check Authorized Keys And File Permissions

A very common cause is a correct key pair with incorrect file permissions or a broken home-directory setup on the instance. The SSH daemon may refuse to use authorized_keys if ownership or permissions are too loose.

Typical expected permissions are:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Also verify the target user's shell and home directory are valid. A broken shell configuration can cause the connection to close immediately after login succeeds.

Consider Disk And Resource Problems

Instances under pressure can accept a connection and then close it because the system is unhealthy. Common examples are:

• root volume is full
• memory pressure is severe
• cloud-init or startup scripts damaged the SSH configuration

If you can reach the instance through Session Manager or a recovery mount, check:

df -h
free -m

A full disk is especially common after logs or package caches grow unexpectedly.

Private Subnets And Bastion Paths

If the instance is in a private subnet, make sure you are connecting through the intended path rather than directly from the internet. In that case the failure may actually be on the bastion host or tunnel step, not on the private instance itself.

A clean pattern is:

• bastion host in public subnet
• private instance reachable from bastion security group
• SSH from your machine to bastion, then from bastion to the target

If the first hop works and the second fails, the issue is inside the VPC rather than at the public edge.

Common Pitfalls

• Using the wrong default username for the chosen AMI.
• Checking only security groups and forgetting that network ACLs or route tables can also block traffic.
• Assuming the key pair is wrong when the real problem is a broken sshd service or invalid file permissions on the instance.
• Ignoring EC2 Serial Console or Session Manager and trying to debug a server-side SSH failure from the client side only.
• Treating connection closed like a timeout even though it usually means something answered and then deliberately terminated the session.

Summary

• 'Connection closed by means the SSH path reached a responder that then ended the session.'
• Check security groups, routing, and ACLs first, then inspect sshd and the instance health.
• Use ssh -vvv to see where the failure occurs.
• Verify the AMI username, authorized keys, and SSH-related file permissions.
• If direct SSH is impossible, recover with Session Manager, EC2 Serial Console, or a rescue-volume workflow.