How to Fix 'Permission denied (publickey)' SSH Error in Linux

You have just provisioned a new Cloud VPS, disabled password authentication for security, and attempted to log in via SSH. Instead of a welcoming command prompt, you are immediately kicked back to your local machine with the error:

user@server: Permission denied (publickey).

This error means the SSH daemon (sshd) on the remote server rejected your login attempt because it either could not find a matching public key, or the file permissions are too insecure to trust. Here is how to methodically diagnose and fix the issue. (Note: If your SSH connection times out completely rather than explicitly denying permission, refer to our SSH Connection Refused Guide instead).

Understanding SSH Key Pairs

SSH authentication relies on an asymmetric cryptographic key pair:

1. Private Key (id_rsa): This stays securely on your local computer. It is the literal “key” that unlocks the server. You must never share this.
2. Public Key (id_rsa.pub): This is placed on the remote server inside the ~/.ssh/authorized_keys file. It acts as the “lock” that only your private key can open.

When you attempt to connect, the server checks if your private key mathematically matches any of the public keys listed in its authorized_keys file. If it doesn’t, or if the server cannot read that file, you get “Permission denied”.

Cause 1: Incorrect File Permissions (The Most Common Issue)

SSH is incredibly strict about file permissions. If the authorized_keys file on the remote server is readable or writable by anyone other than the specific user logging in, SSH will silently ignore the file to prevent security breaches.

To fix this, you must access the server (via a web console provided by your host, or temporarily re-enabling password auth) and run the following commands on the remote machine:

# Set the home directory permissions
chmod 755 ~/

# Set the .ssh directory permissions (read/write/execute for the owner only)
chmod 700 ~/.ssh

# Set the authorized_keys file permissions (read/write for the owner only)
chmod 600 ~/.ssh/authorized_keys

Once applied, restart the SSH service: sudo systemctl restart sshd.

Cause 2: Missing or Incorrect Public Key

If the permissions are correct, the public key inside the server’s authorized_keys file likely does not match the private key you are using locally.

1. Verify your local key: On your local machine, print your public key: cat ~/.ssh/id_rsa.pub
2. Compare with the server: On the remote server, view the contents of the authorized keys file: cat ~/.ssh/authorized_keys
3. If they do not match exactly (including the ssh-rsa prefix), you must copy the local public key string and paste it into the server’s file.

Cause 3: The SSH Agent Isn’t Loading Your Key

Sometimes, your local SSH client simply isn’t presenting the correct private key to the server, especially if you have multiple keys (e.g., one for GitHub, one for your VPS).

You can explicitly tell SSH which private key to use using the -i flag:

ssh -i ~/.ssh/my_custom_key user@your_server_ip

To avoid doing this every time, add the key to your SSH agent:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/my_custom_key

Conclusion

The “Permission denied (publickey)” error is almost always a strict permissions issue or a simple key mismatch. By ensuring chmod 600 on your authorized_keys and explicitly passing your private key, you can securely regain access to your Linux environment. For tips on managing permissions recursively, check our Fixing Linux Error 28 (No space left on device) guide.

Secure root SSH key access and management effortlessly on Nextgen cloud VPS instances.