If you’ve misplaced the private key (<code>.pem</code>) 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 <code>authorized_keys</code> so you can SSH again.<hr><h2>Table of Contents</h2><ol><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#how-to-choose-the-right-method-tldr">How to Choose the Right Method (TL;DR)</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#one-time-prep-create-a-new-ssh-key-pair">One-Time Prep: Create a New SSH Key Pair</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-1--aws-systems-manager-session-manager-no-ssh-needed">Method 1 — AWS Systems Manager: Session Manager (No SSH Needed)</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-2--ec2-instance-connect-eic-push-a-60second-key">Method 2 — EC2 Instance Connect (EIC): Push a 60-Second Key</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-3--ec2-serial-console-outofband-access">Method 3 — EC2 Serial Console: Out-of-Band Access</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-4--ssm-automation-awssupport-resetaccess">Method 4 — SSM Automation: AWSSupport-ResetAccess</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-5--rescue-the-root-volume-detach--mount--fix">Method 5 — Rescue the Root Volume (Detach → Mount → Fix)</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-6--cloud-init-user-data-injection-on-next-boot">Method 6 — Cloud-Init User Data Injection (On Next Boot)</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#after-youre-in-make-your-new-key-permanent">After You’re In: Make Your New Key Permanent</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#troubleshooting--gotchas">Troubleshooting &amp; Gotchas</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#hardening--future-proofing-checklist">Hardening &amp; Future-Proofing Checklist</a></li><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#faq">FAQ</a></li></ol><hr><h2>How to Choose the Right Method (TL;DR)</h2>Use this quick picker to decide:<ul><li>SSM agent + IAM role already on the instance? → <a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-1--aws-systems-manager-session-manager-no-ssh-needed">Method 1: Session Manager</a> (fastest, no ports, no downtime).</li><li>Instance supports EC2 Instance Connect and port 22 reachable? → <a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-2--ec2-instance-connect-eic-push-a-60second-key">Method 2: EIC</a> (push a 60-sec temp key, then fix permanently).</li><li>Nitro instance with serial console access enabled? → <a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-3--ec2-serial-console-outofband-access">Method 3: Serial Console</a> (works even if networking is broken).</li><li>You prefer automation and have SSM? → <a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-4--ssm-automation-awssupport-resetaccess">Method 4: AWSSupport-ResetAccess</a> (automates key replacement).</li><li>None of the above available? → <a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-5--rescue-the-root-volume-detach--mount--fix">Method 5: Rescue the Root Volume</a> (always works; short downtime).</li><li>You can reboot and don’t mind user data scripts? → <a target="_blank" rel="noopener noreferrer nofollow" href="https://chatgpt.com/c/68df279c-b624-8324-a9bb-912463087435#method-6--cloud-init-user-data-injection-on-next-boot">Method 6: User Data</a> (injects a key on next boot).</li></ul><blockquote>Note: AWS never stores your private key; if it’s lost, you must replace access using one of these paths.</blockquote><hr><h2>One-Time Prep: Create a New SSH Key Pair</h2>Do this on your laptop before any method:<pre><code class="language-bash"># 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
</code></pre><blockquote>Tip: If you still have an old private key but lost the <code>.pub</code>, rebuild it:<pre><code class="language-bash">ssh-keygen -y -f old-key.pem &gt; old-key.pub
</code></pre></blockquote><hr><h2>Method 1 — AWS Systems Manager: Session Manager (No SSH Needed)</h2>Best when:<ul><li>SSM Agent is installed on the instance (common on Amazon Linux &amp; Ubuntu official AMIs).</li><li>The instance has an IAM role with <code>AmazonSSMManagedInstanceCore</code>.</li><li>The instance can reach SSM endpoints (internet or VPC endpoints).</li></ul>Steps (Console):<ol><li>AWS Console → EC2 → Instances → select your instance → Connect → Session Manager → Connect.</li><li>You’ll get a browser shell without SSH. Add your new public key for the correct user:</li></ol><pre><code class="language-bash"># 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
</code></pre><ol start="3"><li>Exit the session and SSH normally using your new key.</li></ol>Why it’s great: No open ports, no public IP, works in private subnets (with VPC endpoints).<hr><h2>Method 2 — EC2 Instance Connect (EIC): Push a 60-Second Key</h2>Best when:<ul><li>The AMI/instance supports EC2 Instance Connect.</li><li>You can reach port 22 (public IP or via an EIC Endpoint in private subnets).</li></ul><h3>2A) Public IP Path (CLI)</h3><pre><code class="language-bash"># 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@&lt;PUBLIC_IP&gt;
# Then persist your key in ~/.ssh/authorized_keys (see "After You’re In")
</code></pre><h3>2B) Private Subnet Path via EIC Endpoint</h3><ul><li>Create an EC2 Instance Connect Endpoint in your VPC/subnet.</li><li>Ensure Security Groups/Routes allow the endpoint to reach your instance.</li><li>Connect via console or CLI similar to above (the endpoint tunnels to the private IP).</li></ul><blockquote>Notes<ul><li>Some AMIs need the <code>ec2-instance-connect</code> package for browser-based EIC.</li><li>The pushed key lives for about 60 seconds—use it right away, then add a permanent key.</li></ul></blockquote><hr><h2>Method 3 — EC2 Serial Console (Out-of-Band Access)</h2>Best when:<ul><li>You use a Nitro instance and Serial Console access is enabled in the account.</li><li>Network is broken or you can’t reach port 22.</li></ul>High-level steps:<ol><li>Enable EC2 Serial Console at the account level (one-time).</li><li>Use CLI to push a temporary public key to the serial port:<pre><code class="language-bash">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
</code></pre></li><li>SSH to the serial console as per the instance OS/console docs and fix <code>authorized_keys</code>.</li><li>Add your permanent key (see “After You’re In”).</li></ol>Why it’s handy: Works even if networking is misconfigured.<hr><h2>Method 4 — SSM Automation: <code>AWSSupport-ResetAccess</code></h2>Best when:<ul><li>Your instance is SSM-managed, and you prefer an automated “do it for me” approach.</li></ul>Steps:<ol><li>AWS Console → Systems Manager → Automation → Execute automation.</li><li>Search for <code>AWSSupport-ResetAccess</code> and select it.</li><li>Provide the Instance ID and required parameters; run it.</li><li>The runbook generates and injects a new key so you can log in.</li></ol>Why it’s nice: Minimal manual work; AWS-maintained automation.<hr><h2>Method 5 — Rescue the Root Volume (Detach → Mount → Fix)</h2>Works everywhere (with a short downtime) because you fix <code>authorized_keys</code> offline.<ol><li>Stop the original instance (do not terminate).</li><li>Detach its root EBS volume.</li><li>Attach that volume to a helper instance in the same AZ (as a secondary disk, e.g., <code>/dev/sdf</code>).</li><li>On the helper instance:<pre><code class="language-bash">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
</code></pre></li><li>Add your key into the right user’s <code>authorized_keys</code>:<pre><code class="language-bash"># 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
</code></pre>For Ubuntu, use <code>/mnt/recovery/home/ubuntu/.ssh/authorized_keys</code>.</li><li><code>sudo umount /mnt/recovery</code></li><li>Detach the volume from the helper and reattach it to the original instance as the root device.</li><li>Start the original instance and SSH using your new key.</li></ol>Pros: Bulletproof; no special agents or roles. Cons: Requires stop/start and a helper instance.<hr><h2>Method 6 — Cloud-Init User Data Injection (On Next Boot)</h2>Best when:<ul><li>You can stop/start the instance and are okay injecting a script at boot.</li></ul>Steps:<ol><li>Stop the instance.</li><li>In EC2 Console → Instance Actions → Edit user data, paste:<pre><code class="language-bash">#!/bin/bash
user=ec2-user # or ubuntu
home=/home/$user
mkdir -p $home/.ssh
chmod 700 $home/.ssh
echo "ssh-ed25519 AAAA... your_comment" &gt;&gt; $home/.ssh/authorized_keys
chmod 600 $home/.ssh/authorized_keys
chown -R $user:$user $home/.ssh
</code></pre></li><li>Start the instance, SSH with your key, then (optionally) clear user data afterward.</li></ol>Pros: Simple; no helper instance needed. Cons: Requires a reboot and the AMI must process user data on boot.<hr><h2>After You’re In: Make Your New Key Permanent</h2>Run this once (adjust the user to <code>ec2-user</code> or <code>ubuntu</code> as appropriate):<pre><code class="language-bash">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
</code></pre><blockquote>Security hygiene:<ul><li>Remove any temporary keys you added.</li><li>Ensure <code>sshd_config</code> has <code>PasswordAuthentication no</code> (if you don’t use passwords).</li><li>Restart SSH if you changed its config: <code>sudo systemctl restart sshd</code> (Amazon Linux) or <code>sudo systemctl restart ssh</code> (Ubuntu).</li></ul></blockquote><hr><h2>Troubleshooting &amp; Gotchas</h2><ul><li>Default usernames: <code>ec2-user</code> (Amazon Linux/AL2023), <code>ubuntu</code> (Ubuntu), <code>centos</code> (older CentOS), etc.</li><li>Port 22 blocked: For EIC/SSH, open SG/NACL appropriately (temporarily if needed).</li><li>Private subnets: Prefer EIC Endpoint or Session Manager; avoid exposing public IPs.</li><li>Wrong filesystem device: Always verify with <code>lsblk</code> before mounting.</li><li>Permissions: <code>~/.ssh</code> must be <code>700</code>; <code>authorized_keys</code> must be <code>600</code>; owner the target user.</li><li>SSM not showing instance: Check IAM role (<code>AmazonSSMManagedInstanceCore</code>), SSM agent running, and network path to SSM (public internet or VPC endpoints).</li></ul><hr><h2>Hardening &amp; Future-Proofing Checklist</h2><ul><li>✅ Attach an IAM role and SSM Agent to every instance.</li><li>✅ Set up VPC endpoints for SSM so Session Manager works in private subnets.</li><li>✅ Adopt EC2 Instance Connect Endpoints for admin access (no bastion, granular SGs).</li><li>✅ Keep port 22 closed by default; open only when needed.</li><li>✅ Store keys safely (password manager/secret vault) and rotate regularly.</li><li>✅ Consider keyless access patterns (SSM Session Manager as primary, SSH as fallback).</li><li>✅ Backups &amp; AMIs: Keep current AMIs and snapshots so you can rebuild quickly.</li></ul><hr><h2>FAQ</h2>Q1: Can AWS recover my lost <code>.pem</code>? 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 <code>AWSSupport-ResetAccess</code> to re-enable local admin password or RDP access.<hr><h3>Copy-Paste Snippet (Once You Have a Shell)</h3><pre><code class="language-bash">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 &lt; "$PUB"
sudo chmod 600 /home/$USER/.ssh/authorized_keys
sudo chown -R $USER:$USER /home/$USER/.ssh
</code></pre><hr><h2>Final Thoughts</h2>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 <code>AWSSupport-ResetAccess</code> 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.

Cloud Computing

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