Husain Alhaboubi

Getting locked out of your Ubuntu server can feel like a nightmare, especially when you have lost your SSH reset key pair or root password. Whether you accidentally deleted your .pem file, switched to a new computer, or simply misplaced your credentials, regaining access is entirely possible without losing any data. I have personally tested these recovery methods on Ubuntu running on AWS EC2, and in this guide, I will walk you through every step to reset key pair access and restore full control of your server.

Understanding SSH Key Pairs and Why You Lose Access

SSH key pairs use public-key cryptography to authenticate connections between your local machine and a remote server. When you launch an EC2 instance, AWS places the public key in ~/.ssh/authorized_keys on the server. You keep the private key (the .pem file) on your local machine. When you connect via SSH, the server verifies that your private key matches the stored public key.

There are several common scenarios where you might need to reset key pair access. You may have switched to a new laptop and forgot to transfer the .pem file. Perhaps a team member who held the only copy of the key left the organization. Or maybe the key file got corrupted or accidentally deleted. Regardless of the cause, AWS does not store a copy of your private key, which means there is no “download again” button. You need to take manual recovery steps, and that is exactly what this guide covers.

Before You Start: Critical Precautions

Before attempting any recovery method to reset key pair credentials, follow these precautions to protect your data:

• Take an EBS snapshot: Go to EC2 → Volumes, select your root volume, and create a snapshot. This gives you a rollback point if anything goes wrong.
• Note your instance details: Record the Instance ID, Availability Zone, root volume Device Name (typically /dev/xvda or /dev/sda1), and any Elastic IP associations.
• Never terminate your instance: Always stop the instance, not terminate it. Terminating permanently deletes EBS-backed instances by default.
• Verify EBS-backed storage: These methods work on EBS-backed instances only. Instance-store backed instances cannot be stopped, so if you lose the key pair on those, AWS recommends terminating and recreating the instance.

How to Reset Key Pair Access If You Lost the Root Password

If you still have your SSH key pair but lost the root password, you can recover access by temporarily mounting the EBS volume on a helper instance. These steps should work on any Linux distribution but were only tested on Ubuntu on AWS from my side.

Follow these steps to reset key pair configuration and regain root password access:

1. Log in to your AWS Console and navigate to EC2.
2. Create a new temporary instance in the same Availability Zone as your locked-out instance. Make sure you generate a new key pair for this temporary instance.
3. Stop both the temporary instance and the old (locked-out) instance.
4. Detach the Elastic Block Store (EBS) root volume from the old instance. Note the device name (e.g., /dev/xvda).
5. Attach the detached EBS volume to the temporary instance as /dev/xvdf1.
6. Start the temporary instance.
7. Connect to the temporary instance via SSH using the new key pair you generated.
8. Once connected, create a mount directory:

mkdir oldebs

9. Locate the attached EBS volume:

sudo lsblk

The output should look something like this:

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0         7:0    0 97.7M  1 loop /snap/core/10126
loop1         7:1    0 97.1M  1 loop /snap/core/9993
loop2         7:2    0 28.1M  1 loop /snap/amazon-ssm-agent/2012
nvme1n1     259:0    0 69.9G  0 disk
nvme0n1     259:1    0   64G  0 disk
└─nvme0n1p1 259:2    0   64G  0 part /

The unpartitioned disk (in this case nvme1n1) is your attached volume. If your instance uses the xvd naming convention, look for /dev/xvdf or /dev/xvdf1.

10. Mount the attached EBS volume. You may need to switch to root first:

sudo su
mount /dev/xvdf1 oldebs

11. Edit the SSH configuration file on the mounted volume to enable key pair access and disable password authentication:

vi oldebs/etc/ssh/sshd_config

Set the following values:

PermitRootLogin yes
PubkeyAuthentication yes
PasswordAuthentication no

12. Save the file and unmount the volume:

umount oldebs

13. Stop the temporary instance.
14. Detach the EBS volume from the temporary instance and reattach it to the old instance using the original device name you noted earlier (e.g., /dev/xvda).
15. Start the old instance.
16. Connect via SSH using the key pair that was originally generated when you created the old instance.
17. Once logged in, change your root password:

