What causes 'Permission denied (publickey)' on SSH?

This error occurs when the SSH server cannot verify your identity using public key authentication. Common causes include: encrypted home directories preventing access to ~/.ssh/authorized_keys before login, incorrect file permissions on ~/.ssh or authorized_keys, the public key not being present on the server, SSH agent not having the key loaded, or the server's sshd_config not allowing public key authentication.

Why does SSH key authentication fail after a server reboot but works after manual login?

This is a classic symptom of an encrypted home directory. When the server boots, the home directory is encrypted and the SSH daemon cannot read ~/.ssh/authorized_keys. After you log in manually (via console or password), the home directory is decrypted and SSH key authentication starts working. The solution is to store your authorized_keys file outside the encrypted home directory.

How do I fix 'Permission denied (publickey)' caused by an encrypted home directory?

You have two options: (1) Store your SSH authorized_keys file outside the encrypted home directory by changing the AuthorizedKeysFile path in /etc/ssh/sshd_config to a location like /etc/ssh/authorized_keys/%u, or (2) Decrypt your home directory entirely. Option 1 is recommended as it maintains the encryption of your home data while allowing SSH key access.

How can I diagnose which SSH authentication method is failing?

Use verbose mode when connecting: 'ssh -vvv user@server'. This shows the full authentication negotiation, including which keys are tried, which methods the server offers, and where the authentication fails. On the server side, check /var/log/auth.log for detailed error messages.

Resolved: 'Permission denied (publickey).' when trying to access via SSH an Ubuntu Server

The Permission denied (publickey). error is one of the most frustrating SSH issues to troubleshoot because it can have multiple causes, and the error message itself gives very little information about what went wrong. This article focuses on a particularly tricky cause — encrypted home directories — and also covers the other common causes and their solutions.

The Problem

You set up SSH key authentication correctly on your Ubuntu server. Everything works perfectly — until you restart the server. After the reboot, you get:

Permission denied (publickey).

You access the server via console, and everything looks fine — the keys are in the right place, permissions look correct. You try SSH again and it works. Restart the server or the SSH service, and the error returns.

This intermittent behavior is the key symptom that points to an encrypted home directory as the root cause.

Why Encrypted Home Directories Break SSH Key Auth

When you install Ubuntu and choose to encrypt your home directory, the system uses eCryptfs to encrypt ~/.Private and mount it at your home directory upon login. Here is what happens:

Before login: Your home directory contents are encrypted. The SSH daemon tries to read ~/.ssh/authorized_keys but cannot because the directory is encrypted.
During console login: You enter your password, which triggers the decryption and mounting of your home directory.
After login: ~/.ssh/authorized_keys is now readable, so SSH key authentication works.

This creates the confusing pattern where SSH keys work after you log in manually but fail after a fresh boot.

Key insight: Cloud servers (AWS, Azure, DigitalOcean, etc.) do not encrypt home directories by default, which is why this issue typically only affects servers you installed yourself where you chose the encrypt option.

Diagnosing the Issue

Step 1: Enable Verbose SSH Output

Connect with maximum verbosity to see exactly where authentication fails:

ssh -vvv user@your-server

Look for lines like:

debug1: Offering public key: /home/youruser/.ssh/id_ed25519
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

The type 51 response means the server rejected the key.

Step 2: Check Server-Side Logs

On the server (accessed via console), examine the authentication log:

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

For encrypted home directory issues, you might see:

sshd[1234]: Could not open authorized keys '/home/user/.ssh/authorized_keys': No such file or directory

This message appears because the encrypted directory looks empty to the SSH daemon.

Step 3: Verify Home Directory Encryption

Check if your home directory is encrypted:

ls -la /home/

If you see a .ecryptfs directory or a .Private directory, your home directory uses encryption:

ls -la /home/user/
# If encrypted and not mounted, you may see:
# .ecryptfs  .Private  Access-Your-Private-Data.desktop  README.txt

You can also check:

mount | grep ecryptfs

Solution 1: Store SSH Keys Outside the Encrypted Home Directory (Recommended)

The best approach is to configure SSH to read authorized keys from a location outside the encrypted home directory.

Create the Alternative Keys Directory

sudo mkdir -p /etc/ssh/authorized_keys

Copy Your Authorized Keys

sudo cp ~/.ssh/authorized_keys /etc/ssh/authorized_keys/$USER
sudo chown root:root /etc/ssh/authorized_keys/$USER
sudo chmod 644 /etc/ssh/authorized_keys/$USER

Update SSH Configuration

Edit the SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Find the AuthorizedKeysFile directive and change it to:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

The %u is replaced by the username during authentication.

Restart SSH

sudo systemctl restart sshd

Test the Configuration

From your local machine:

ssh user@your-server

This should now work even after a reboot because /etc/ssh/authorized_keys/ is not inside the encrypted home directory.

Important: When you add new SSH keys in the future, you need to add them to /etc/ssh/authorized_keys/username instead of ~/.ssh/authorized_keys.

For a detailed walkthrough of this approach, see: How to store your SSH public key in a different directory.

Solution 2: Decrypt the Home Directory

If you decide you no longer need home directory encryption:

# Make sure you are logged in as the user
ecryptfs-migrate-home -u $USER

Warning: Back up your data before attempting this. Home directory decryption can fail if there is insufficient disk space (you need roughly double the space of your home directory temporarily).

Other Common Causes of ‘Permission denied (publickey)’

If your home directory is not encrypted, the error likely comes from one of these causes:

Incorrect File Permissions

SSH is very strict about permissions. The following must be set correctly:

# Home directory: no write for group/others
chmod 755 ~
# or
chmod 700 ~

# .ssh directory: owner only
chmod 700 ~/.ssh

# authorized_keys: owner read/write only
chmod 600 ~/.ssh/authorized_keys

# Private key (on your client): owner read only
chmod 600 ~/.ssh/id_ed25519

Key Not Added to authorized_keys

Verify your public key is in the server’s authorized_keys file:

cat ~/.ssh/authorized_keys

Compare it with your local public key:

# On your local machine
cat ~/.ssh/id_ed25519.pub

SSH Agent Not Loaded

If your key uses a passphrase and the SSH agent is not running:

# Start the agent
eval "$(ssh-agent -s)"

# Add your key
ssh-add ~/.ssh/id_ed25519

Wrong Key Type

Older servers may not support newer key types like Ed25519. Try generating an RSA key:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_legacy
ssh-copy-id -i ~/.ssh/id_rsa_legacy.pub user@server

Server Configuration Blocking Public Key Auth

Verify the server allows public key authentication:

sudo grep -E "PubkeyAuthentication|AuthorizedKeysFile" /etc/ssh/sshd_config

Ensure:

PubkeyAuthentication yes

SELinux or AppArmor Blocking Access

On systems with mandatory access control:

# Check SELinux
sudo restorecon -R ~/.ssh/

# Check AppArmor
sudo aa-status

Quick Troubleshooting Checklist

Check	Command
SSH verbose output	`ssh -vvv user@server`
Server auth log	`sudo tail -50 /var/log/auth.log`
Home dir encrypted?	`mount \| grep ecryptfs`
.ssh permissions	`ls -la ~/.ssh/`
authorized_keys content	`cat ~/.ssh/authorized_keys`
SSH config	`sudo sshd -T \| grep -i pubkey`
SSH agent keys	`ssh-add -l`

Summary

The Permission denied (publickey) error caused by encrypted home directories is particularly insidious because it works intermittently — SSH key auth succeeds after manual login but fails after a reboot. The recommended fix is to store authorized keys outside the encrypted home directory by updating AuthorizedKeysFile in sshd_config.

For other causes of this error, systematically check file permissions, verify the key is in authorized_keys, ensure the SSH agent is running, and review the server’s sshd_config. Using ssh -vvv and checking /var/log/auth.log will almost always reveal the root cause.