AWS USD Recharge AWS EC2 key pair login tutorial

AWS Account / 2026-05-15 16:08:38

Introduction: Why Key Pairs Are the Bouncer at the EC2 Club

If you’ve ever tried to enter a club with the wrong password, you know the feeling: that awkward moment where the bouncer looks at you like, “I don’t know you, and I definitely don’t let you in.” In AWS EC2 land, the bouncer’s name is the key pair, and it’s very serious about access.

In this tutorial, you’ll learn how to log into an EC2 instance using an AWS key pair. We’ll cover the full journey: creating the key pair in AWS, downloading it, setting correct file permissions on your computer, locating your instance’s public IP, and finally connecting via SSH. We’ll also handle the common “why isn’t this working?” situations, because they happen to everyone—usually right before you have a demo.

We’ll assume you’re connecting from a typical macOS or Linux terminal environment. If you’re on Windows, don’t worry; the article will still be friendly. You can adapt the commands with the usual tools (like PuTTY or Windows OpenSSH), and you’ll still get the core idea without losing your sanity.

What You Need Before You Start

Before you begin, gather these items. Think of this as packing snacks before a road trip—small effort now, fewer problems later.

An AWS account
An EC2 instance you want to log into
A key pair created in AWS (the private part stays with you; the public part goes to AWS)
The instance’s public IP address (or public DNS)
Network access to the instance (security group inbound rules)

Now for the most important thing: the private key file. If you didn’t download it when you created the key pair, you’re about to learn a valuable lesson—AWS won’t magically re-send it. (It’s not being mean; it’s being secure.)

Step 1: Create or Confirm Your EC2 Key Pair

Let’s start at the AWS end. You’ll create a key pair, name it something you’ll recognize later, and download the private key file.

Creating a key pair in the AWS Console

Open the AWS Management Console.
Go to EC2 service.
In the left navigation, find Network & Security and click Key Pairs.
Click Create key pair.
Enter a name, for example: my-ec2-login-key.
Select the key pair type (commonly RSA; AWS defaults are generally fine).
Choose Create key pair.
Download the private key file (.pem). Store it somewhere safe, like a high-security vault… except the vault is your computer folder.

Quick emotional support note: don’t put this file in a public share folder, and don’t name it something like final-key-v7-reallyfinal. Future you will suffer.

Important security reminder

After creation, AWS keeps the public key and stores it for authentication. You receive only the private key. That means: if you lose the .pem file, you generally have to create a new key pair and launch/attach appropriately (or use other recovery methods). There’s no “oops, can I get the private key again?” button.

Step 2: Launch or Confirm Your EC2 Instance Uses This Key Pair

A key pair only helps if your EC2 instance is actually configured to accept it. So check that you launched the instance with the same key pair you downloaded.

How to verify the key pair used for an instance

Go to EC2 in AWS Console.
Click Instances in the left menu.
Select your instance.
Look for a section labeled something like Key pair name in the instance details.
Confirm it matches the key pair you created.

If the key pair name doesn’t match, the instance won’t accept your private key. That’s like bringing the correct ID to the wrong party.

Step 3: Make Sure Your Security Group Allows SSH

Even with a perfect key pair, the instance still needs to be reachable. SSH traffic usually uses port 22. AWS blocks inbound traffic by default using security groups, so you must ensure your security group permits inbound SSH from your IP.

Check the security group inbound rules

Select your EC2 instance in the console.
Find Security or Security groups and click the associated security group.
Go to the Inbound rules tab.
Ensure there’s a rule that allows:

Type: SSH
Protocol: TCP
Port: 22
Source: Your IP address (or a safe range)

Many folks accidentally set source to 0.0.0.0/0 (the whole internet). That works, but it’s like leaving your front door open because you’re “confident.” If this is a learning environment, sure. For anything serious, restrict it.

Step 4: Find Your Instance’s Public IP Address

Now we locate the target. SSH doesn’t work by vibes; it needs an address.

How to get the public IP

On the instance page in AWS Console, find Public IPv4 address.
Or use Public DNS (IPv4) if provided.
Copy the public IP address.

If your instance doesn’t have a public IP, it might be configured without direct public access. In that case, you might need a bastion host, VPN, or Systems Manager Session Manager. But for the classic key pair SSH tutorial, we assume you have a public IP.

Step 5: Determine the Correct SSH Username

