How to Fix ‘Permission Denied (publickey)’ SSH Error in Ubuntu Linux

When attempting to connect to a remote server, cloud instance, or local machine using SSH, encountering the error message Permission denied (publickey) is one of the most common and disruptive obstacles in Linux administration. This error indicates that the remote Secure Shell daemon (sshd) rejected your connection because it could not validate your cryptographic identity against its authorized credentials database.

What Triggers the “Permission Denied (publickey)” Error?

Public-key authentication relies on an asymmetric cryptographic key pair: a private key stored strictly on your local computer, and a matching public key placed inside the remote server’s ~/.ssh/authorized_keys file. When authentication fails, the breakdown typically stems from one of four vulnerabilities:

• Overly Permissive File Permissions: OpenSSH strictly refuses to use keys or configuration directories that are readable or writable by other local users on the system.
• Missing or Unmatched Key Pairs: The client is offering a different private key than the public counterpart installed on the server.
• Incorrect File Ownership or Server Permissions: The remote server’s .ssh directory or authorized_keys file has incorrect POSIX ownership or permission bits.
• Server Daemon Configuration: The remote /etc/ssh/sshd_config file has public key authentication disabled or specifies an unconventional keys path.

Step 1: Diagnose the Root Cause Using Verbose Mode

Before modifying configuration files at random, run SSH in verbose debugging mode to pinpoint exactly where the handshake fails:

ssh -vvv username@remote_host

Inspect the output lines starting with debug1:. Specifically, look for lines reading Offering public key: ... followed immediately by Authentications that can continue: publickey. If the client offers multiple keys that are all rejected, or if your specific identity file is never offered, the verbose log reveals whether the fault lies on the client or server side.

Step 2: Correct Local Client Permissions

If your local private key permissions are too broad, OpenSSH silently ignores the key to prevent credential theft. Fix your local directory permissions with these commands:

1. Open your local terminal (Ctrl + Alt + T).
2. Lock down your local .ssh directory to ensure only your user account can read, write, or enter it:

   chmod 700 ~/.ssh

3. Set strict read and write permissions on your private keys:

   chmod 600 ~/.ssh/id_rsa ~/.ssh/id_ed25519

   (Adjust the filename to match your specific key name, such as my_server_key.)
4. Ensure your public keys (ending in .pub) and known_hosts files have standard readable permissions:

   chmod 644 ~/.ssh/*.pub ~/.ssh/known_hosts

Step 3: Explicitly Specify Your Private Key

If you manage multiple SSH keys for different services (such as GitHub, GitLab, and multiple virtual private servers), your client may exhaust its maximum authentication attempts offering irrelevant default keys before reaching the correct one. Force SSH to use your designated key using the -i identity flag:

ssh -i ~/.ssh/id_ed25519 username@remote_host

To avoid typing this flag every time, create or edit your local client configuration file at ~/.ssh/config:

Host myserver
    HostName 192.168.1.100
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

The IdentitiesOnly yes directive is vital: it instructs the client to offer only the specified key, preventing “Too many authentication failures” errors.

Step 4: Load Keys into the SSH Agent

If your private key is protected by a passphrase, ensure the SSH authentication agent is running and has your key loaded into memory:

1. Start the ssh-agent in the background:

   eval "$(ssh-agent -s)"

2. Add your private key to the agent:

   ssh-add ~/.ssh/id_ed25519

3. Verify that the key is registered:

   ssh-add -l

Step 5: Fix Permissions and Configuration on the Remote Server

If you have console or recovery access to the remote Ubuntu server, verify the remote user environment:

1. Ensure the user owns their entire home and configuration structure:

   sudo chown -R $USER:$USER ~/.ssh

2. Apply correct permission bits on the remote directory and keys file:

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

3. Verify that the server configuration enables public key authentication by checking /etc/ssh/sshd_config:

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

   Ensure PubkeyAuthentication yes is present and uncommented.
4. If you made changes to the configuration, reload the OpenSSH server:

   sudo systemctl restart ssh

Systematically checking client permissions, server-side authorized keys, and daemon configuration ensures your encrypted SSH tunnels establish quickly, securely, and without authentication dropouts.