SSH Key Auth Fails on VPS – Quick Fix Inside

You're trying to SSH into your VPS with a key pair, but you get dumped back with "Permission denied (publickey)". I've been there – it's annoying when you know the key is correct.

Quick Fix – What Actually Works

The most common reason: authorized_keys has wrong permissions or you're using the wrong user. Here's the fix in two commands if you have root access.

1. SSH as root (if you have root password or console access):
   ssh root@your-vps-ip
2. Fix permissions for your user (replace youruser with actual username):
   

   chown -R youruser:youruser ~youruser/.ssh
   chmod 700 ~youruser/.ssh
   chmod 600 ~youruser/.ssh/authorized_keys

3. Test it – try logging in with your key from another terminal.

That's it for 90% of cases. The reason step 3 works: SSH daemon checks that .ssh directory is only readable by the owner (mode 700) and authorized_keys is not world-writable (mode 600). If either file has group write permissions, OpenSSH refuses the key. This is a security feature designed to stop other users from adding keys to your account.

Still Broken? Check SELinux or AppArmor

If permissions look fine but it still fails, the security module might be blocking access. On CentOS 7 or Rocky Linux 9 with SELinux enforcing, you need to restore the correct context:

restorecon -Rv ~/.ssh

What's happening here: SELinux labels need to match the ssh_home_t type. If you copied files from another machine with cp -a, the labels are wrong. The restorecon command fixes them.

On Ubuntu 22.04 with AppArmor, check if the SSH daemon is constrained:

sudo aa-status | grep sshd

If it shows enforce and you see denials in /var/log/syslog like apparmor="DENIED" operation="open" profile="/usr/sbin/sshd", then AppArmor is blocking the key file. The fix: add your user's home directory to the AppArmor profile, or disable AppArmor for SSH temporarily (sudo aa-disable usr.sbin.sshd – not recommended long-term).

Less Common Variations That Stumped Me

1. Wrong SSH Key Format on the Server

You copied a public key to authorized_keys but it's the private key by accident. The public key starts with ssh-rsa AAAA... (or ecdsa-sha2-...), not -----BEGIN OPENSSH PRIVATE KEY-----. Check the file's first line:

head -1 ~/.ssh/authorized_keys

If you see a private key header, you copied the wrong file. Regenerate a new key pair with ssh-keygen -t ed25519 and copy the public key again.

2. SSH Server Version Mismatch

Older OpenSSH versions (before 7.0 from 2016) don't support Ed25519 keys. If you generated a new Ed25519 key and try to use it on a server running OpenSSH 6.9, it will fail silently. Check server version:

ssh -V

If it's older than 6.9, generate an RSA key instead: ssh-keygen -t rsa -b 4096.

3. Multiple Keys and Wrong One Used

You have multiple private keys in ~/.ssh/. SSH tries them in order, but if the first key fails (wrong passphrase or not accepted), it stops and doesn't try the next. Force which key to use:

ssh -i ~/.ssh/id_ed25519 youruser@vps-ip

Or configure ~/.ssh/config to specify the key per host:

Host myvps
    HostName 192.168.1.100
    User youruser
    IdentityFile ~/.ssh/id_ed25519

4. Empty Authorized Keys File

Sometimes the file exists but is empty. Use cat ~/.ssh/authorized_keys to verify it has content. If empty, append your public key:

cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys

Debugging When Nothing Works

If you're stuck, run SSH in verbose mode from your client:

ssh -vvv youruser@vps-ip

Look for lines like:

• debug1: Authentications that can continue: publickey – means the server accepts public key auth but didn't like yours.
• debug2: we did not send a packet; disable method – means your client didn't offer a key it could use (e.g., no key found or passphrase wrong).
• debug1: Offering public key: /home/youruser/.ssh/id_ed25519 – shows which key was offered. If you don't see your key, you're using the wrong one.

On the server, check /var/log/auth.log (Ubuntu/Debian) or /var/log/secure (CentOS/RHEL):

sudo tail -f /var/log/auth.log

When you try to connect, you'll see something like Failed publickey for youruser from xxx.xxx.xxx.xxx port 22 ssh2: RSA SHA256:.... The key fingerprint matches? Then it's a permissions issue.

Prevention – Don't Get Stuck Again

Before you close this, do these two things:

1. Fix permissions right after adding a key – make it a habit. Script it if you manage multiple users.
2. Use ssh-copy-id instead of manual copy – it handles permissions for you. Run ssh-copy-id youruser@vps-ip from your client. It appends the public key and sets correct ownership/permissions.

One more thing: never set PermitRootLogin yes just because you can't log in as a regular user. It's a security risk. Fix the key instead.