I’ve SSH’d Into EC2 Dozens of Times. This One Still Took 4 Hours!
Source: Dev.to
The Problem
Yesterday I spent four hours trying to SSH into an EC2 instance. I tried from both macOS and Windows terminals, suspecting a local system issue, but nothing worked.
What I Checked
- Security group – Port 22 open ✅
- Source IP – Correct ✅
- Instance state – Running ✅
- Public IP – Correct ✅
- .pem key and permissions – All in order ✅
On paper everything was right, yet I still couldn’t connect.
Why It Felt Overwhelming
Even when you know what you’re doing, many small variables can combine to create friction:
- Different environments behave differently
- Muscle memory fails when the context changes
- Minor details that are usually glossed over suddenly matter
The overwhelm wasn’t due to a lack of knowledge about EC2; it was the sheer number of variables at play:
- Shell differences
- Key permissions
- Command syntax
- AWS quirks
Each issue was individually trivial, but together they became exhausting. The “friction” wasn’t a dramatic misconfiguration—just anything that slows thinking, disrupts flow, or makes a straightforward task feel heavier.
The Solution
When the noise finally dropped, the fix was embarrassingly simple. I realized I had been using the wrong username for the AMI type. Switching to the correct default user (ec2-user, ubuntu, admin, etc., depending on the AMI) allowed the SSH connection to succeed instantly.
Takeaways
- Familiar ≠ frictionless – Experience doesn’t eliminate all obstacles.
- Experience ≠ immunity to overwhelm – Even seasoned engineers can get stuck.
- Struggle ≠ incompetence – The challenge is often mental, not technical.
Practical Advice
- Slow down – Give yourself time to think clearly.
- Reduce variables – Verify one thing at a time.
- Don’t let frustration rewrite your self‑assessment – A temporary setback isn’t a reflection of your skill.
Being experienced means you’ll eventually get through the friction, even if it takes longer than expected. Sometimes, that’s enough.