sudo passwd root

18. If you want to switch back to password-based authentication, edit the SSH config again:

sudo vi /etc/ssh/sshd_config

Update the values:

PermitRootLogin yes
PubkeyAuthentication no
PasswordAuthentication yes

19. Restart the SSH service to apply changes:

sudo systemctl restart sshd

20. Do not forget to stop or terminate the temporary instance to avoid extra AWS charges.

Security note: Enabling password authentication and root login is generally not recommended for production servers. If you need to manage your AWS infrastructure securely, consider using key-based authentication as your primary method and keep password access disabled once recovery is complete.

How to Reset Key Pair If You Lost Your SSH Key

If you have completely lost your SSH private key (.pem file) and cannot connect to your Ubuntu instance at all, you still have several options to reset key pair access. AWS provides multiple recovery methods depending on your instance configuration. I will walk you through all four methods, starting with the most universally reliable one.

Method 1: Using a Rescue Instance (EBS Volume Swap)

This is the most reliable method and works regardless of your instance configuration. The concept is similar to the root password reset above: you mount the locked instance’s volume on a helper instance and inject a new public key into the authorized_keys file.

Step 1: Generate a new key pair in the AWS Console.

Go to EC2 → Key Pairs → Create Key Pair. Give it a descriptive name (e.g., recovery-key-2026), select .pem format for Linux/macOS or .ppk for PuTTY, and download the private key. Store it securely.

Step 2: Extract the public key from the new private key.

On your local machine, run:

ssh-keygen -y -f recovery-key-2026.pem

This outputs the public key string (starting with ssh-rsa or ssh-ed25519). Copy this entire string — you will need it shortly.

Step 3: Stop the locked-out instance.

In the EC2 Console, select the instance → Actions → Instance State → Stop. Wait until the state shows “Stopped.” Note the Availability Zone and root volume Device Name.

Step 4: Detach the root EBS volume.

Go to EC2 → Volumes. Find the root volume attached to your stopped instance. Select it → Actions → Detach Volume. Note the Volume ID.

Step 5: Launch a temporary rescue instance.

Launch a new Ubuntu instance in the same Availability Zone as the locked instance. Use the new key pair you just created. A t2.micro or t3.micro is sufficient since this instance is only needed temporarily.

Step 6: Attach the detached volume to the rescue instance.

Go to Volumes → select the detached volume → Actions → Attach Volume. Choose the rescue instance and set the device as /dev/xvdf (or /dev/sdf).

Step 7: SSH into the rescue instance and mount the volume.

ssh -i recovery-key-2026.pem ubuntu@RESCUE_INSTANCE_PUBLIC_IP

Once connected, identify and mount the attached volume:

sudo lsblk
sudo mkdir /mnt/recover
sudo mount /dev/xvdf1 /mnt/recover

If the partition name differs, use the output of lsblk to identify the correct partition (typically the largest one on the attached disk).

Step 8: Replace the public key in authorized_keys.

For Ubuntu instances, the default user is ubuntu. For Amazon Linux, use ec2-user. For CentOS, use centos.

# Back up the existing authorized_keys
sudo cp /mnt/recover/home/ubuntu/.ssh/authorized_keys /mnt/recover/home/ubuntu/.ssh/authorized_keys.bak

# Replace with your new public key
echo "ssh-rsa AAAAB3...YOUR_NEW_PUBLIC_KEY..." | sudo tee /mnt/recover/home/ubuntu/.ssh/authorized_keys

# Set correct permissions
sudo chown -R 1000:1000 /mnt/recover/home/ubuntu/.ssh
sudo chmod 700 /mnt/recover/home/ubuntu/.ssh
sudo chmod 600 /mnt/recover/home/ubuntu/.ssh/authorized_keys

Important: Replace the ssh-rsa AAAAB3...YOUR_NEW_PUBLIC_KEY... with the actual public key you extracted in Step 2. The entire key must be on a single line.

Step 9: Unmount, detach, and reattach.

sudo umount /mnt/recover

Now go back to the AWS Console:

