How to SSH into an EC2 Instance on AWS

Quick answer

• SSH into an EC2 instance with: ssh -i your-key.pem username@public-ip
• Run chmod 400 your-key.pem before connecting. SSH refuses to use a key file readable by other users.
• The username depends on the AMI: ec2-user for Amazon Linux, ubuntu for Ubuntu, admin for Debian
• Port 22 must be open in the security group, restricted to your IP only. Never open it to 0.0.0.0/0.

Before you start

All of these need to be in place before the connection will work:

• A running Linux EC2 instance. Windows instances use RDP, not SSH.
• A key pair. Either one created in AWS (gives you a .pem file to download) or an imported public key from your own machine.
• The instance’s public IP or DNS. Only available on instances in public subnets. Private subnet instances have no public IP and need a different approach.
• A security group rule for SSH. TCP port 22 must allow inbound traffic from your IP address.
• The correct username. Depends on the OS/AMI (see the table further down).
• An SSH client installed locally. macOS and Linux include one built in. Windows 10 and 11 include OpenSSH, or you can use PuTTY.

If you have not yet launched your first instance, the first EC2 instance guide walks through key pair creation, security group setup, and connecting for the first time.

Simple explanation

SSH uses a pair of mathematically linked keys. You hold the private key on your machine as a .pem file. The public key lives on the EC2 instance at ~/.ssh/authorized_keys. When you connect, your SSH client proves it holds the private key without ever sending it over the network. The instance checks that proof against the public key on file. If they match, you get a shell with no password required.

The practical consequence: if you lose the private key, you lose direct SSH access. AWS never keeps a copy after the initial download. This is one reason Session Manager is often the better long-term choice. Access is controlled through IAM permissions rather than key files, so losing a .pem file is not a crisis.

How SSH access to EC2 works

Four things have to line up for a connection to succeed:

• Key pair. When you launch an instance with a key pair, AWS injects the public key into the instance’s authorized_keys file. You must have the matching private key (.pem) to authenticate.
• Public IP and reachability. You need a network route to the instance. Instances in public subnets get a public IP. Instances in private subnets only have private IPs and are not reachable from the internet. They need a bastion host, VPN, or Session Manager.
• Security group on port 22. The security group acts as a virtual firewall. TCP port 22 must explicitly allow traffic from your source IP. If the rule is missing or points to a different IP, the connection will time out.
• Correct username. Each AMI has a default OS user. Using the wrong one produces “Permission denied” even when the key is correct.

Understanding public vs private IP addresses in AWS will save you significant troubleshooting time when an instance appears unreachable.

Step-by-step: connect to an EC2 instance

1. Create or import a key pair

Create a new RSA key pair and save the private key:

aws ec2 create-key-pair \
  --key-name my-key \
  --key-type rsa \
  --key-format pem \
  --query "KeyMaterial" \
  --output text > my-key.pem

Or create an ED25519 key pair (more modern than RSA):

aws ec2 create-key-pair \
  --key-name my-key \
  --key-type ed25519 \
  --query "KeyMaterial" \
  --output text > my-key.pem

If you already have an SSH key pair on your machine, import the public key instead:

aws ec2 import-key-pair \
  --key-name my-key \
  --public-key-material fileb://~/.ssh/id_rsa.pub

2. Lock down the private key permissions

Run this immediately after saving the file. SSH refuses to use a key file that other users on your machine can read:

chmod 400 my-key.pem

3. Get the instance public IP or DNS

aws ec2 describe-instances \
  --instance-ids i-0abc12345def67890 \
  --query "Reservations[0].Instances[0].PublicIpAddress" \
  --output text

You can also find it in the EC2 console: Instances → select your instance → Public IPv4 address. If the field is empty, the instance is in a private subnet and has no public IP. You cannot SSH to it directly from the internet.

4. Confirm the security group allows SSH from your IP only

# Get your current public IP
MY_IP=$(curl -s https://checkip.amazonaws.com)

# Add an inbound SSH rule restricted to your IP
aws ec2 authorize-security-group-ingress \
  --group-id sg-0abc12345def67890 \
  --protocol tcp \
  --port 22 \
  --cidr ${MY_IP}/32

5. Use the correct SSH username

The username depends on the AMI. See the Default usernames by OS table below. Using the wrong username is one of the most common causes of “Permission denied (publickey)”, even when the key is perfectly valid.

6. Connect with SSH

# Amazon Linux 2023 / Amazon Linux 2
ssh -i my-key.pem ec2-user@<public-ip>

# Ubuntu
ssh -i my-key.pem ubuntu@<public-ip>

# Add -v for verbose output when debugging connection issues
ssh -v -i my-key.pem ec2-user@<public-ip>

7. Verify you are connected

Once connected, you should see the instance hostname in the shell prompt. Confirm you are on the right instance:

# Show the instance ID from metadata
curl -s http://169.254.169.254/latest/meta-data/instance-id

# Show OS details and hostname
uname -a
hostname

Default usernames by OS

Check this before assuming the key or security group is the problem. The wrong username produces the same “Permission denied (publickey)” error as a bad key, and it is a much faster fix.

For marketplace or custom AMIs, check the AMI’s documentation page. Vendors sometimes configure a different default user.

When to use SSH

SSH is a strong choice when you need:

• Direct shell access. Interactive debugging, running ad-hoc commands, editing configuration files on the instance.
• File transfers. Both scp and rsync run over SSH and are straightforward for copying files to and from an instance.
• Port forwarding and tunneling. Forward a remote port (for example, a database listening on 5432) to your local machine without exposing it to the internet.
• Remote development. VS Code Remote SSH connects to EC2 over SSH and gives you a full IDE experience running on the instance.
• Bastion host patterns. A hardened public instance acts as a jump host into private instances behind it using SSH agent forwarding.

When to use Session Manager instead

Session Manager is the better operational choice when you want to:

• Eliminate port 22 entirely. No inbound SSH rule means one less attack surface to manage.
• Access private instances directly. Instances in private subnets with no public IP are fully accessible through Session Manager. No bastion host needed.
• Stop managing key pairs. Access is controlled through IAM permissions, not .pem files. You grant and revoke access by updating IAM, not by distributing or rotating keys.
• Get automatic audit logs. Every session is recorded to CloudWatch Logs or S3, giving you a full history of who ran what command and when.
• Support multiple team members. Each IAM user gets their own audited access session without anyone sharing a key pair.

The trade-off: Session Manager requires the SSM Agent to be running on the instance and an IAM instance profile with SSM permissions attached. Applying the principle of least privilege to those instance profiles is important to avoid over-granting access.

SSH vs Session Manager vs EC2 Instance Connect

Each method has different trade-offs. Here is a practical comparison to help you choose:

For most production environments, Session Manager is the stronger operational choice. SSH remains useful for file transfers and port forwarding workflows that Session Manager does not natively support. EC2 Instance Connect is the best option for recovery or occasional access when you have not pre-configured either of the others.

Troubleshooting SSH failures

Permission denied (publickey)

• Likely cause: Wrong username, wrong key pair, or file permissions too open
• Fix: Run chmod 400 my-key.pem. Confirm the username matches the AMI (see the table above). Confirm this key pair was the one selected when the instance was launched, not a different one or none at all. Add -v to the SSH command for verbose output that identifies exactly where authentication fails.

Connection timed out

• Likely cause: Port 22 is not open in the security group from your IP, or the instance is in a private subnet with no route from your machine
• Fix: Check the security group inbound rules. TCP 22 must allow your source IP. Check whether the instance has a public IP. If it is in a private subnet, it is not reachable directly from the internet. See the network troubleshooting guide for diagnosing route and subnet issues.

Connection refused

• Likely cause: The SSH daemon is not running, or the instance is still booting
• Fix: Wait a minute and retry. Check the instance system log in the EC2 console under Actions, then Monitor and troubleshoot, then Get system log. If the SSH daemon crashed, you may need to recover via EC2 Instance Connect, Session Manager, or the EBS volume method below.

Host key verification failed

• Likely cause: The instance was replaced and the new one got the same IP. Your local ~/.ssh/known_hosts file still has the old host key stored for that address.
• Fix: Remove the stale entry with ssh-keygen -R <ip-address>. Reconnect and confirm the new host key fingerprint matches what you expect.

WARNING: UNPROTECTED PRIVATE KEY FILE

• Likely cause: The .pem file has permissions wider than 400, meaning other users on the machine can read it
• Fix: Run chmod 400 my-key.pem. SSH requires 400 or stricter and refuses to proceed until this is done.

No route to host / private subnet reachability

• Likely cause: The instance is in a private subnet, has no public IP, or the VPC has no internet gateway attached
• Fix: Confirm the instance has a public IP. If it does not, use a bastion host, VPN, or Session Manager. For deeper diagnosis, see debugging VPC connectivity problems.

Recovering when locked out

If you lose the private key and cannot SSH in, try these options in order of effort:

Option 1: EC2 Instance Connect

It pushes a temporary public key to the instance for 60 seconds. Trigger it from the EC2 console Connect button, or from the CLI:

aws ec2-instance-connect send-ssh-public-key \
  --instance-id i-0abc12345def67890 \
  --instance-os-user ec2-user \
  --ssh-public-key file://~/.ssh/id_rsa.pub \
  --availability-zone us-east-1a

Immediately SSH in while the temporary key is valid:

ssh -i ~/.ssh/id_rsa ec2-user@<public-ip>

Option 2: Session Manager

If the instance has the SSM Agent running and an IAM instance profile with SSM permissions, Session Manager gives you a shell with no key pair or open port needed. This is the simplest recovery path when it is already configured.

Option 3: EBS volume recovery

Use this when neither of the above options are available. It takes longer but is reliable:

1. Stop the locked-out instance (do not terminate it)
2. Detach its root EBS volume
3. Attach the volume to a working instance as a secondary disk (for example, /dev/sdf)
4. Mount the volume and add your new public key to /home/ec2-user/.ssh/authorized_keys
5. Unmount and detach the volume
6. Reattach it to the original instance as the root volume and start the instance

This is the nuclear recovery option. It is a good reason to configure Session Manager before you need it.

Using SSH config to simplify connections

Instead of typing the full command each time, add the instance to your ~/.ssh/config file:

Host myserver
  HostName 54.123.45.67
  User ec2-user
  IdentityFile ~/.ssh/my-key.pem

Now you can connect with just ssh myserver. You can extend this to set up local port forwarding, for example to access a Postgres database on the instance from your local machine:

Host myserver
  HostName 54.123.45.67
  User ec2-user
  IdentityFile ~/.ssh/my-key.pem
  LocalForward 5432 localhost:5432