47 seconds. That’s all it takes.
One minute you’re confidently typing ssh -i …, the next you’re sweating over a blinking cursor and that cold, unfeeling line:
"
Permission denied (publickey).
"
Yeah. I’ve been there. Multiple times. Once during a Friday night deploy — team waiting, stakeholders pinging, and me Googling “aws ec2 ssh permission denied fix ubuntu” like my job depended on it. (Spoiler: it kinda did.)
Look — this error sucks. But here’s the thing: it’s rarely some catastrophic AWS failure. More often? A tiny misstep. A permission bit off by one. A file in the wrong place. Something small — but maddening if you don’t know where to look.
So let’s walk through it. Like I’m sitting next to you, coffee in hand, helping you debug this before the weekend slips away.
--
)
🌐 Security Groups — The Traffic Filter
Yeah, this feels obvious. But — from what I’ve seen on real projects — like, 30% of “permission denied” cases are actually network issues.
SSH can’t even start if the network blocks it.
Your EC2 instance needs a Security Group that allows inbound traffic on port 22 from your IP (or 0.0.0.0/0 — but don’t leave it like that).
Check:
- Is the right Security Group attached?
- Does it allow TCP 22 from your current IP?
- Is the instance in a public subnet with an Internet Gateway?
And yes — if you’re on a corporate network, your IP might’ve changed. Or your office might block outbound SSH (shoutout to overzealous firewalls).
I had a dev call me from a co-working space once. His IP had changed, and the SG only allowed his old one. Five minutes to fix. Two hours of panic before that.
Use telnet to test the connection:
telnet your-instance-ip 22
If it hangs or says “Connection refused” — it’s not SSH. It’s the network.
Fix that first. Then go back to keys.
--
🌐 IPv4 vs IPv6 — Are You Connecting to the Right Address?
Some instances have both IPv4 and IPv6.
If you’re using the IPv6 address — make sure:
- Your local network supports IPv6.
- The Security Group has an IPv6 rule (like
::/0or your specific IPv6).
Otherwise, you’ll get a timeout — which the client sometimes misreads as “permission denied.”
Not the end of the world. But confusing.
So — if you’re not sure, stick to IPv4. Easier to debug.
--
🧠 User and Home Directory — The Hidden Gotchas
Key? Good. Network? Fine. SSH config? Proper.
And still — “Permission denied.”
Now we go deeper.
Is the ubuntu user actually set up?
I had this happen once — launched an Ubuntu AMI, but a custom setup script ran before the user was fully initialized. Result? No /home/ubuntu/.ssh. No shell. Nothing.
The user existed in /etc/passwd — but the home directory was missing. SSH tried to log in, failed silently, and said “permission denied.”
Classic.
Check:
getent passwd ubuntu
You should see:
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
If the home directory is missing — create it:
sudo mkdir -p /home/ubuntu/.ssh
sudo chown ubuntu:ubuntu /home/ubuntu
sudo chmod 700 /home/ubuntu/.ssh
And if the last part is /usr/sbin/nologin or something — fix it:
sudo usermod -s /bin/bash ubuntu
Also — double-check the AMI. Are you sure it’s Ubuntu? Because if it’s Amazon Linux, the default user is ec2-user, not ubuntu.
Yeah. That happened. To me. On a production box. (Won’t lie — that was a long Monday.)
--
🟩 Final Thoughts
Here’s the truth: “Permission denied” is never just one thing.
It’s a chain — key, network, config, user, permissions — and one broken link kills the whole thing.
The frustrating part? The error message doesn’t tell you which link failed. It just says “no.”
But — here’s the good news: every fix is local. You don’t need to nuke and rebuild. You just need to test each layer.
Start with the key. Then the network. Then the server config. Then the user.
One by one.
The real skill isn’t memorizing commands. It’s knowing where to look. Developing that instinct — that’s what turns a junior into someone people call when things go sideways.
So next time you see that red text — don’t panic.
Take a breath.
And start debugging.
You’ve got this.
--
❓ Frequently Asked Questions
Can I regenerate the .pem file for my EC2 instance?
No. AWS doesn’t store private keys. If you lose the original .pem file, you can’t regenerate it. But you don’t have to start over — just mount the EBS volume on another instance and update ~/.ssh/authorized_keys with a new key. (It’s janky, but it works.)
Why does SSH say “Permission denied” even with the correct key?
In my experience? Usually one of four things: (1) wrong .pem permissions (400 is mandatory), (2) wrong username (ubuntu vs ec2-user), (3) sshd_config disabling pubkey auth, or (4) missing/empty authorized_keys file. Always check the logs: sudo tail -f /var/log/auth.log.
How do I check SSH daemon logs on Ubuntu?
Run sudo tail -f /var/log/auth.log. During login attempts, look for lines with “sshd” — they’ll tell you if the key was rejected, the user doesn’t exist, or the file permissions are wrong. Logs don’t lie. (Unlike my junior who swore he’d set chmod 400… he hadn’t.)
--
📚 References & Further Reading
- Official AWS EC2 Linux SSH troubleshooting guide:
(And if you’re reading this at 2 a.m. — hang in there. It’ll click. It always does.)
SOCIAL SHARE CARD GENERATOR