• Stop the rescue instance.
• Detach the volume from the rescue instance.
• Reattach the volume to the original instance using the same device name it had before (e.g., /dev/xvda or /dev/sda1).
• Start the original instance.

Step 10: Connect with the new key pair.

ssh -i recovery-key-2026.pem ubuntu@YOUR_INSTANCE_PUBLIC_IP

You should now have full SSH access with your new key. Do not forget to terminate the rescue instance to avoid ongoing charges.

Method 2: Using EC2 User Data (Cloud-Init)

If you want to replace your SSH key without creating a rescue instance, you can inject a new public key through EC2 User Data. This method leverages cloud-init, which runs scripts during instance boot.

1. Stop your instance.
2. Select the instance → Actions → Instance Settings → Edit User Data.
3. Paste the following script (replace YOUR_NEW_PUBLIC_KEY with your actual public key):

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [users-groups, once]
users:
  - name: ubuntu
    ssh-authorized-keys:
      - YOUR_NEW_PUBLIC_KEY

4. Save the user data and start the instance.
5. Wait for the instance to fully boot. Check the instance console output (Actions → Monitor and Troubleshoot → Get System Log) to confirm cloud-init completed successfully.
6. Connect using your new key pair.

Note: This method may not work on all AMIs. Some older AMIs or custom images may not have cloud-init configured to reprocess user data on subsequent boots. If it does not work, use Method 1 instead.

Method 3: Using AWS Systems Manager (SSM)

If your instance has the SSM Agent installed and an appropriate IAM role attached, you can use the AWSSupport-ResetAccess automation runbook to reset key pair access without stopping your instance. This is the most convenient method when available.

Prerequisites:

• SSM Agent installed on the instance (pre-installed on most Ubuntu AMIs from 2018 onward).
• An IAM instance profile with AmazonSSMManagedInstanceCore policy attached.
• The instance must appear under Systems Manager → Fleet Manager → Managed Instances.

Steps:

1. Go to AWS Systems Manager → Automation → Execute automation.
2. Search for AWSSupport-ResetAccess and select it.
3. Enter your Instance ID and (optionally) a subnet ID in the same Availability Zone.
4. Click Execute and wait for the automation to complete (typically 5–10 minutes).
5. Once complete, retrieve the new SSH private key from Systems Manager → Parameter Store. Look for the parameter named /ec2rl/openssh/YOUR_INSTANCE_ID/key.
6. Save the key content to a new .pem file on your local machine:

aws ssm get-parameters --names "/ec2rl/openssh/INSTANCE_ID/key" --with-decryption --output json --query "Parameters[0].Value" | sed 's:\\n:\n:g; s:^"::; s:"$::' > recovered-key.pem
chmod 400 recovered-key.pem

7. Connect to your instance using the recovered key:

ssh -i recovered-key.pem ubuntu@YOUR_INSTANCE_IP

The advantage of this method is that you do not need to stop your instance or detach any volumes. For teams managing multiple servers, this is often the fastest way to reset key pair access. If you are managing cloud infrastructure at scale, understanding how to properly set up EC2 instances can help prevent lockout situations in the first place.

Method 4: Using EC2 Instance Connect

For instances running Amazon Linux 2, Amazon Linux 2023, or Ubuntu 20.04 and later with EC2 Instance Connect configured, you can access the instance directly from the AWS Console without any SSH key.

1. Go to EC2 → Instances → select your instance.
2. Click Connect → EC2 Instance Connect tab → Connect.
3. A browser-based terminal opens with shell access to your instance.
4. Once inside, generate a new key pair and update authorized_keys:

# Generate a new key pair directly on the server
ssh-keygen -t ed25519 -f ~/.ssh/new_key -C "recovery-key"

# Display the private key (copy this to your local machine)
cat ~/.ssh/new_key

# Add the public key to authorized_keys
cat ~/.ssh/new_key.pub >> ~/.ssh/authorized_keys

# Clean up the private key from the server
rm ~/.ssh/new_key

5. Copy the private key output to a file on your local machine, set permissions to chmod 400, and use it to connect via SSH going forward.

