Table of Contents
Introduction
Few error messages are as frustrating — or as vague — as this one:
Permission denied (publickey,password).You try to SSH into a server, you’re confident the password or key is right, and yet the door slams shut. The message tells you that authentication failed, but not why. The part in parentheses, (publickey,password), is actually a clue: it lists the authentication methods the server is willing to accept. Your client tried them all, and every one was rejected.
This guide walks through the causes in the order you should check them — from the quick wins to the deeper issues — so you can diagnose and fix the problem methodically instead of guessing.
First: Understand What the Error Is Telling You
The message Permission denied (publickey,password) means two things:
- The SSH connection to the server succeeded — you reached
sshdand negotiated a session. This is not a network or firewall problem. - Authentication failed. The server offered these methods (
publickey,password), your client attempted them, and none satisfied the server.
So the problem lies squarely in authentication — your key, your password, your username, or the server’s configuration.
Step 1: Run SSH in Verbose Mode (Always Start Here)
Before changing anything, get more information. The -v (verbose) flag reveals exactly what the client and server negotiate. Use -vvv for maximum detail.
ssh -vvv user@server-ipLook for lines like these:
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/user/.ssh/id_ed25519
debug1: Server accepts key: ...
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Next authentication method: passwordThis output tells you which keys the client is offering, whether the server accepts any of them, and where it falls back to password auth. Nine times out of ten, the verbose log points straight at the cause. Keep this terminal open as you work through the steps below.
Step 2: Verify the Username and Hostname
The most common — and most embarrassing — cause is simply the wrong username.
# Wrong: using your local username on the remote host
ssh server-ip
# Right: specify the correct remote account explicitly
ssh ubuntu@server-ipDifferent distributions and cloud images use different default users:
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
| Platform | Default Username |
|---|---|
| Ubuntu (AWS, cloud images) | ubuntu |
| Amazon Linux | ec2-user |
| Debian | debian or admin |
| CentOS / RHEL | centos / cloud-user / ec2-user |
| Fedora | fedora |
| Generic VPS | often root |
If you omit the username, SSH uses your local username, which usually doesn’t exist on the server. Always be explicit.
Step 3: Fix Key and Directory Permissions (The #1 Cause)
SSH is deliberately paranoid about file permissions. If your private key, .ssh directory, or authorized_keys file is readable by anyone other than the owner, SSH silently refuses to use them. This is the single most frequent cause of this error.
On the Client (your machine)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 # your private key
chmod 644 ~/.ssh/id_ed25519.pub # your public key
chmod 600 ~/.ssh/config # if you have oneOn the Server
The permissions on the server side matter just as much — this is what people most often miss:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# Critical: your home directory must NOT be group- or world-writable
chmod 755 ~⚠️ The home directory trap: If your home directory (
~) is writable by group or others (e.g.,775or777),sshdrejects key authentication even when everything else is perfect. Set it to755or stricter.
Ownership matters too
Make sure everything is owned by the correct user, not root:
chown -R user:user ~/.sshStep 4: Confirm the Public Key Is in authorized_keys
For key-based login, your public key must be present in ~/.ssh/authorized_keys on the server.
The Easy Way: ssh-copy-id
If you can still log in another way (e.g., password, or a console), the cleanest method is:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ipThis appends your public key correctly and fixes permissions automatically.
The Manual Way
If ssh-copy-id isn’t available, add it by hand:
# On the server
mkdir -p ~/.ssh
echo "ssh-ed25519 AAAAC3Nza... user@laptop" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysVerify the key actually matches. Compare the fingerprint of your local private key against what’s on the server:
# On the client — show your key's fingerprint
ssh-keygen -lf ~/.ssh/id_ed25519.pub
# On the server — show the fingerprint of each authorized key
ssh-keygen -lf ~/.ssh/authorized_keysIf the fingerprints don’t match, you’ve added the wrong key.
Step 5: Make Sure the Client Is Offering the Right Key
If you have multiple keys, SSH may be offering the wrong one, or not offering yours at all. Point it explicitly at the correct private key:
ssh -i ~/.ssh/id_ed25519 user@server-ipTo make this permanent, add an entry to ~/.ssh/config:
Host myserver
HostName server-ip
User ubuntu
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yesThe IdentitiesOnly yes line is important: without it, SSH may offer every key it knows about and get rejected for trying too many before reaching the right one (some servers disconnect after MaxAuthTries).
Check your SSH agent
Sometimes the key just isn’t loaded into the agent:
ssh-add -l # list keys currently loaded
ssh-add ~/.ssh/id_ed25519 # add your key if it's missingStep 6: Check the Server’s sshd_config
If the client side is correct, the server’s SSH daemon configuration may be blocking you. Inspect sshd_config:
sudo grep -Ei 'PubkeyAuthentication|PasswordAuthentication|PermitRootLogin|AllowUsers|DenyUsers|AllowGroups' /etc/ssh/sshd_configCheck these directives:
| Directive | What to Verify |
|---|---|
PubkeyAuthentication | Must be yes for key login |
PasswordAuthentication | Must be yes if you’re using a password |
PermitRootLogin | If logging in as root, this must allow it (yes or prohibit-password) |
AllowUsers / AllowGroups | If set, your user/group must be listed |
DenyUsers / DenyGroups | Make sure your user isn’t blocked here |
AuthorizedKeysFile | Confirm it points to .ssh/authorized_keys |
Also check for included config fragments, which often override the main file:
sudo ls /etc/ssh/sshd_config.d/
sudo grep -R "PasswordAuthentication\|PubkeyAuthentication" /etc/ssh/sshd_config.d/💡 On many modern cloud images,
PasswordAuthenticationis set tonoby default — so a password will always fail, and key-based login is the only option.
After any change, restart the SSH service:
sudo systemctl restart sshd # or 'ssh' on Debian/Ubuntu⚠️ Safety tip: Keep your current SSH session open while you test a new one from another terminal. If you lock yourself out with a bad config, you’ll still have a way back in.
Step 7: Read the Server-Side Logs
The client only sees “Permission denied.” The server knows the real reason. If you have another way in (console, another user), check the auth log:
# Debian/Ubuntu
sudo tail -f /var/log/auth.log
# RHEL/CentOS/Fedora
sudo tail -f /var/log/secure
# Or via journald on any systemd system
sudo journalctl -u sshd -fThen attempt the failing login. You’ll often see a precise reason, such as:
Authentication refused: bad ownership or modes for directory /home/user
User user not allowed because account is locked
Invalid user user from ...These messages tell you exactly what to fix — permissions, a locked account, or a bad username.
Step 8: Check for SELinux Issues
On RHEL-family systems with SELinux enforcing, an incorrectly labeled .ssh directory (common after manually creating or copying it) will block key authentication even when permissions look perfect.
# Check for SSH-related denials
sudo ausearch -m avc -ts recent | grep ssh
# Restore the correct SELinux context on the user's SSH files
sudo restorecon -Rv ~/.sshIf you created ~/.ssh by copying from elsewhere, its SELinux type may be wrong (e.g., not ssh_home_t). restorecon resets it to what the policy expects. This is a frequently missed cause on SELinux systems.
Step 9: Account-Level Problems
Finally, verify the account itself is usable:
# Is the account locked? An exclamation mark (!) before the hash means locked
sudo passwd -S user
# Check the login shell — /sbin/nologin or /bin/false will block interactive login
grep "^user:" /etc/passwd
# Has the password/account expired?
sudo chage -l userA locked account, an expired password, or a nologin shell will all produce authentication failures regardless of correct keys or passwords.
The Most Common Fixes, Summarized
In practice, this error is almost always one of these five things:
- Wrong username — using
rootor your local username instead of the cloud image’s default. - Bad permissions —
~/.ssh, the private key,authorized_keys, or the home directory are too open. - Key not in
authorized_keys— or the wrong public key was added. sshd_configrestrictions —PasswordAuthentication no, or anAllowUserslist that excludes you.- SELinux mislabeling — a manually created
~/.sshwith the wrong context.
Work through them in order, keep a verbose session and the server logs open, and you’ll almost always find the culprit quickly.
Conclusion
Permission denied (publickey,password) isn’t one problem — it’s a category of authentication failures wearing the same generic mask. The key to fixing it fast is to stop guessing and start reading: run ssh -vvv on the client, tail /var/log/auth.log (or /var/log/secure) on the server, and let the two sides tell you where the mismatch is. From there, it’s almost always a permissions fix, a username correction, or a config toggle away.
And a final piece of hard-won advice: whenever you edit sshd_config, keep an existing session open and test from a second terminal. The only thing worse than this error is locking yourself out of the server entirely while trying to fix it.