The next question is: “What username does the instance expect?” This depends on the AMI (Amazon Machine Image) you used. Common defaults:

Amazon Linux: often ec2-user
Ubuntu: often ubuntu
AWS USD Recharge Debian: often admin or debian depending on image
CentOS (older): often centos

If you’re unsure, check the instance details or the AMI documentation. Many tutorials assume Amazon Linux and use ec2-user. If your login fails, the fix might not be your key pair at all—it might be the username. Credentials are a team sport, and you need both sides.

Step 6: Set Correct Permissions on Your Private Key (.pem)

Here comes one of the most frequent errors: “Permissions are too open.” Your computer’s SSH client is protective. If your private key file is too permissive, SSH refuses to use it.

Fix permissions on macOS/Linux

Run the following command in your terminal, replacing the file name with yours:

chmod 400 /path/to/my-ec2-login-key.pem

Or, if you want to be extra clear that you’re targeting the right file:

ls -l /path/to/my-ec2-login-key.pem

You should see something that looks like a permissions pattern equivalent to read-only for your user.

What happens if you skip this?

SSH will often respond with an error like:

Permissions 0644 for 'key.pem' are too open.

This is not AWS being dramatic. It’s your SSH client being sensible. It’s basically saying, “I can’t trust this key file, because anyone could read it.”

Step 7: Connect to the EC2 Instance Using SSH

Time to do the thing: log in. You’ll use your private key file and the instance’s public IP and username.

The basic SSH command

Replace values with your own:

ssh -i /path/to/my-ec2-login-key.pem ec2-user@PUBLIC_IP_ADDRESS

Example (illustrative only):

ssh -i ~/keys/my-ec2-login-key.pem [email protected]

First-time connection prompt

On the first connection, you might see a prompt about the authenticity of the host, something like:

Are you sure you want to continue connecting (yes/no/[fingerprint])?

If you recognize the IP and expected host, you can type yes. SSH stores the fingerprint in your known hosts file so the next time it won’t ask again.

Step 8: Troubleshooting Common Problems (The “Why Won’t It Let Me In?” Section)

Let’s address the classic faceplants. If you’re following along and something goes wrong, check these in order. Most issues fall into a handful of buckets.

Problem A: “Permission denied (publickey)”

This is the SSH equivalent of “wrong key” or “wrong user.” Causes include:

You used the wrong private key file (.pem).
The instance was launched with a different key pair.
The username is incorrect (e.g., using ec2-user on an Ubuntu image).

Fix:

Confirm the Key pair name on the instance matches your .pem file.
Try the correct username for your AMI.
Double-check you didn’t download a different key pair than the one you’re using.

Problem B: “Permission denied” or “Too open” key file errors

As discussed earlier, SSH will block keys with overly open permissions. Fix it by running:

chmod 400 /path/to/key.pem

Then try again.

Problem C: “Connection timed out”

This usually means your instance isn’t reachable on the network path, commonly because of security group rules or missing public access.

Check:

Security group inbound rule allows TCP port 22 from your IP.
Your instance has a public IP (or you have a route to it).
The instance is in a running state.

If you want an extra diagnostic, you can try ping (though ICMP might be blocked) or use network tools. Timeouts are often firewall or routing related, not key related.

Problem D: “Connection refused”

This means the network path works, but nothing is listening on port 22 (or SSH isn’t running).

Possible reasons:

SSH daemon isn’t running on the instance.
AWS USD Recharge Port 22 is blocked by OS-level firewall rules (less common with default images).
You’re connecting to the wrong instance or wrong IP.

Check your instance status checks and consider using AWS Systems Manager Session Manager if available (that avoids SSH entirely).

Problem E: You accidentally used the wrong IP address

It happens: you copy the wrong line, paste the wrong number, and suddenly you’re trying to log into a server that doesn’t exist or isn’t yours. SSH is literal—if the IP is wrong, your key pair is irrelevant.

Fix: re-copy from the instance details and verify the IP matches the instance you’re trying to reach.

Problem F: “Host key verification failed”

Sometimes the instance host fingerprint changes (e.g., the instance was replaced, or you connected to a different machine with the same IP). SSH then complains.

Fix options:

Verify you’re connecting to the right machine.
Remove the old entry from your known_hosts file for that IP.

Be careful: removing entries without verifying can be risky. You want to be sure you’re connecting to the correct server, not a surprise guest.

Problem G: Using the .pem file from a different key pair format

