DEV Community

Cover image for Access EC2 even without your .PEM/.PPK key.
DevOps Descent
DevOps Descent

Posted on

Access EC2 even without your .PEM/.PPK key.

#ec2 #aws #linux #server

Access Your AWS EC2 Instance Even Without the .PEM or .PPK Key: All Possible Ways Explained

Losing your EC2 SSH private key (.pem or .ppk) is one of those "oh no" moments every AWS user dreads.

AWS never stores your private key — it only keeps the public key on the instance in ~/.ssh/authorized_keys. Once it's gone from your machine, it's gone forever.

But don't panic. Your instance, data, and applications are not lost. You can regain access in multiple ways — some with zero downtime, some fully automated, and some requiring a bit of surgery on the EBS volume.

In this comprehensive guide, I’ll walk you through every official and practical method available in 2026, with prerequisites, step-by-step instructions, pros/cons, and when to use each one. Plus, I've added practical suggestions to make recovery faster and safer.

Important Warnings Before You Start

  • This guide is for EBS-backed Linux instances (the vast majority).
  • Instance store-backed instances generally cannot be recovered this way — terminate and relaunch instead.
  • You need IAM permissions for EC2, SSM, and (in some cases) Systems Manager Automation.
  • Always take a backup first — create an EBS snapshot or AMI before making changes.
  • Some methods require the instance to be running; others require it to be stopped.
  • Suggestion: Enable detailed monitoring and CloudWatch alarms on your critical instances to detect issues early.

Method 1: AWS Systems Manager Session Manager (Recommended — Zero Downtime, No SSH)

If your instance has the SSM Agent installed and the proper IAM role, this is the easiest and most modern way. No port 22, no keys, no security group changes.

Prerequisites

  • SSM Agent installed (pre-installed on Amazon Linux 2/2023, Ubuntu, etc.)
  • Instance has an IAM role with the AmazonSSMManagedInstanceCore managed policy
  • SSM VPC endpoints (or outbound internet on port 443)

Steps

  1. Go to AWS Systems Manager → Session Manager
  2. Click Start session
  3. Select your instance and click Start session

You now have a full shell in the browser (or via AWS CLI):

aws ssm start-session --target i-1234567890abcdef0
Enter fullscreen mode Exit fullscreen mode

Once Inside

# Generate and add a new key pair
ssh-keygen -t ed25519 -f /tmp/newkey
cat /tmp/newkey.pub >> /home/ec2-user/.ssh/authorized_keys

# Or just keep using Session Manager forever (best practice)
Enter fullscreen mode Exit fullscreen mode

Pros

  • No downtime
  • Fully auditable
  • Works on private subnets
  • No SSH exposure

Cons

  • Requires prior SSM setup

When to Use

Use this as your default and preferred method whenever the instance is SSM-managed.

Suggestion: Always attach the AmazonSSMManagedInstanceCore policy to your EC2 IAM role during instance launch. This saves you from key loss headaches in the future.

Method 2: AWSSupport-ResetAccess Automation (Fully Automated Magic)

AWS provides an official Systems Manager Automation runbook that does the entire rescue process for you.

What It Does (Linux)

  • Stops your instance
  • Launches a temporary helper instance
  • Mounts your root volume
  • Generates a brand new SSH key pair
  • Injects the public key
  • Stores the private key encrypted in SSM Parameter Store (/ec2rl/openssh/<instance-id>/key)
  • Restarts your original instance

Steps

  1. Open Systems Manager → Automation → Execute automation
  2. Search for and select AWSSupport-ResetAccess
  3. Choose Simple execution
  4. Enter your Instance ID
  5. (Optional) Provide a Subnet ID in the same AZ
  6. Execute

Retrieve Your New Private Key 

aws ssm get-parameter --name "/ec2rl/openssh/<instance-id>/key" \
  --with-decryption \
  --query "Parameter.Value" \
  --output text > newkey.pem

chmod 400 newkey.pem
ssh -i newkey.pem ec2-user@your-ip
Enter fullscreen mode Exit fullscreen mode

Pros

  • Fully automated
  • Official AWS-supported method
  • Can create a backup AMI automatically

Cons

  • Requires SSM + Automation IAM permissions
  • Causes brief downtime

When to Use

Perfect when you want a hands-off recovery process.

Suggestion: Test this automation in a non-production environment first so you’re comfortable using it during a real incident.

Method 3: EC2 Instance Connect (Temporary Browser/CLI Access)

EC2 Instance Connect pushes a temporary public key to the instance for 60 seconds.

Prerequisites

  • ec2-instance-connect package installed (default on Amazon Linux)
  • Security group allows inbound TCP 22
  • IAM permission: ec2-instance-connect:SendSSHPublicKey

Steps (Console)

  1. In EC2 console → Select instance → Connect
  2. Choose EC2 Instance Connect
  3. Click Connect → browser-based terminal opens

Via CLI 

aws ec2-instance-connect send-ssh-public-key \
  --instance-id i-1234567890abcdef0 \
  --instance-os-user ec2-user \
  --ssh-public-key-file ~/.ssh/id_rsa.pub
Enter fullscreen mode Exit fullscreen mode

Then SSH normally within 60 seconds.

Once Inside

Add your permanent public key to authorized_keys.

Pros

  • Quick and simple
  • No volume detachment
  • Good for emergency access

Cons

  • Requires SSH port 22 open
  • Package must already be installed
  • Access is temporary

When to Use

Use when you need fast temporary access and SSH/network is functional.

Suggestion: Install ec2-instance-connect on all your instances during initial setup for quick emergency access.

Method 4: EC2 Serial Console (Emergency Console Access)

Perfect when SSH is completely broken but the instance is still running.

Prerequisites

  • Nitro-based instance
  • Serial Console enabled at the account level
  • IAM permissions for serial console access

Steps

  1. In EC2 console → Select instance
  2. Go to Actions → Monitor and troubleshoot → EC2 Serial Console → Connect

You can now fix broken SSH configs, firewall rules, or boot issues.

Pros

  • Works even if network/SSH is broken
  • Excellent for deep troubleshooting

Cons

  • Text-only
  • Requires account-level enablement
  • Less beginner-friendly

When to Use

Best for low-level troubleshooting when other remote access fails.

Suggestion: Enable EC2 Serial Console at the account level today — it’s a lifesaver during major outages.

Method 5: Classic EBS Volume Rescue Method (The Original Way)

This is the most universal method when nothing else is configured.

Steps

  1. Create a new key pair in the EC2 console
  2. Stop the problematic instance
  3. Note the root volume ID and device name
  4. Launch a temporary rescue instance in the same Availability Zone
  5. Detach root volume from original instance
  6. Attach it to rescue instance as secondary volume (/dev/sdf)
  7. SSH into rescue instance and mount: 
sudo mkdir /mnt/rescue
sudo mount /dev/xvdf1 /mnt/rescue   # confirm with lsblk
Enter fullscreen mode Exit fullscreen mode
  1. Add your new public key: 
cat <<EOF >> /mnt/rescue/home/ec2-user/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your-new-public-key
EOF
Enter fullscreen mode Exit fullscreen mode
  1. Fix permissions: 
sudo chown -R 1000:1000 /mnt/rescue/home/ec2-user/.ssh
sudo chmod 700 /mnt/rescue/home/ec2-user/.ssh
sudo chmod 600 /mnt/rescue/home/ec2-user/.ssh/authorized_keys
Enter fullscreen mode Exit fullscreen mode
  1. Unmount, detach, reattach to original instance with correct device name, and start.

Pros

  • Works on almost any EBS-backed Linux instance
  • Most reliable fallback

Cons

  • Requires downtime
  • Manual process

When to Use

Use when nothing else is pre-configured.

Suggestion: Keep a small “rescue instance” always ready in each AZ with the latest tools installed.

Method 6: Create AMI + Launch New Instance

If preserving the exact same instance ID is not critical, this is a clean shortcut.

Steps

  1. Select instance → Actions → Image and templates → Create image
  2. Once AMI is ready, launch a new instance with a new key pair
  3. Reassign Elastic IP, security groups, and DNS records

Pros

  • Clean rebuild
  • Good for fixing other config issues

Cons

  • New instance ID and possibly new IP

When to Use

Use if you’re okay starting fresh from the same disk image.

Suggestion: Always stop the instance before creating an AMI for consistent data.

Prevention: Never Lose Access Again

The best recovery is the one you never need.

Best Practices & Suggestions

  • Use Session Manager as your primary access method instead of SSH keys
  • Add at least 2–3 public keys to authorized_keys
  • Store private keys securely in AWS Secrets Manager or a password manager
  • Enable EC2 Instance Connect and Serial Console proactively
  • Use Infrastructure as Code (Terraform/CloudFormation) with proper IAM roles
  • Set up automated EBS snapshots and AMI creation
  • Tag instances clearly: AccessMethod: SSM, Environment: Prod

Pro Tip: Create a launch template with SSM role and Session Manager pre-configured so every new instance is recovery-ready from day one.

Quick Decision Guide

Situation Recommended Method
SSM already configured Session Manager (Method 1)
Want fully automated recovery AWSSupport-ResetAccess
Need quick temporary access EC2 Instance Connect
SSH/network completely broken EC2 Serial Console
Nothing pre-configured Classic EBS Volume Rescue
Don’t care about same instance ID Create AMI + Launch New Instance

Final Thoughts

Losing an EC2 key is painful, but AWS provides excellent escape hatches.

The real lesson: Stop depending only on SSH keys.

Modern AWS best practice is to use Session Manager + IAM roles + multiple recovery paths enabled in advance. This turns a potential disaster into a minor inconvenience.

Have you ever lost an EC2 private key?

Happy debugging and stay prepared! 🚀




**Support if you found this helpful😉**

No **Money** 🙅🏻‍♀️ just **Subscribe** to my [YouTube](https://shorturl.at/lVi2G) channel.

**Linktree Profile:** https://linktr.ee/DevOps_Descent
**GitHub**: https://github.com/devopsdescent
Enter fullscreen mode Exit fullscreen mode

Top comments (0)