How to fix Permission denied (publickey,password). in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 473 views

The "Permission denied (publickey,password)" error means SSH authentication failed using both public key and password methods. Both authentication methods were either disabled on the server or the credentials provided don't match what the server expects. This is one of the most common SSH connection problems.

Quick fix

Fixes Permission denied (publickey,password).

ssh -v ubuntu@example.com 2>&1 | grep "Offering public key"
  1. Verify you're using the correct username
  2. Verify your private key is readable and in correct format
  3. Check that authorized_keys file exists and has correct permissions
  4. Add your public key to authorized_keys on the server
ssh — error
ssh -v ubuntu@example.com 2>&1 | grep "Offering public key"
Permission denied (publickey,password).

What this error means

When SSH displays "Permission denied (publickey,password)", it indicates that the server tried and rejected both public key and password authentication methods. This error tells you: 1. The server is running SSH and responding 2. The TCP connection succeeded (port 22 is reachable) 3. Authentication failed—no valid credentials were accepted The error message itself intentionally doesn't reveal which method failed or why, for security reasons. The server logs will show the real reason, but the client only sees this generic message. The fact that BOTH publickey and password are mentioned means the server had these methods available, but both failed. If either method had succeeded, you wouldn't see this error.

Typical symptoms

  • SSH connection fails with 'Permission denied (publickey,password).'
  • Manual SSH works from one computer but fails from another
  • Can't connect to a fresh cloud instance
  • Error appears immediately after SSH connects (so port 22 is reachable)
  • Works with one username but not another
  • Started happening after changing SSH configuration
  • Ansible, SCP, or Git over SSH also fail with the same error
  • Error doesn't say 'Connection refused'—it says 'Permission denied'

Common causes

  1. Public key in authorized_keys file on server doesn't match your private key
  2. authorized_keys file has incorrect permissions (should be 600) or wrong ownership
  3. .ssh directory has incorrect permissions (should be 700) or wrong ownership
  4. Home directory has overly permissive permissions (should be 700, not 777)
  5. PasswordAuthentication is disabled in sshd_config but you tried password login
  6. PubkeyAuthentication is disabled in sshd_config
  7. Using wrong username (e.g., root instead of ubuntu, ec2-user instead of admin)
  8. Private key is password-protected and SSH couldn't unlock it
  9. Private key was copied as multiple lines instead of one continuous line
  10. Wrong private key being used (multiple keys and SSH chose the wrong one)
  11. Host key mismatch or old host key cached in known_hosts
  12. SSH service on server isn't fully initialized or has stopped

How to fix "Permission denied (publickey,password)."

1Verify you're using the correct username

Different systems have different default SSH users. Check what user you're connecting as:

bash
ssh -v ubuntu@example.com 2>&1 | grep "Offering public key"

If you get "Permission denied", try the correct default user for your system:

| System | Default User |
|--------|--------------|
| Ubuntu (AWS, Azure, DigitalOcean) | ubuntu |
| Amazon Linux 2, RHEL, CentOS (AWS) | ec2-user |
| Debian | admin |
| Alpine | root |
| Raspberry Pi OS | pi |
| Custom servers | depends on setup |

Example with different users:

bash
ssh -i ~/.ssh/key.pem ubuntu@example.com    # Try ubuntu
ssh -i ~/.ssh/key.pem ec2-user@example.com  # Try ec2-user
ssh -i ~/.ssh/key.pem admin@example.com     # Try admin

Check your cloud provider's documentation if unsure. The AMI or image description usually lists the correct username.

2Verify your private key is readable and in correct format

Check your private key exists and is in the right format:

bash
# Check the file exists and is readable
ls -la ~/.ssh/my-key.pem

# Verify it's a valid SSH key (starts with BEGIN)
head -1 ~/.ssh/my-key.pem
# Should output: -----BEGIN RSA PRIVATE KEY----- or -----BEGIN OPENSSH PRIVATE KEY-----

# Check permissions (should be 600 or 400)
stat -c "%A" ~/.ssh/my-key.pem
# Should output: -rw------- (600)

If permissions are wrong, fix them:

bash
chmod 600 ~/.ssh/my-key.pem

