Key Pairs and Logging In

Inkwell's server is running. Now the developer needs to log in to check the web server. EC2 Linux instances do not use passwords for this by default. Instead they use a key pair, and understanding who holds which half explains nearly every login error you will see.

The rule

AWS keeps the lock; you keep the only key.

A key pair is two mathematically linked keys:

• The public key is the lock. AWS stores it and, at launch, places it in the instance's ~/.ssh/authorized_keys file. It can be shown to anyone.
• The private key is the key. You download it once, as a .pem file, when you create the key pair. AWS does not keep a copy.

When you connect over SSH, your computer proves it holds the private key, and the instance checks that proof against the public key. The private key itself never crosses the network.

• chmod 400 makes the file readable only by you; SSH refuses a private key that others can read.
• The username depends on the image: ec2-user for Amazon Linux, ubuntu for Ubuntu.
• Key types are RSA or ED25519.

For Windows instances the key pair works differently: it decrypts the Administrator password once, and you log in with that password over Remote Desktop.

You can also avoid long-lived keys: EC2 Instance Connect pushes a short-lived key for each session, and Systems Manager Session Manager gives a shell without opening port 22 at all.

The shortcut

When a login fails, check the three-part match: right key file, right username, right permissions.

The trap is treating the .pem file casually. Anyone who copies it can log in, and if you lose it AWS cannot give it back. Store it like a password, never commit it to a Git repository, and do not share one key across a whole team.

Drills

Answer fast — trust the rule.

Remember

• AWS keeps the lock (public key); you keep the only key (private .pem).
• Login fails? Check the right key file, the right username, the right permissions.
• Trap: a lost private key cannot be recovered, and a leaked one lets anyone in.