How to Fix “Permission denied (publickey)” When Connecting with SSH

The SSH “Permission denied (publickey)” message appears when the server rejects every public key your SSH client offers. Usually, the client has the wrong username, has picked the wrong private key, or hasn’t loaded the key it needs.

ssh -i ~/.ssh/id_ed25519 username@server-ip
ssh -vvv -i ~/.ssh/id_ed25519 username@server-ip

Replace username with the account that owns the matching public key on the server. On cloud systems, that account is often ubuntu, ec2-user, debian, or azureuser.

Quick Fix Checklist

1. Check the SSH username and server address.
2. Use -i to tell SSH which private key to try.
3. Set the local private key permission to 600.
4. Make sure the matching public key is in the remote account’s ~/.ssh/authorized_keys file.
5. Fix ownership and permissions on the server.
6. Run ssh -vvv to see which key is being offered and why the server refuses it.

Why SSH Returns “Permission denied (publickey)”

Public-key authentication depends on a matching key pair. Your client proves it has the private key, while the server searches for the corresponding public key under the remote user’s account. If the account, key pair, permissions, or SSH configuration doesn’t line up, authentication stops there.

Work Through the Fix

1. Check the Remote Username

SSH checks the keys belonging to the account named in your connection command. So a key installed for ubuntu won’t automatically let you sign in as root, or as any other user.

ssh ubuntu@203.0.113.10
ssh ec2-user@203.0.113.10
ssh admin@example.com

If you don’t know the default account, check the hosting provider’s documentation or the server deployment record. Don’t assume root login is available. Quite often, it isn’t.

2. Choose the Right Private Key

Use -i so SSH doesn’t have to guess which identity it should offer:

ssh -i ~/.ssh/project_ed25519 username@server-ip

Then confirm that the public half of that key is the one installed on the server.

ssh-keygen -y -f ~/.ssh/project_ed25519
ssh-keygen -lf ~/.ssh/project_ed25519.pub

The first command derives a public key from the private key. Compare that output with the entry in the server’s authorized_keys file.

3. Tighten the Local Key Permissions

OpenSSH may refuse to use a private key if other users can read it. On Linux or macOS, set restrictive permissions on the directory and files:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/project_ed25519
chmod 644 ~/.ssh/project_ed25519.pub

Ownership matters too. Check that the files belong to your local account:

ls -la ~/.ssh

4. Inspect the SSH Agent

If you normally connect without -i, see which identities the SSH agent has loaded:

ssh-add -l

Missing key? Start the agent and add the private key yourself.

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

An agent carrying a lot of keys can cause another problem: the server may disconnect before SSH gets around to trying the correct one. In that case, name the key and limit the client to that identity.

ssh -o IdentitiesOnly=yes -i ~/.ssh/project_ed25519 username@server-ip

5. Put the Public Key on the Server

If password login still works, copy the public key with ssh-copy-id:

ssh-copy-id -i ~/.ssh/project_ed25519.pub username@server-ip

If password authentication has been disabled, you’ll need another route in. Use the hosting provider’s web console, a recovery console, or an administrator session that already works. Append the public key, as one uninterrupted line, to:

/home/username/.ssh/authorized_keys

6. Repair Server Ownership and Permissions

Run the following commands from the affected account or through an administrative console. Replace username and its group where needed.

sudo chown -R username:username /home/username/.ssh
sudo chmod 700 /home/username/.ssh
sudo chmod 600 /home/username/.ssh/authorized_keys
sudo chmod go-w /home/username

On an SELinux-enabled distribution, such as RHEL, Rocky Linux, AlmaLinux, or Fedora, restore the expected security context as well:

sudo restorecon -Rv /home/username/.ssh

7. Check the SSH Server Settings

Look at the effective OpenSSH server settings rather than trusting comments in the configuration file. Comments can be stale, or an included file may be changing the result.

sudo sshd -T | grep -E 'pubkeyauthentication|authorizedkeysfile'

Normally, the output should include pubkeyauthentication yes and an authorized-key path such as .ssh/authorized_keys. If you change the configuration, validate it before reloading SSH.

sudo sshd -t
sudo systemctl reload sshd

Debian and Ubuntu may use ssh as the service name instead:

sudo systemctl reload ssh

Keep your current console or SSH session open while you test. A bad configuration change can lock you out, and that existing session may be the only easy way back in.

Read the Verbose SSH Output

ssh -vvv -o IdentitiesOnly=yes -i ~/.ssh/project_ed25519 username@server-ip

Watch for lines containing Offering public key and Server accepts key. If the expected key never gets offered, the fault is probably on the client side. If SSH offers the right key and the server rejects it, check the username, the server’s public-key entry, file permissions, and the SSH logs.

Depending on the distribution, authentication messages may appear in one of these locations:

sudo journalctl -u sshd --since '10 minutes ago'
sudo journalctl -u ssh --since '10 minutes ago'
sudo tail -f /var/log/auth.log

Save the Working Connection

Once the connection works, save the account and identity in ~/.ssh/config. That way, you don’t have to type the full command every time.

Host project-server
    HostName 203.0.113.10
    User ubuntu
    IdentityFile ~/.ssh/project_ed25519
    IdentitiesOnly yes

Set the configuration file permission, then connect through the alias:

chmod 600 ~/.ssh/config
ssh project-server

Mistakes That Commonly Cause This Error

• Putting the public key in the wrong user’s home directory.
• Using a cloud instance name instead of a reachable IP address or hostname.
• Copying the private key into authorized_keys.
• Splitting one public key across multiple lines.
• Closing the only working server session before testing configuration changes.
• Making ~/.ssh or authorized_keys world-writable.

Confirm That Authentication Works

Run a non-interactive command over SSH:

ssh -o IdentitiesOnly=yes -i ~/.ssh/project_ed25519 username@server-ip 'whoami'

If authentication succeeds, the command prints the remote username. You can then use the same identity with SCP, SFTP, Git, automation tools, or the SSH configuration you saved.