While AWS typically provides RSA .pem keys, sometimes people convert or mix up files. SSH expects the private key in a readable format.

Fix: use the exact private key file downloaded from AWS for that key pair.

Extra: Copy/Paste-Friendly “Ready to Use” Command Patterns

Here are common patterns you can adapt. Replace placeholders with your actual values.

Amazon Linux (common case)

ssh -i ~/keys/my-key.pem [email protected]

Ubuntu (common case)

ssh -i ~/keys/my-key.pem [email protected]

Using a custom hostname instead of IP

If you prefer public DNS:

ssh -i ~/keys/my-key.pem [email protected]

Step 9: Confirm You’re Actually Logged In

AWS USD Recharge Once connected, you’ll typically see a shell prompt. You can confirm by running:

whoami

This shows the username your session uses. You can also check basic system info:

uname -a

hostname

If those commands work, congratulations—you’ve successfully passed the bouncer’s checkpoint.

Keeping Your Access Safe (Because Keys Are Not Toys)

Now that you can log in, let’s do the responsible thing: keep things secure. Key pairs are powerful; treat them like a master key with feelings.

AWS USD Recharge Store .pem files securely with restricted permissions.
Don’t commit keys to Git or upload them to public locations.
Restrict security group inbound SSH to your IP where possible.
AWS USD Recharge Rotate keys if you suspect exposure.

If you’re working in a learning environment, you might be tempted to open SSH to the world. It works, but it’s like installing a trampoline on your roof and inviting raccoons over for “spontaneous parkour.” It’s fun until it isn’t.

Alternative Options: When SSH Keys Aren’t the Whole Story

Just because this tutorial focuses on SSH key pairs doesn’t mean you must always use them. AWS offers other access methods:

AWS Systems Manager Session Manager: connect without opening SSH to the internet, often safer.
EC2 Instance Connect: push temporary keys through AWS.
Use a bastion host: SSH from a controlled jump server.

If your environment is locked down (corporate networks, private subnets, strict security), these approaches can be more convenient than exposing port 22. But for getting started quickly, key pairs are the classic method.

Quick Checklist (So You Don’t Have to Re-Read Everything While Panicking)

You created a key pair in AWS and downloaded the .pem file.
AWS USD Recharge Your EC2 instance was launched with that key pair.
Your security group allows inbound SSH (TCP 22) from your IP.
You found the instance’s public IP.
You used the correct username (ec2-user, ubuntu, etc.).
Your .pem file has correct permissions (chmod 400).
You ran: ssh -i /path/to/key.pem username@PUBLIC_IP

Frequently Asked Questions

Can I use the same key pair for multiple EC2 instances?

Yes. A key pair can authenticate access to multiple instances as long as those instances are configured to use the matching key pair name during launch (or via the instance’s configuration where applicable). But keep in mind that shared keys increase the blast radius if something goes wrong.

What if I changed my AWS region?

Key pairs are created within an AWS region context in your workflow, and your instances live in a particular region too. Make sure you’re operating in the same region when you locate the key pair and the instance.

Why does AWS show me the public key but I only downloaded a private key?

That’s normal and intentional. AWS stores the public key so it can verify your authentication attempt. You keep the private key and prove you have it by using it to sign your SSH request. No private key, no login—very secure, and also very “no take-backs.”

Do I need to convert the key format?

Typically, no. AWS’s .pem keys generally work directly with OpenSSH. If you receive an unexpected key format, you might need conversion, but starting with the key downloaded directly from AWS usually avoids this.

How do I know if port 22 is open?

Check the EC2 security group inbound rules for SSH. Also confirm the instance is running. The best check is usually: try connecting. If your connection times out, it’s likely a network rule issue. If it refuses, SSH may not be running or you may be hitting a wrong target.

AWS USD Recharge Conclusion: You’ve Got Access, So Act Like You’ve Been There Before

Logging into an EC2 instance with an AWS key pair isn’t hard—once you know the steps. Create the key pair, attach it to your instance, allow SSH in the security group, fix your key file permissions, and connect with SSH using the correct username and the instance’s public IP.

And when something goes wrong (because something always goes wrong at least once), remember the usual suspects: wrong key pair, wrong username, blocked port 22, incorrect instance IP, or overly-permissive key file permissions.

Now go forth and administer your server like a confident internet wizard. Just… maybe don’t name the key file “definitelyfinalreallyfinalkey.pem.” Your future self deserves better.