Fix SSH Permission Denied with Public Key Authentication

Linux & Unix Intermediate 👁 13 views 📅 May 25, 2026

SSH public key authentication fails with 'Permission denied' due to incorrect file permissions, wrong key placement, or SSH config issues. This guide covers diagnosis and resolution.

Symptoms

When attempting to connect via SSH using public key authentication, you receive an error message similar to: Permission denied (publickey). The SSH server may log entries like Authentication refused: bad ownership or modes or No supported authentication methods available. The connection fails even though the correct private key is provided.

Root Causes

The most common causes are:

  • Incorrect permissions on the ~/.ssh directory, authorized_keys file, or the user's home directory.
  • Wrong ownership of the .ssh directory or its contents.
  • Misplaced or missing public key in the authorized_keys file.
  • SSH daemon configuration that disables public key authentication.
  • Incorrect file format of the public key (e.g., extra whitespace or line breaks).

Step-by-Step Fix

1. Check SSH Server Logs

On the server, examine the SSH log for detailed error messages:

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

Or on RHEL/CentOS:

sudo tail -f /var/log/secure

2. Verify File Permissions

Ensure the following permissions are set correctly for the user account:

  • Home directory: should not be writable by group or others (e.g., 755 or 700).
  • ~/.ssh directory: 700 (drwx------).
  • ~/.ssh/authorized_keys file: 600 (-rw-------).
  • ~/.ssh and its contents must be owned by the user.

Fix permissions with:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $(whoami):$(whoami) ~/.ssh

3. Validate the Public Key

Open the authorized_keys file and ensure the public key is exactly one line, starting with ssh-rsa, ssh-ed25519, or similar. No extra spaces or newlines. Example:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... user@host

4. Check SSH Daemon Configuration

Edit /etc/ssh/sshd_config and verify these settings:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no  (optional, for key-only access)

Then restart SSH:

sudo systemctl restart sshd

5. Test with Verbose Output

From the client, run SSH with verbose logging to see which keys are offered:

ssh -vvv user@server

Look for lines like Offering public key and Authentication succeeded.

Alternative Fixes

  • Use SSH agent: Add your private key with ssh-add ~/.ssh/id_rsa and try again.
  • Copy key with ssh-copy-id: This tool sets correct permissions automatically: ssh-copy-id user@server.
  • Check SELinux (RHEL/CentOS): If SELinux is enforcing, restore contexts: restorecon -Rv ~/.ssh.
  • Disable strict mode (temporary): In sshd_config, set StrictModes no to bypass permission checks (not recommended for production).

Prevention

  • Always use ssh-copy-id to deploy public keys automatically.
  • Set up a configuration management tool (Ansible, Puppet) to enforce correct permissions.
  • Regularly audit SSH logs for authentication failures.
  • Use ed25519 keys for better security and shorter strings.
  • Keep SSH daemon updated and follow security best practices.

Was this solution helpful?