Quick answer
The permission denied publickey error means the server did not accept your public key, even though the password may be correct. The most common culprits are a wrong key on the client, incorrect permissions on ~/.ssh and authorized_keys, or a setting in sshd_config. Check them in order and access is restored without reinstalling.
How to recognize the problem
- SSH login fails with the message Permission denied (publickey)
- The password is not requested or the server rejects it immediately
- The same key worked yesterday, but not today
- Login works from one computer but not from another
- After changing the user or reinstalling the server, the key is rejected
Most common causes
Wrong or missing private key
The SSH client is trying to log in with a key the server does not know, or the key is not loaded into the agent. Check which key is actually offered to the server.
Incorrect permissions on .ssh and authorized_keys
If the home directory, ~/.ssh, or authorized_keys have permissions that are too broad, sshd rejects them for security reasons. This is the most common cause after manually copying files.
The key is not in authorized_keys for that user
The key was added to the wrong account, for example root instead of deploy, or the file was overwritten instead of appended. The server then has nothing to compare.
sshd_config does not allow key login
Options like PubkeyAuthentication, AuthorizedKeysFile, or AllowUsers can disable the key or the user. After changing the configuration, the service must be reloaded.
SELinux or home directory with the wrong context
On systems with SELinux, the file may have the wrong security context even though the permissions are correct. Restorecon usually solves the problem.
Step-by-step fix
- 1
Read the exact message and user
Run the login with
-vto see details:ssh -v user@server. In the output, look for which keys the client offers and whether the server rejects all of them. Also check that you are using the right user and port, because the error often occurs for only one account. - 2
Check which key the client is using
On the client, run
ssh-add -lto see the keys in the agent. If a different key is needed, specify it explicitly:ssh -i ~/.ssh/id_ed25519 user@server. In~/.ssh/config, you can addIdentityFileandIdentitiesOnly yesfor the host so the client does not offer the wrong keys. - 3
Compare the key fingerprint with the server
On the client, calculate the fingerprint:
ssh-keygen -lf ~/.ssh/id_ed25519.pub. On the server, if you have another access method, checkssh-keygen -lf ~/.ssh/authorized_keys. The fingerprints must match; if they do not, the key was not added or was added to the wrong user. - 4
Fix permissions on the server
Log in via the console or another account and run (replace
userwith the actual name and/home/userwith the actual path to the home directory; if you are not root, addsudo):chmod 700 /home/user/.ssh,chmod 600 /home/user/.ssh/authorized_keys,chmod go-w /home/userandchown -R user:user /home/user/.ssh. The owner of.sshandauthorized_keysshould be that user. If you are unsure about the existing permissions, first record them withstat -c '%a %U:%G' /home/user /home/user/.ssh /home/user/.ssh/authorized_keys. This solves most cases after manual copying. - 5
Add the public key in the right place
Add the contents of the
id_ed25519.pubfile to/home/user/.ssh/authorized_keysfor that user, on a new line, without deleting existing ones. If you usessh-copy-id, check that the target user is correct. After the change, recheck the permissions from the previous step. - 6
Check sshd_config
In
/etc/ssh/sshd_config(or a file insshd_config.d), checkPubkeyAuthentication yes,AuthorizedKeysFile .ssh/authorized_keys, and thatAllowUsersorDenyUsersare not blocking you. Make a copy of the file before changing it. After the change, runsudo sshd -tto check the syntax. - 7
Reload the SSH service
If the configuration is correct, apply it with
sudo systemctl reload sshd(on Debian/Ubuntu:sudo systemctl reload ssh). Reload is safer than restart because it does not interrupt existing sessions. Then try logging in from a new terminal without closing the old one. - 8
Fix the SELinux context if enabled
On systems with SELinux, run
sudo restorecon -Rv /home/user/.ssh. Check the status withgetenforce. If the problem persists, look for key rejection messages in the log/var/log/secureor/var/log/auth.log. Do not disable SELinux permanently.
If nothing helps: console access and a backup account
When the key does not work even after all checks, use the provider's console or KVM access to the server and log in with a password or via recovery mode. Then read the exact reason for rejection from /var/log/auth.log or /var/log/secure, because sshd logs there whether the problem is permissions, ownership, or configuration. A good practice is to always have a second administrative account with a key and not to disable PasswordAuthentication until you confirm the key works. If the server is in the cloud, also check whether the public key is associated with the instance in the provider's control panel, because it is sometimes lost when the instance is recreated.
How to prevent it
- Keep a backup administrative account with a valid key
- After every change to sshd_config, check the syntax with `sudo sshd -t` before reloading
- Use `ssh-copy-id` and do not copy files manually without setting permissions
- Occasionally check that the key in the agent matches the one on the server
When to call a professional
If you do not have console access, a backup account, or a valid key, and the server is production, it is better to contact IT support than to experiment with sshd_config and risk losing access completely.
IT infrastructure maintenance · Servers, networks, backup, security and helpdeskFAQ
Is the publickey error related to the password?
No. The message Permission denied (publickey) means the server rejected the key, not the password. The password is not checked at all if key login is the only allowed method.
Why does the key work for root but not for a regular user?
Because authorized_keys is read from the home directory of the logged-in user. A key added to root's home directory does not apply to another account, and permissions and ownership are checked separately for each user.
Can I restore password login until I fix the key?
You can, if you have console access and a password is set. Temporarily enable `PasswordAuthentication yes` in sshd_config, reload, and immediately after fixing the key set that option back to `no`. This is a security risk, so use a strong password and, if possible, restrict access with a firewall.