Alright, let’s get you into your machine. Because an instance just sitting there in the AWS console, looking pretty, is about as useful as a car without a steering wheel. You need to get inside and make it do things. We have three main ways to do this, each with its own flavor of “why.”

The Old Guard: SSH and Key Pairs

This is the classic, the standard, the thing that will never die. SSH is your direct, encrypted line to the shell of your Linux instance. It’s powerful, it’s ubiquitous, and it’s also the one where you’ll most likely shoot yourself in the foot first.

The core concept here is the key pair. When you launch an instance, AWS asks if you want to create a new key pair or use an existing one. Say yes. This isn’t a suggestion. If you don’t assign a key pair at launch, and it’s an older-gen instance type, you’re basically locking yourself out of your own house. The key pair consists of a public key that AWS injects into the instance’s authorized_keys file and a private key (.pem file) that you download exactly once. Guard this .pem file like it’s the nuclear codes. If you lose it, you can’t SSH in using this method. If someone else gets it, they can.

Here’s the classic SSH command. The -i flag is for “identity file,” aka your private key.

ssh -i /path/to/your/key.pem ec2-user@ec2-12-34-56-78.compute-1.amazonaws.com

Why this works: It’s pure SSH, talking directly to port 22 on your instance. The instance’s security group must allow inbound traffic on port 22 from your IP address (or 0.0.0.0/0 if you’re feeling reckless and want company).

Pitfalls:

  1. Key permissions: Your private key file must have strict permissions, or SSH will refuse to use it, rightly calling it an “unprotected private key file.” Fix it: chmod 400 your-key.pem.
  2. The wrong user: Amazon Linux uses ec2-user, Ubuntu uses ubuntu, CentOS uses centos. Get it wrong, and you’ll be rejected. It’s a surprisingly common facepalm moment.
  3. IP Address changes: If your home IP isn’t static, it might change, breaking your security group rule. This is why the next option is so clever.

The AWS Party Trick: EC2 Instance Connect

This is AWS’s slick solution to the “oops, my IP changed” and “where did I put that darn .pem file?” problems. The magic here isn’t in your client; it’s on the instance itself.

For this to work, the instance needs the ec2-instance-connect package installed (it is on most modern Amazon Linux AMIs). You can connect via the AWS CLI or the Console. The CLI command is deceptively simple:

aws ec2-instance-connect send-ssh-public-key \
  --region us-east-1 \
  --instance-id i-1234567890abcdef0 \
  --availability-zone us-east-1a \
  --instance-os-user ec2-user \
  --ssh-public-key file:///path/to/your/public_key.pub

Here’s the genius part: this command doesn’t actually start a session. It temporarily pushes your public key to the instance’s authorized_keys file for 60 seconds. You then use a regular SSH command to connect within that window.

Why this works: It uses IAM permissions (ec2-instance-connect:SendSSHPublicKey) to authenticate the key push, not your network rules. You still need a security group that allows port 22, but now you’re authorizing via IAM, which is often easier to manage than a fluctuating IP. It’s a brilliant end-run around the key management problem.

Pitfall: It requires that the instance can communicate with the AWS EC2 API. If it’s in a private subnet without a NAT gateway, or its security groups are locked down too tight, the send-ssh-public-key call will fail. It’s also not universally supported on every obscure Linux distro out of the box.

The No-Brainer Heavyweight: Session Manager

This is the future, and it’s glorious. Session Manager is part of AWS Systems Manager, and it completely changes the game. You don’t need a public IP. You don’t open port 22. You don’t even need SSH keys. It’s all encrypted and authenticated through IAM.

To use it, you need two things:

  1. The SSM Agent is installed on the instance (it’s on most modern AWS AMIs).
  2. The instance has an IAM role attached that grants it the AmazonSSMManagedInstanceCore policy (or equivalent permissions).

That’s it. The connection is initiated from your machine using the AWS CLI and the Session Manager plugin:

aws ssm start-session --target i-1234567890abcdef0

Boom. You’re in. A shell session opens directly in your terminal.

Why this works: The instance “phones home” to the SSM service. When you start a session, your CLI authenticates with IAM, tells the SSM service to connect to the instance, and it sets up a secure, proxied tunnel between you and the instance’s agent. It’s ridiculously secure by default—no inbound ports—and auditable, as every session is logged to CloudWatch Logs and S3.

Pitfall: The main one is IAM and networking. The instance’s role must be correct, and the instance must have outbound internet access (or a VPC Endpoint for SSM) to communicate with the service. If it’s completely air-gapped, you’re back to SSH.

So, which to use? My rule of thumb: Use Session Manager for almost everything. It’s more secure and easier. Use EC2 Instance Connect for a nice web-based console experience or when you need to forward a GUI. Keep SSH in your back pocket for when you’re dealing with ancient systems, other clouds, or you just need the raw, unfiltered power of a direct connection.