Troubleshooting SSH Permission Denied Publickey Issues

Permission denied (publickey) means the server was reachable, but it did not accept any public-key authentication attempt for the user you tried. That narrows the problem. You are no longer debugging routing, DNS, or whether the SSH port is open. You are debugging identity: the username, the private key your client offered, the public key stored on the server, and the server rules that decide whether that login is allowed.

The quickest useful command is:

ssh -vvv user@your_server_ip

Look for Authenticating to ... as 'user', then look for Offering public key. If the expected key is not offered, fix the client. If the expected key is offered and rejected, fix the server-side authorized_keys, ownership, permissions, or SSH daemon policy.

Common Causes of 'Permission Denied (publickey)'

The "Permission Denied (publickey)" error can stem from several configuration issues. Identifying the root cause often involves systematically checking the following components:

• Incorrect File Permissions: SSH is highly sensitive to file and directory permissions for security reasons. Incorrect permissions on your local ~/.ssh directory, private key file, or on the server-side ~/.ssh directory and authorized_keys file can prevent authentication.
• Missing or Incorrect authorized_keys Entry: The server's authorized_keys file must contain the correct public key for the user you are trying to log in as. If the key is missing, malformed, or associated with the wrong user, authentication will fail.
• Incorrect key pair association: Your SSH client might be offering the wrong private key, or the server might not have the corresponding public key listed in the authorized_keys file.
• SSH Agent Issues: If you are using an SSH agent, it might not be properly loaded with your private key, or it might be configured incorrectly.
• Server-Side SSH Configuration: While less common for this specific error, the server's SSH daemon configuration (sshd_config) might have specific restrictions on public-key authentication.

Step-by-Step Troubleshooting Guide

Let's delve into the practical steps to diagnose and fix these issues.

1. Verify Local Private Key and Permissions

Your local SSH configuration is the first place to check. Ensure your private key is accessible and has the correct permissions.

Checking Private Key Existence

Your private key is often located in ~/.ssh/id_ed25519 or ~/.ssh/id_rsa, but many teams use project-specific names. List your keys:

ls -la ~/.ssh

Do not upload or paste a private key into authorized_keys. The server needs the .pub file content, not the private key.

Verifying Local File Permissions

The ~/.ssh directory and your private key file should have restrictive permissions to prevent unauthorized access.

• ~/.ssh directory: Should be 700 (drwx------).
• Private key file (e.g., id_rsa): Should be 600 (-rw-------).

Use the chmod command to set the correct permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

Tip: If you're using a different key name, replace id_rsa with your actual private key filename.

If you are testing a specific key, force it:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod user@your_server_ip

This prevents your agent from offering a long list of unrelated keys first.

2. Verify Server-Side authorized_keys Configuration

This is often the most common culprit. The server must have your public key correctly listed for the user you're attempting to authenticate as.

Accessing the Server (if possible)

If you can still access the server via another method (e.g., password authentication, another user account, or a console), log in to check the authorized_keys file.

Checking authorized_keys File Location

The authorized_keys file is typically located at ~/.ssh/authorized_keys within the home directory of the user you are trying to log in as.

Verifying Server-Side File Permissions

Similar to the client-side, server-side permissions are critical:

• ~/.ssh directory on the server: Should be 700 (drwx------).
• authorized_keys file on the server: Should be 600 (-rw-------).

Ensure these permissions are set correctly on the server:

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

Also verify ownership. The .ssh directory and authorized_keys file should normally belong to the account you are logging in as:

chown -R youruser:youruser ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

If StrictModes is enabled in sshd_config, OpenSSH may reject keys when the home directory or .ssh path is writable by the wrong users.

Verifying authorized_keys Content

Open the ~/.ssh/authorized_keys file using a text editor (e.g., nano, vim). Each public key should be on a single line. Ensure that the public key you expect to use is present and correctly formatted. It should start with ssh-rsa, ssh-ed25519, or similar, followed by a long string of characters, and optionally a comment.

Example authorized_keys entry:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... your_public_key_string user@hostname

Do not add your private key to authorized_keys. Only the public key should be here.

3. Ensure Correct Public Key was Added

It's possible that the wrong public key was copied or that the public key on the server doesn't match your local private key.

Retrieving Your Local Public Key

Your public key is the counterpart to your private key. You can view it using the ssh-keygen command:

cat ~/.ssh/id_rsa.pub

This command will output your public key. Compare this output carefully with the entry in the server's ~/.ssh/authorized_keys file. Even a single typo or missing character will cause authentication to fail.

For a cleaner comparison, print the public key derived from the private key you are trying to use:

ssh-keygen -y -f ~/.ssh/id_ed25519_prod

That output should match one line in the remote user's authorized_keys.

Tip: A quick way to add your public key if you have password access to the server is using ssh-copy-id.

ssh-copy-id user@your_server_ip

This command automatically appends your default public key (~/.ssh/id_rsa.pub) to the ~/.ssh/authorized_keys file on the remote server and sets the correct permissions.

4. Specify the Correct Private Key (if not default)

If you are using a non-default private key (e.g., ~/.ssh/my_other_key), you need to tell your SSH client which key to use.

Using the -i Flag

You can specify the identity file (private key) with the -i option:

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

Configuring ~/.ssh/config

For convenience, you can configure your SSH client to always use a specific key for a given host:

Create or edit the ~/.ssh/config file on your local machine and add an entry like this:

Host your_server_alias
  HostName your_server_ip_or_domain
  User your_username
  IdentityFile ~/.ssh/my_other_key
  IdentitiesOnly yes

Then you can connect simply using:

ssh your_server_alias

5. Check SSH Agent Status

If you rely on an SSH agent to manage your keys, ensure it's running and has your key loaded.

Checking if Agent is Running

echo "$SSH_AUTH_SOCK"

If this outputs a path, the agent is likely running. If it's empty, you may need to start one.

Adding Key to Agent

If your key is not loaded, add it:

ssh-add ~/.ssh/id_rsa

If you are prompted for a passphrase, enter it. You can verify which keys are added with ssh-add -l.

If ssh-add -l shows many unrelated keys and the server disconnects after several attempts, either remove old keys from the agent or use IdentitiesOnly yes for that host.

6. Debugging with Verbose Mode

SSH has a verbose mode (-v, -vv, or -vvv for increasing levels of detail) that can provide invaluable clues about where the authentication process is failing.

ssh -vvv user@your_server_ip

Examine the output for messages related to key authentication, offering keys, and server responses. This often points directly to the problem.

Example verbose output snippet indicating a publickey failure:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: read PEM private key file /home/user/.ssh/id_rsa
debug1: failed to use sshkey: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

This output means the client tried id_rsa, the server did not accept it, and the client moved on to the next allowed method.

7. Server-Side sshd_config Review (Advanced)

Check /etc/ssh/sshd_config and any files in /etc/ssh/sshd_config.d/. Confirm that public-key authentication is enabled:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Then look for Match blocks near the bottom of the file. A later Match User, Match Group, or Match Address block can override earlier settings for the exact account you are testing.

After any change, validate syntax before reloading:

sudo sshd -t
sudo systemctl reload sshd

Some systems use ssh as the service name instead of sshd.

A Reliable Troubleshooting Order

Use the verbose output to avoid guessing. First confirm the username. Then confirm the client offers the private key you expect. Then confirm the matching public key is in the target user's authorized_keys. Then check ownership and permissions. Only after those are clean should you spend time on sshd_config, Match blocks, SELinux contexts, or account restrictions.

That order solves most Permission denied (publickey) cases without random changes, and it keeps you from weakening SSH security just to get one urgent login working.