If your key starts with something other than "BEGIN RSA PRIVATE KEY" or "BEGIN OPENSSH PRIVATE KEY", it's corrupted or in the wrong format. Regenerate the key pair.

3Check that authorized_keys file exists and has correct permissions

On the server, the public key must be in ~/.ssh/authorized_keys with correct permissions:

bash
# SSH into the server using a method that works (if possible)
ssh -i ~/.ssh/key.pem ubuntu@example.com

# Once connected, check authorized_keys
ls -la ~/.ssh/
ls -la ~/.ssh/authorized_keys

# Permissions should be:
# -rw------- (600) for authorized_keys
# drwx------ (700) for .ssh directory

If permissions are wrong, fix them:

bash
# Fix directory permissions
chmod 700 ~/.ssh

# Fix authorized_keys permissions
chmod 600 ~/.ssh/authorized_keys

If the file doesn't exist, create it:

bash
mkdir -p ~/.ssh
touch ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If the server uses a custom AuthorizedKeysFile location (check /etc/ssh/sshd_config), verify the file exists at that location instead.

4Add your public key to authorized_keys on the server

The public key from your private key must be in the server's authorized_keys. First, extract your public key from the private key:

bash
# Extract public key from your private key
ssh-keygen -y -f ~/.ssh/my-key.pem > ~/.ssh/my-key.pub

Then add it to authorized_keys on the server. You have two options:

Option 1: Use ssh-copy-id (easiest if you can authenticate once)

bash
ssh-copy-id -i ~/.ssh/my-key.pem ubuntu@example.com
# Follow prompts (may ask for password)

Option 2: Manually append to authorized_keys

bash
# First, get your public key content
cat ~/.ssh/my-key.pub

# Then SSH to the server (using any available method)
ssh ubuntu@example.com

# Add the public key to authorized_keys (one line per key, no line breaks)
echo "YOUR_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys

# Verify it was added
cat ~/.ssh/authorized_keys

Important: The public key must be on ONE continuous line. If it wrapped to multiple lines when you pasted it, the authentication will still fail. Use single-line format.

5Check server's SSH configuration for disabled authentication

The server might have public key or password authentication disabled. Check the server's SSH config:

bash
# SSH to the server using any available method
ssh ubuntu@example.com

# Check sshd configuration
grep -E "^(PubkeyAuthentication|PasswordAuthentication)" /etc/ssh/sshd_config

# Should output:
# PubkeyAuthentication yes
# PasswordAuthentication yes

If either is set to "no", enable it:

bash
# Edit the SSH server configuration
sudo nano /etc/ssh/sshd_config

# Find and modify (or add) these lines:
PubkeyAuthentication yes
PasswordAuthentication yes

# Save and exit (Ctrl+O, Enter, Ctrl+X in nano)

# Restart SSH service to apply changes
sudo systemctl restart sshd
# Or on older systems:
sudo service ssh restart

After restarting SSH, your client should be able to connect.

6Check home directory permissions on server

SSH will refuse key-based authentication if the home directory has overly permissive permissions:

bash
# SSH to the server using any working method
ssh ubuntu@example.com

# Check home directory permissions
ls -ld ~

# Should show something like:
# drwx------ (700) - only owner can read/write/execute

If permissions are too open (like 777, 755, or 755), fix them:

bash
# Fix home directory permissions
chmod 700 ~

# Also check .ssh directory
chmod 700 ~/.ssh

# And authorized_keys file
chmod 600 ~/.ssh/authorized_keys

Even if the authorized_keys file has correct permissions, SSH checks the parent directories. All directories in the path must be secured (700 or 750, never 777 or 755).

7Use SSH verbose mode to see what's happening

Enable verbose SSH output to see exactly which authentication methods are being tried:

bash
# Single verbose flag: shows some details
ssh -v ubuntu@example.com

# Double verbose flag: shows more details (recommended)
ssh -vv ubuntu@example.com

# Triple verbose flag: shows everything
ssh -vvv ubuntu@example.com

Look for lines like:
- Offering public key:... - shows which keys were tried
- Authentications that can continue: publickey,password - shows available methods
- Permission denied (publickey,password) - final failure

Example of useful output:

