Getting in: SSH and key pairs

A terminal on a machine you will never see

Your instance is running in a Virginia data center. You administer it with SSH (Secure Shell), a protocol that gives you an encrypted terminal session on a remote machine. Everything you type runs there, not on your laptop.

SSH logins to EC2 use a key pair instead of a password:

• a public key, which AWS places on the instance at launch, and
• a private key, a file only you hold (like my-key.pem).

The server issues a mathematical challenge that only the private key can answer, so nothing guessable ever crosses the wire. AWS keeps no copy of your private key. Lose the file and AWS cannot resend it, which is very on-brand for lesson 2-1: AWS avoids holding secrets it does not need.

The commands, end to end

Launching and connecting looks like this (shown for reading, not running, since it needs a real account):

# launch: which image, which size, which key, which firewall
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0123456789

# connect: private key file + username + the instance's public IP
ssh -i my-key.pem ubuntu@54.210.167.204

After the ssh command your prompt belongs to the instance. From there it is the deployment world you already know: install Docker, pull your image, run the container. Note the launch flags map one-to-one to this unit: AMI, instance type, key pair, and a security group, which is the next lesson.

Building an SSH command for Amazon Linux

The ssh command has three moving parts: the private key file, the login user, and the address. This builds the command for an Amazon Linux instance at 3.91.44.10 using prod-key.pem.

key_file="prod-key.pem"
user="ec2-user"
ip="3.91.44.10"
echo "ssh -i $key_file $user@$ip"

Output

ssh -i prod-key.pem ec2-user@3.91.44.10

The detail that trips people daily

• The login user comes from the AMI, not from anything you choose. Ubuntu images create the user ubuntu, and Amazon Linux images create ec2-user.
• Using the wrong username fails with Permission denied (publickey), which is the exact same error as a wrong or badly permissioned key file. One message, three possible causes, which is why people burn hours on it.
• When you hit that error, check the username first. It is the cheapest of the three to rule out.

Why AWS cannot resend a lost private key

AWS never had it. Private keys stay with you, and only the public half was placed on the instance.

The design is asymmetric on purpose. AWS stores the public key, you store the private one, and neither alone lets an attacker in. A public key can be handed out freely, because it verifies signatures rather than creating them.

The security benefit is worth stating plainly: no copy at AWS means there is nothing for an AWS breach to leak. Your ability to log into your servers does not depend on Amazon keeping a secret safe.

Recovery from a lost key does exist, but it means attaching a new key yourself, typically by stopping the instance and modifying its disk or user data. There is no support ticket that produces the old file.

The port SSH listens on

SSH's standard port is 22.

A port is a numbered mailbox on a machine. One IP address can therefore offer many services at once, with the port number telling the operating system which program should receive an arriving packet. ssh, scp, and sftp all default to 22, because all three ride on the same protocol.

Security groups block everything inbound by default, so a new instance needs an explicit rule for 22 before you can connect at all. The habit worth building now is to open 22 to your own IP only rather than to the whole internet, and to open 80 and 443 for web traffic that genuinely needs to be public.