ProjectDevOps

Lost Your EC2 .pem Key? Here’s Every Way to Get Back In Step-by-Step Guide

Aadmin••👁️ 10•
#AWS EC2#DevOps#Cloud Computing
Lost Your EC2 .pem Key? Here’s Every Way to Get Back In Step-by-Step Guide

If you’ve misplaced the private key (.pem) for an Amazon EC2 Linux instance, AWS can’t recover it for you—but you still have multiple safe ways to regain access. This blog walks you through all practical methods, what each one requires, and exact commands to fix authorized_keys so you can SSH again.

Table of Contents

How to Choose the Right Method (TL;DR)

Use this quick picker to decide:

Note: AWS never stores your private key; if it’s lost, you must replace access using one of these paths.

One-Time Prep: Create a New SSH Key Pair

Do this on your laptop before any method:

# Ed25519 is modern, small, and widely supported
ssh-keygen -t ed25519 -C "my-ec2-login" -f ~/.ssh/my-ec2-2025

# Result:
# - Private key: ~/.ssh/my-ec2-2025
# - Public key : ~/.ssh/my-ec2-2025.pub

Tip: If you still have an old private key but lost the .pub, rebuild it:

ssh-keygen -y -f old-key.pem > old-key.pub

Method 1 — AWS Systems Manager: Session Manager (No SSH Needed)

Best when:

  • SSM Agent is installed on the instance (common on Amazon Linux & Ubuntu official AMIs).

  • The instance has an IAM role with AmazonSSMManagedInstanceCore.

  • The instance can reach SSM endpoints (internet or VPC endpoints).

Steps (Console):

  1. AWS Console → EC2 → Instances → select your instance → Connect → Session Manager → Connect.

  2. You’ll get a browser shell without SSH. Add your new public key for the correct user:

# For Amazon Linux / AL2023
sudo install -d -m 700 -o ec2-user -g ec2-user /home/ec2-user/.ssh
echo "ssh-ed25519 AAAA... your_comment" | sudo tee -a /home/ec2-user/.ssh/authorized_keys
sudo chmod 600 /home/ec2-user/.ssh/authorized_keys

# For Ubuntu (uncomment if needed)
# sudo install -d -m 700 -o ubuntu -g ubuntu /home/ubuntu/.ssh
# echo "ssh-ed25519 AAAA..." | sudo tee -a /home/ubuntu/.ssh/authorized_keys
# sudo chmod 600 /home/ubuntu/.ssh/authorized_keys

  1. Exit the session and SSH normally using your new key.

Why it’s great: No open ports, no public IP, works in private subnets (with VPC endpoints).

Method 2 — EC2 Instance Connect (EIC): Push a 60-Second Key

Best when:

  • The AMI/instance supports EC2 Instance Connect.

  • You can reach port 22 (public IP or via an EIC Endpoint in private subnets).

2A) Public IP Path (CLI)

# Push your public key (valid for ~60 seconds)
aws ec2-instance-connect send-ssh-public-key \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --availability-zone ap-south-1a \
  --instance-os-user ec2-user \
  --ssh-public-key file://~/.ssh/my-ec2-2025.pub

# Immediately SSH within 60 seconds:
ssh -i ~/.ssh/my-ec2-2025 ec2-user@<PUBLIC_IP>
# Then persist your key in ~/.ssh/authorized_keys (see "After You’re In")

2B) Private Subnet Path via EIC Endpoint

  • Create an EC2 Instance Connect Endpoint in your VPC/subnet.

  • Ensure Security Groups/Routes allow the endpoint to reach your instance.

  • Connect via console or CLI similar to above (the endpoint tunnels to the private IP).

Notes

  • Some AMIs need the ec2-instance-connect package for browser-based EIC.

  • The pushed key lives for about 60 seconds—use it right away, then add a permanent key.

Method 3 — EC2 Serial Console (Out-of-Band Access)

Best when:

  • You use a Nitro instance and Serial Console access is enabled in the account.

  • Network is broken or you can’t reach port 22.

High-level steps:

  1. Enable EC2 Serial Console at the account level (one-time).

  2. Use CLI to push a temporary public key to the serial port:

    aws ec2-instance-connect send-serial-console-ssh-public-key \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --serial-port 0 \
  --ssh-public-key file://~/.ssh/my-ec2-2025.pub \
  --region ap-south-1

  3. SSH to the serial console as per the instance OS/console docs and fix authorized_keys.

  4. Add your permanent key (see “After You’re In”).

Why it’s handy: Works even if networking is misconfigured.

Method 4 — SSM Automation: AWSSupport-ResetAccess

Best when:

  • Your instance is SSM-managed, and you prefer an automated “do it for me” approach.

Steps:

  1. AWS Console → Systems Manager → Automation → Execute automation.

  2. Search for AWSSupport-ResetAccess and select it.

  3. Provide the Instance ID and required parameters; run it.

  4. The runbook generates and injects a new key so you can log in.

Why it’s nice: Minimal manual work; AWS-maintained automation.

Method 5 — Rescue the Root Volume (Detach → Mount → Fix)

Works everywhere (with a short downtime) because you fix authorized_keys offline.

  1. Stop the original instance (do not terminate).

  2. Detach its root EBS volume.

  3. Attach that volume to a helper instance in the same AZ (as a secondary disk, e.g., /dev/sdf).

  4. On the helper instance:

    lsblk
sudo mkdir -p /mnt/recovery

# Nitro/NVMe example (adjust device from lsblk)
sudo mount /dev/nvme1n1p1 /mnt/recovery

# If Xen-based, the device may be /dev/xvdf1
# sudo mount /dev/xvdf1 /mnt/recovery

  5. Add your key into the right user’s authorized_keys:

    # Amazon Linux example
sudo mkdir -p /mnt/recovery/home/ec2-user/.ssh
echo "ssh-ed25519 AAAA... your_comment" | sudo tee -a /mnt/recovery/home/ec2-user/.ssh/authorized_keys
sudo chmod 700 /mnt/recovery/home/ec2-user/.ssh
sudo chmod 600 /mnt/recovery/home/ec2-user/.ssh/authorized_keys
sudo chown -R 1000:1000 /mnt/recovery/home/ec2-user/.ssh  # adjust UID:GID if needed

    For Ubuntu, use /mnt/recovery/home/ubuntu/.ssh/authorized_keys.

  6. sudo umount /mnt/recovery

  7. Detach the volume from the helper and reattach it to the original instance as the root device.

  8. Start the original instance and SSH using your new key.

Pros: Bulletproof; no special agents or roles.
Cons: Requires stop/start and a helper instance.

Method 6 — Cloud-Init User Data Injection (On Next Boot)

Best when:

  • You can stop/start the instance and are okay injecting a script at boot.

Steps:

  1. Stop the instance.

  2. In EC2 Console → Instance Actions → Edit user data, paste:

    #!/bin/bash
user=ec2-user      # or ubuntu
home=/home/$user
mkdir -p $home/.ssh
chmod 700 $home/.ssh
echo "ssh-ed25519 AAAA... your_comment" >> $home/.ssh/authorized_keys
chmod 600 $home/.ssh/authorized_keys
chown -R $user:$user $home/.ssh

  3. Start the instance, SSH with your key, then (optionally) clear user data afterward.

Pros: Simple; no helper instance needed.
Cons: Requires a reboot and the AMI must process user data on boot.

After You’re In: Make Your New Key Permanent

Run this once (adjust the user to ec2-user or ubuntu as appropriate):

USER=ec2-user
PUBKEY="ssh-ed25519 AAAA... your_comment"

sudo install -d -m 700 -o $USER -g $USER /home/$USER/.ssh
echo "$PUBKEY" | sudo tee -a /home/$USER/.ssh/authorized_keys
sudo chmod 600 /home/$USER/.ssh/authorized_keys
sudo chown -R $USER:$USER /home/$USER/.ssh

Security hygiene:

  • Remove any temporary keys you added.

  • Ensure sshd_config has PasswordAuthentication no (if you don’t use passwords).

  • Restart SSH if you changed its config: sudo systemctl restart sshd (Amazon Linux) or sudo systemctl restart ssh (Ubuntu).

Troubleshooting & Gotchas

  • Default usernames: ec2-user (Amazon Linux/AL2023), ubuntu (Ubuntu), centos (older CentOS), etc.

  • Port 22 blocked: For EIC/SSH, open SG/NACL appropriately (temporarily if needed).

  • Private subnets: Prefer EIC Endpoint or Session Manager; avoid exposing public IPs.

  • Wrong filesystem device: Always verify with lsblk before mounting.

  • Permissions: ~/.ssh must be 700; authorized_keys must be 600; owner the target user.

  • SSM not showing instance: Check IAM role (AmazonSSMManagedInstanceCore), SSM agent running, and network path to SSM (public internet or VPC endpoints).

Hardening & Future-Proofing Checklist

  • ✅ Attach an IAM role and SSM Agent to every instance.

  • ✅ Set up VPC endpoints for SSM so Session Manager works in private subnets.

  • ✅ Adopt EC2 Instance Connect Endpoints for admin access (no bastion, granular SGs).

  • ✅ Keep port 22 closed by default; open only when needed.

  • ✅ Store keys safely (password manager/secret vault) and rotate regularly.

  • ✅ Consider keyless access patterns (SSM Session Manager as primary, SSH as fallback).

  • ✅ Backups & AMIs: Keep current AMIs and snapshots so you can rebuild quickly.

FAQ

Q1: Can AWS recover my lost .pem?
No. AWS never stores your private key. You must replace access via one of the methods above.

Q2: Which method has the least risk?
Session Manager (Method 1) is safest: no open ports, works in private subnets, auditable, no key exposure in transit.

Q3: I can’t afford downtime—what now?
Try Session Manager or EIC first. Both can be done with the instance running.

Q4: My instance has no internet.
Use VPC endpoints for SSM/EIC, or EC2 Serial Console, or do the Rescue Volume method.

Q5: Windows instance?
On Windows, use AWSSupport-ResetAccess to re-enable local admin password or RDP access.

Copy-Paste Snippet (Once You Have a Shell)

USER=ec2-user
PUB=~/.ssh/my-ec2-2025.pub

sudo install -d -m 700 -o $USER -g $USER /home/$USER/.ssh
sudo tee -a /home/$USER/.ssh/authorized_keys < "$PUB"
sudo chmod 600 /home/$USER/.ssh/authorized_keys
sudo chown -R $USER:$USER /home/$USER/.ssh

Final Thoughts

Losing an EC2 private key isn’t the end of the world. With Session Manager, EC2 Instance Connect (and its Endpoint), Serial Console, the SSM AWSSupport-ResetAccess runbook, or the classic rescue-volume workflow, you can always regain access—then lock things down so it doesn’t happen again. If you share your instance OS, VPC layout (public/private), and what’s already enabled (SSM/EIC/Serial), you can choose the fastest path from this guide and be back in within minutes.

Comments (0)

No comments yet. Be the first to share your thoughts!