bash
Offering public key: /home/user/.ssh/id_rsa RSA SHA256:xxxxx
Authentications that can continue: publickey,password
Permission denied (publickey,password).

The verbose output will show:
1. Which private keys SSH tried
2. Whether it succeeded with any key
3. What methods the server allows
4. Where exactly the authentication failed

8Check server logs to see the real error

Server-side logs reveal the actual reason for the authentication failure (the client only gets a generic message):

bash
# SSH to the server using any available method
ssh ubuntu@example.com

# Check SSH server logs (location varies by OS)
# Linux (most systems):
sudo tail -20 /var/log/auth.log

# Or:
sudo tail -20 /var/log/secure

# Or with journal (systemd):
sudo journalctl -u sshd -n 20 --no-pager

# Look for lines mentioning your username and the authentication failure

Server logs will show messages like:
- Invalid user: ... - wrong username
- user not allowed because account is locked - account disabled
- Received disconnect - client disconnected
- Authentication refused: bad ownership or modes - file permission issue
- no matching key exchange method found - SSH version mismatch

Once you find the actual error in the logs, it's much easier to fix.

9If using multiple SSH keys, specify the correct one explicitly

If you have multiple SSH keys, SSH might try the wrong one first:

bash
# List all your SSH keys
ls -la ~/.ssh/

# Try with a specific key
ssh -i ~/.ssh/my-specific-key.pem ubuntu@example.com

# You can also restrict which keys SSH tries
ssh -i ~/.ssh/my-key.pem -o PubkeyAuthentication=yes ubuntu@example.com

If a specific key works, add only that key to your SSH agent:

bash
# Clear old keys from SSH agent
ssh-add -D

# Add only the key that works
ssh-add ~/.ssh/my-working-key.pem

# Now connections should use that key by default
ssh ubuntu@example.com

Advanced notes

Understanding the error message:

The error "Permission denied (publickey,password)" is misleading. The parentheses show the authentication methods the server tried (in the order it configured them), not necessarily what's available on your system. If both methods appear but both failed, it means you either:
1. Didn't have the right credentials for either method
2. Server-side permissions prevent using those methods
3. The server has those methods available but disabled them for your account

SSH is intentionally vague for security—it doesn't tell you which method failed or why, preventing attackers from getting hints about valid usernames.

Common scenarios by authentication method:

Public key failed: The public key on the server doesn't match your private key, or the file permissions are wrong (home dir, .ssh dir, authorized_keys, or the private key itself).

Password failed: You entered the wrong password, or PasswordAuthentication is disabled in sshd_config, or the account is locked/disabled.

Both failed: You don't have valid credentials for either method. This is the "Permission denied (publickey,password)" error—both attempts failed.

SSH key verification and known_hosts:

Sometimes the error appears because of host key verification issues (first connection to a host). The remote host is refusing the connection before authentication happens. Check your SSH client's StrictHostKeyChecking setting if you're scripting SSH connections.

Default users across platforms:

Different cloud providers and Linux distributions use different default users for security. Using "root" or the wrong user is one of the most common reasons for this error on fresh instances. Always check the provider's documentation for the default SSH user.

Passwordless sudo and automation:

If you're using this for automation (Ansible, Terraform, automation scripts), the connecting user often needs passwordless sudo. After getting SSH key access working, you may also need to configure sudo in the server's sudoers file to avoid password prompts during provisioning.

Frequently asked questions

What does "Permission denied (publickey,password)." mean?
When SSH displays "Permission denied (publickey,password)", it indicates that the server tried and rejected both public key and password authentication methods. This error tells you: 1. The server is running SSH and responding 2.
How do I fix "Permission denied (publickey,password)."?
The "Permission denied (publickey,password)" error means SSH authentication failed using both public key and password methods. Both authentication methods were either disabled on the server or the credentials provided don't match what the server expects. This is one of the most common SSH connection problems.
What causes "Permission denied (publickey,password)."?
Public key in authorized_keys file on server doesn't match your private key authorized_keys file has incorrect permissions (should be 600) or wrong ownership .ssh directory has incorrect permissions (should be 700) or wrong ownership
Is the "Permission denied (publickey,password)." error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading