Key Pairs and Connecting to EC2
By the end of this lesson, you'll be able to:
- Explain the public/private key concept behind an EC2 key pair
- Describe how to connect to a Linux EC2 instance over SSH, at a beginner level
- Work through a basic troubleshooting sequence when an SSH connection fails
Prerequisites: "Instances, Instance Types, and AMIs"
The public/private key concept
An EC2 key pair consists of two mathematically related files: a public key, which AWS stores and places on the instance when it launches, and a private key, which you download once and keep yourself. When you connect, your SSH client proves it holds the matching private key without ever sending that key across the network — this is what authenticates you as the instance's legitimate operator, in place of a traditional password.
The critical, non-negotiable rule: the private key file must never be committed to Git, shared over chat, or stored anywhere it could leak — it is a long-lived credential, exactly the kind Module 2 warned about, and anyone who obtains it can connect to any instance launched with the matching key pair.
Connecting to a Linux instance
A typical SSH connection to a Linux EC2 instance looks like this:
ssh -i YOUR_KEY.pem USER@YOUR_INSTANCE_HOSTYOUR_KEY.pem is your downloaded private key file, USER is the default login username for the AMI's operating system (this varies by AMI — for example, common Amazon Linux and Ubuntu images each define their own default), and YOUR_INSTANCE_HOST is the instance's public address. The exact command and default username can vary slightly depending on your operating system and SSH client, so treat this as the general shape rather than something to copy character-for-character in every situation.
When the connection fails: a troubleshooting sequence
A failed SSH connection is one of the most common early EC2 frustrations. Work through these in order rather than guessing randomly:
- Is the instance actually Running? A stopped or still-launching instance won't accept connections.
- Is the correct host/address being used? A stopped-and-restarted instance's public address can change, depending on configuration (Lesson 4 covers why).
- Does the security group permit the required traffic from the appropriate source? Lesson 4 covers this in full — an instance with no inbound rule allowing SSH from your location will refuse the connection every time.
- Is the correct username being used for this AMI? Different AMIs default to different usernames.
- Is the correct private key being used? The key must match the specific key pair the instance was launched with.
- Are the key file's permissions/configuration appropriate? Some SSH clients refuse to use a private key file that's readable by other users on your own machine, as a safety check.
Exercise
A learner tries to SSH into their EC2 instance and gets a connection timeout (not a rejected-credentials error — the connection never completes at all). Using the troubleshooting sequence from this lesson, name the two most likely causes to check first, and explain why a timeout specifically (rather than an authentication error) points toward them.
Show hint
A timeout usually means the network traffic never reached something willing to respond — as opposed to reaching the instance and being rejected.
Key Pairs and Connecting to EC2 Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
An EC2 key pair uses public-key cryptography — AWS keeps the public key, you keep the private key — to authenticate an SSH connection to a Linux instance, and the private key must be protected with the same seriousness as any other credential covered in Module 2.