Struggling with the dreaded SSH ‘Permission denied (publickey)’ error? A senior engineer breaks down the common causes and provides three real-world fixes, from the quick triage to the permanent, automated solution.

I Saw a Junior Engineer’s Cry for Help on Reddit—It Reminded Me of a Classic SSH Nightmare

I was scrolling through Reddit the other night and saw a post titled, “i don’t know how to solve it help me guys.” That hit me hard. It wasn’t the lack of detail; it was the sheer panic in the title. It took me back to a 2 AM incident a few years ago. We had a critical deployment fail. The logs were useless, just a stream of “Permission denied.” We were trying to SSH into a brand-new `prod-autoscaler-04` instance to debug, but every attempt failed. Turns out, the base AMI we used had a misconfigured `sshd_config` that was ignoring the `authorized_keys` file. We burned an hour of a P1 outage because of a simple key issue. These little things, the “paper cuts” of infrastructure, are often the most infuriating.

The Root of the Problem: Why Your Key Isn’t Working

Before we dive into fixes, let’s quickly demystify this. The “Permission denied (publickey)” error isn’t the server hating you personally. It’s a digital bouncer at a nightclub. You’re showing your ID (your private key), and the bouncer is checking it against the guest list (the `~/.ssh/authorized_keys` file on the server). The error means one of three things:

• You’re showing the wrong ID (using the wrong private key).
• Your name isn’t on the list (your public key isn’t in the `authorized_keys` file).
• You’re holding your ID weirdly, so the bouncer can’t read it (file and directory permissions are wrong).

The server’s SSH daemon (`sshd`) is incredibly strict about permissions. If the bouncer sees anything fishy, it’s an immediate “access denied.” No second chances.

Solution 1: The Triage (The “Is It Plugged In?” Fix)

This is your first-response checklist. Nine times out of ten, one of these steps will solve your problem. It’s not fancy, but it’s effective.

Step 1: Get Loud with Verbose Mode

Stop running `ssh user@host`. You’re flying blind. Use the `-v` (verbose) flag to get a play-by-play of the connection attempt. `-vvv` gives you even more detail.

ssh -vvv darian@prod-db-01

Look for lines like “Offering public key: /home/darian/.ssh/id_rsa” or “Server refused our key.” This tells you which key your client is trying to use and confirms the server is rejecting it.

Step 2: Check Your Permissions (The Bouncer’s Rules)

This is the most common culprit. SSH requires your home directory, your `.ssh` folder, and your `authorized_keys` file on the server to have strict permissions. Anyone else having write access is a security risk, so SSH just gives up.

SSH into the server (if you have another way in) and run these commands:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Your `.ssh` directory should be `700` (drwx——) and `authorized_keys` should be `600` (-rw——-). Anything else is a no-go.

Pro Tip: If you can get into the server using another method (like a password or a different user), the easiest way to add a new key is with `ssh-copy-id`. It automatically appends your public key to the remote `authorized_keys` file and sets the correct permissions. It’s a lifesaver.
ssh-copy-id darian@prod-db-01

Solution 2: The Right Way (The Configuration Management Fix)

Doing this manually is fine once, but it’s not scalable and it’s prone to error. In any real environment, you should be managing user keys with an automation tool. This is how we do it at TechResolve. It’s the “permanent” fix that prevents the problem from happening again.

Here’s a simple Ansible task that ensures a user `darian` exists and has their public key properly configured. You can keep your team’s public keys in a central repository and have Ansible pull them.

- name: Set up authorized keys for the user
  ansible.posix.authorized_key:
    user: darian
    state: present
    key: "{{ lookup('file', 'pubkeys/darian.pub') }}"

Running this playbook across your fleet ensures every server is configured identically. No more manual `chmod` commands or copy-pasting keys at 2 AM. This approach treats your server configuration as code—predictable, repeatable, and version-controlled.

Solution 3: The Backdoor Play (The “Nuclear” Option)

Okay, let’s say the server is totally inaccessible. You can’t get in, you have no other users, and `ssh-copy-id` is not an option. This is the last resort, the “break glass in case of emergency” option. We’re going to temporarily enable password authentication to get in, fix the keys, and then immediately lock it back down.

WARNING: This is a massive security risk, even for a short time. Do NOT do this on a critical, publicly-exposed production server unless you are in a P1 outage and have exhausted all other options. You are opening a door that attackers are constantly trying to break down.

Step 1: Enable Password Auth via User Data (Cloud Environments)

If you’re in AWS, Azure, or GCP, you can often stop the instance and modify its “User Data” or “startup script”. You can inject a script that edits the SSH config.

An example script for `cloud-init` (used by many Linux AMIs):

#cloud-config
runcmd:
  - sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
  - systemctl restart sshd

After the instance reboots, you should be able to log in with the user’s password. Once you’re in, fix the `authorized_keys` file, and then immediately revert the `sshd_config` change and restart `sshd` again.

If you don’t have a password set for the user, you may also need to add a command to set one: `echo ‘username:newpassword’ | chpasswd`.

Step 2: Clean Up Your Mess

Seriously. Once you’ve fixed the key, run this:

sudo sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Do not leave that backdoor open.

Wrapping It Up: Which Fix to Choose?

Here’s a quick breakdown of when to use each approach:

Solution	When to Use It	Pros	Cons
1. The Triage	First 5 minutes of troubleshooting any SSH key issue.	Fast, simple, solves most common problems.	Manual, doesn’t prevent future issues.
2. The “Right Way”	Standard operating procedure for all managed servers.	Scalable, repeatable, secure, prevents errors.	Requires setting up an automation tool like Ansible.
3. The Backdoor Play	Emergency access on a non-critical or firewalled machine.	Can get you out of a “totally locked out” situation.	EXTREMELY RISKY. Creates a temporary security hole.

That cry for help on Reddit is something we’ve all felt. The key (pun intended) is to not panic. Work the problem methodically, understand the “why,” and once you’ve fixed it, put a system in place to make sure it never happens again. Good luck out there.

---

🤖 Frequently Asked Questions