Important: EC2 Instance Connect requires the instance to have a public IP address and port 22 open in the security group. It also requires the ec2-instance-connect package to be installed on the instance.

Comparison: Which Method Should You Use?

Each recovery method has different requirements and trade-offs. Use this table to decide which approach fits your situation:

Method	Requires Instance Stop?	Prerequisites	Difficulty	Best For
Rescue Instance (EBS Swap)	Yes	EBS-backed instance	Medium	Universal fallback — works on any EBS instance
User Data (Cloud-Init)	Yes	Cloud-init enabled	Easy	Quick fix if cloud-init is available
AWS Systems Manager (SSM)	No	SSM Agent + IAM role	Easy	Production servers where downtime is unacceptable
EC2 Instance Connect	No	Public IP + Instance Connect package	Easiest	Quick browser-based access for supported AMIs

How to Generate a New SSH Key Pair on Ubuntu

Whether you are recovering from a lockout or simply rotating your keys as a best practice, generating a new SSH key pair on Ubuntu is straightforward. As of 2025, the recommended algorithm is Ed25519 due to its superior security and smaller key size compared to RSA.

Generate an Ed25519 key pair (recommended):

ssh-keygen -t ed25519 -C "yo********@*****le.com"

Generate an RSA 4096-bit key pair (for older system compatibility):

ssh-keygen -t rsa -b 4096 -C "yo********@*****le.com"

After running either command, you will be prompted for a file location (press Enter to accept the default ~/.ssh/id_ed25519) and a passphrase. Adding a passphrase is strongly recommended as it adds an extra layer of protection even if someone gains access to your private key file.

Copy the public key to a remote server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@YOUR_SERVER_IP

This command automatically adds your public key to the server’s ~/.ssh/authorized_keys file with the correct permissions.

Verify correct file permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys

SSH is very strict about file permissions. If permissions are too open, SSH will refuse to use the key and you will see a “Permissions are too open” error.

SSH Key Best Practices to Prevent Future Lockouts

After you successfully reset key pair access, take these steps to avoid getting locked out again:

• Store private keys in a password manager: Use a tool like Bitwarden or 1Password to securely store your .pem files. Never store them in plain text on shared drives or email.
• Use Ed25519 keys over RSA: Ed25519 keys are shorter, faster, and more secure than RSA. All modern systems support them.
• Add passphrases to your keys: A passphrase encrypts the private key at rest, buying you time to revoke the key if it is stolen.
• Rotate keys regularly: Generate new key pairs every 12–24 months and update authorized_keys on all servers.
• Enable AWS Systems Manager: Install the SSM Agent and attach an IAM role to every EC2 instance. This gives you a backup access method that does not depend on SSH keys.
• Set up EC2 Serial Console: For Nitro-based instances, enable the EC2 Serial Console as an emergency access method.
• Disable root login and password authentication: In production, your sshd_config should have PermitRootLogin no and PasswordAuthentication no.
• Keep backups of authorized_keys: Periodically back up the ~/.ssh/authorized_keys file along with your regular server backups.

Common Mistakes When Resetting Key Pairs

I have seen (and made) several mistakes during key pair recovery. Here are the most common pitfalls to watch out for:

• Wrong Availability Zone: The rescue instance and detached volume must be in the same Availability Zone. You cannot attach an EBS volume from us-east-1a to an instance in us-east-1b.
• Incorrect device name on reattach: When reattaching the volume to the original instance, you must use the exact original device name (e.g., /dev/xvda or /dev/sda1). Using a different name means the instance will not boot.
• Wrong username in authorized_keys path: Ubuntu uses /home/ubuntu/.ssh/, Amazon Linux uses /home/ec2-user/.ssh/, CentOS uses /home/centos/.ssh/, and Debian uses /home/admin/.ssh/. Using the wrong path means the key will not be found.
• Incorrect file permissions: SSH requires 700 for the .ssh directory and 600 for authorized_keys. If permissions are wrong, SSH silently ignores the key.
• Forgetting to unmount before detaching: Always run umount before detaching the volume in the console. Detaching a mounted volume can cause filesystem corruption.
• Terminating instead of stopping: Clicking “Terminate” permanently deletes your instance and its root volume (unless delete-on-termination is disabled). Always use “Stop.”

