Introduction

After getting my first EC2 instance up with Nginx, I dove into Project 2 of my DevOps roadmap: setting up IAM users and roles, and securing an EC2 instance with a security group. My goal? Create a user with limited access, attach a role for S3 permissions, and test it all out. What started as a straightforward task turned into a rollercoaster of SSH woes—but I came out stronger. Here’s how it unfolded.

The Plan

The project had clear steps:

  1. Create an IAM User: Set up devops-user1 with AmazonEC2ReadOnlyAccess for console and programmatic access.
  2. Create an IAM Role: Build ec2-s3-role with AmazonS3ReadOnlyAccess for my EC2 instance.
  3. Configure Security: Define a security group with SSH (port 22) restricted to my IP and generate a key pair (my-new-key).
  4. Launch an Instance: Spin up an Amazon Linux 2 instance with the security group and attach the role.
  5. Test It: Log in as devops-user1 to check EC2 read-only access, and SSH into the instance to run aws s3 ls using the role.

Simple, right? Well, not quite.

How It Went

I kicked off in the AWS Console:

  • IAM User: Created devops-user1, downloaded the access keys, and logged in to confirm read-only EC2 access worked.
  • IAM Role: Set up ec2-s3-role, attached it to my instance via EC2 > Actions > Modify IAM role.
  • Security Group: Added SSH (port 22, my IP) and launched the instance with Amazon Linux 2 AMI and my new key pair.

The instance launched fine, and I could connect via the AWS Console’s EC2 Instance Connect. But when I tried SSH from my local system:

ssh -i my-new-key.pem ec2-user@

It timed out. I was stumped—I’d followed all the steps!

Challenges & Solutions

Challenge 1: SSH Port 22 Timeout

After launching the instance, I couldn’t SSH from my local machine—it just kept timing out with:

ssh: connect to host  port 22: Connection timed out

The security group was set to allow port 22 from anywhere, and the instance was running. I even tested as devops-user1 with the access keys via AWS CLI, but SSH refused to budge.

Challenge 2: Switching to Port 2222 Didn’t Help

Thinking my network might be blocking port 22, I edited /etc/ssh/sshd_config on the instance (via Console access) to use port 2222, restarted sshd, and updated the security group. Tried again:

ssh -i my-new-key.pem -p 2222 ec2-user@

Still no luck—now it said "Connection refused." Telnet (telnet 2222) confirmed the connection failed too.

Solution: Fresh Start with a New Instance

Frustrated, I decided to wipe the slate clean:

  • Terminated the instance, deleted the security group, and trashed the old key pair.
  • Launched a new instance from scratch:
  • Amazon Linux 2 AMI, t3.micro.
  • New security group with SSH (port 22, anywhere).
  • Fresh key pair (my-new-key).

This time, SSH worked like a charm:

ssh -i my-new-key.pem ec2-user@

Opened Git bash & ran aws s3 ls —it listed my buckets, proving the ec2-s3-role worked.

Takeaways

  • Double-Check Everything: My first instance’s woes might’ve stemmed from a misconfigured subnet or lingering settings—starting fresh ruled those out.
  • Network Matters: Port 22 might’ve been blocked locally; testing from another network could’ve confirmed it, but the reset worked too.
  • IAM Power: Roles are a game-changer—no credentials on the instance, just seamless S3 access.
  • Persistence Pays: Troubleshooting taught me more than a smooth run would’ve.

Now that SSH and IAM are in my toolkit, I’m ready for the next challenge. How do you debug SSH woes—any tricks up your sleeve?