Key Pairs & SSH Keys

A key pair is how you prove your identity when you log in to a Linux EC2 instance (a virtual server in AWS). It is made of two halves: a public key that AWS stores and copies onto the instance, and a private key that only you hold. When you connect over SSH (Secure Shell, the standard way to log into a remote Linux machine), the two halves are matched and you are let in without a password. Getting this right is the difference between a smooth first login and being permanently locked out of your own server.

How key pairs actually work

Public-key cryptography uses two mathematically linked keys. The public key can be shared with anyone; the private key must stay secret. AWS keeps the public key and, when you launch an instance, injects it into the file /home/ec2-user/.ssh/authorized_keys (the exact user depends on the AMI — ubuntu for Ubuntu, ec2-user for Amazon Linux). Your SSH client then uses the matching private key to authenticate. Because only your private key matches that public key, only you can log in.

This injection happens once, at launch, via a small program called cloud-init. If you launch an instance with no key pair, there is no SSH key on the box and you cannot SSH in at all — you would need another method like Session Manager.

Gotcha: AWS never sees your private key after creation. When you create a key pair in AWS, the private .pem file is offered for download exactly once. AWS does not store it and cannot recover or re-send it. Lose it and you lose SSH access to any instance that used it.

Creating a key pair

You can have AWS generate the pair for you, or you can import a public key you already own.

Console steps

1. Open the EC2 console and choose Network & Security → Key Pairs in the left menu.
2. Click Create key pair.
3. Enter a Name (for example my-app-key).
4. For Key pair type, choose ED25519 (modern, fast, secure) or RSA (broadest compatibility).
5. For Private key file format, choose .pem for OpenSSH/macOS/Linux or .ppk for PuTTY on Windows.
6. Click Create key pair. Your browser downloads the private key immediately — save it somewhere safe.

CLI

aws ec2 create-key-pair \
  --key-name my-app-key \
  --key-type ed25519 \
  --query 'KeyMaterial' \
  --output text > my-app-key.pem

Output:

# The .pem contents are written to my-app-key.pem; nothing prints to the terminal.
# Confirm it landed:
$ head -1 my-app-key.pem
-----BEGIN OPENSSH PRIVATE KEY-----

Now lock down the file so SSH will accept it:

chmod 400 my-app-key.pem

Warning: SSH refuses to use a private key that other users can read. If you skip chmod 400 you will see UNPROTECTED PRIVATE KEY FILE! and the connection is rejected. 400 means “read-only for you, no access for anyone else.”

Importing your own key

If you already have an SSH key (for example one managed by your team or stored in a password manager), upload only the public half. Your private key never leaves your machine — this is the more secure option.

Console steps

1. Go to EC2 → Key Pairs → Actions → Import key pair.
2. Give it a name and paste the contents of your public key file (for example ~/.ssh/id_ed25519.pub), or browse to the .pub file.
3. Click Import key pair.

CLI

aws ec2 import-key-pair \
  --key-name team-shared-key \
  --public-key-material fileb://~/.ssh/id_ed25519.pub

Output:

{
    "KeyFingerprint": "1f:51:ae:28:bf:89:e9:d8:1f:25:5d:96:8f:99:9a:1b",
    "KeyName": "team-shared-key",
    "KeyPairId": "key-0a1b2c3d4e5f67890"
}

Using the key to connect

Attach the key pair at launch time, then SSH in using the private key and the instance’s public address. (See /aws/connect-via-ssh for the full walkthrough.)

ssh -i my-app-key.pem [email protected]

ED25519 vs RSA — which to pick

Type	Speed	Key size	Compatibility	Recommendation
ED25519	Fast	Small, fixed	Modern OpenSSH, most clients	Default choice for new keys
RSA (2048)	Slower	Larger	Universal, including old tools	Use only if a tool needs it

When in doubt, choose ED25519. Pick RSA only when you must support an older client that cannot handle ED25519.

Do you even need SSH keys?

Many teams now skip key pairs entirely and use AWS Systems Manager Session Manager, a service that opens a shell to your instance through the AWS API instead of opening port 22 to the internet. There is no .pem to lose, no key to rotate, and no inbound SSH port to expose. Access is controlled by IAM (Identity and Access Management) permissions and every session is logged.

Approach	Inbound port 22?	Secret to manage	Audit log	Best for
SSH key pair	Yes	.pem private key	No (unless you add one)	Quick personal access, no SSM agent
Session Manager	No	None	Yes (CloudTrail/CloudWatch)	Teams, locked-down/production environments

Tip: For production, prefer Session Manager and keep port 22 closed. It removes the single biggest cause of EC2 lockouts (a lost .pem) and the most common attack surface (an open SSH port). See /aws/connect-session-manager.

Cost

Key pairs are completely free — AWS charges nothing to create, store, or use them. There is no cost difference between SSH keys and Session Manager either; Session Manager is included with no extra charge.

Best practices

• Use ED25519 unless an old client forces RSA.
• Back up your private key the moment it downloads — it is your only copy. Store it in a password manager or secrets vault, never in a Git repo.
• One key per person or per environment, not one shared key for everything — it makes revoking access far cleaner.
• Always run chmod 400 on a .pem before using it, or SSH will reject it.
• Prefer import over AWS-generated keys so your private key never travels over the network.
• For teams and production, use Session Manager and close port 22 entirely.
• Deleting a key pair in AWS does not remove the public key from running instances — to truly revoke access, edit authorized_keys on the box or rebuild it.

Related Topics

• Connect via SSH
• Connect with Session Manager
• Launch an EC2 instance (Console)
• Security groups
• Instance metadata