FAQ: Reset Key Pair in Ubuntu

Can I reset key pair without stopping my EC2 instance?

Yes. If your instance has AWS Systems Manager (SSM) configured, you can use the AWSSupport-ResetAccess runbook to reset the key without any downtime. EC2 Instance Connect also allows browser-based access without stopping the instance. However, the EBS volume swap method and user data method both require the instance to be stopped first.

Will I lose data when I reset my key pair?

No. Resetting a key pair only modifies the ~/.ssh/authorized_keys file on the instance. Your application data, databases, configurations, and everything else on the server remain untouched. However, you should always take an EBS snapshot before performing any recovery procedure as a safety net.

Can I recover access to an instance-store backed instance?

Instance-store backed instances cannot be stopped, which means you cannot detach and remount the volume. If you lose the SSH key for an instance-store backed instance and SSM or Instance Connect are not available, AWS recommends terminating the instance and launching a new one. This is one reason EBS-backed instances are preferred for production workloads.

Should I use Ed25519 or RSA when generating a new key pair?

Ed25519 is the recommended choice in 2025 and 2026. It provides stronger security with a 256-bit key compared to RSA’s minimum recommended 4096 bits, generates and verifies signatures faster, and produces shorter keys that are easier to manage. The only reason to use RSA is compatibility with very old systems that do not support Ed25519.

Can I add multiple key pairs to a single Ubuntu instance?

Yes. The ~/.ssh/authorized_keys file can contain multiple public keys, one per line. Each key allows the corresponding private key holder to access the instance. This is useful for team environments where multiple people need SSH access. Just append each new public key on its own line in the file.

What is the difference between an AWS key pair and an ssh-keygen key pair?

Functionally, they are the same — both are standard SSH key pairs. An AWS key pair is simply generated through the EC2 console, which stores the public key and gives you the private key to download once. An ssh-keygen key pair is generated locally on your machine. You can use either type interchangeably. The key difference is that AWS-generated keys are immediately associated with your EC2 instances at launch, while locally generated keys need to be manually added to authorized_keys.

Does this guide work for non-AWS Ubuntu servers?

The fundamental concepts apply to any Ubuntu server. The key recovery methods involving authorized_keys editing, ssh-keygen, and SSH configuration are universal Linux practices. However, the AWS-specific methods (SSM, EC2 Instance Connect, User Data, and EBS volume swaps) only apply to AWS EC2 instances. For non-AWS servers, you would typically need physical console access or an out-of-band management interface (like IPMI or a hosting provider’s VNC console) to regain access.

Conclusion: Regain Access and Secure Your Server

Losing your SSH key or root password does not mean you have lost your server. Whether you use the rescue instance method, cloud-init user data, AWS Systems Manager, or EC2 Instance Connect, there is always a path to reset key pair access on your Ubuntu instance. The rescue instance (EBS swap) method is the most reliable universal approach, while SSM and Instance Connect offer the convenience of no-downtime recovery.

Once you have regained access, take the time to implement proper key management practices. Use Ed25519 keys, enable SSM as a backup access method, rotate keys regularly, and always keep secure backups of your credentials. A few minutes of preventive setup now can save you hours of recovery work later. If you are managing AWS EC2 infrastructure, pairing solid key management with proper server maintenance will keep your systems both accessible and secure.

---

Related reading:

• How to Set Up a Private VPN on AWS: Ultimate Complete 2026 Guide
• Setting Up an AWS EC2 CentOS Instance: A Comprehensive Guide
• How to Extend EBS Volume on AWS EC2 Without Downtime
• Cloudflare Origin Certificate Setup Guide
• Fix Failed to Retrieve Directory Listing in FileZilla

Sources: AWS EC2 Documentation – Replace Key Pair (2025), AWS Systems Manager – AWSSupport-ResetAccess Runbook, AWS re:Post – Connect to EC2 After Losing Key Pair (October 2025), DigitalOcean – How to Set Up SSH Keys on Ubuntu (September 2025), SSH Key Best Practices for 2025 – Brandon Checketts (October 2025)