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

SSHINTERMEDIATEHIGH

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 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.

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 [email protected] 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 [email protected]    # Try ubuntu
ssh -i ~/.ssh/key.pem [email protected]  # Try ec2-user
ssh -i ~/.ssh/key.pem [email protected]     # 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 [email protected]

# 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 [email protected]
# 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 [email protected]

# 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 [email protected]

# 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 [email protected]

# 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 [email protected]

# Double verbose flag: shows more details (recommended)
ssh -vv [email protected]

# Triple verbose flag: shows everything
ssh -vvv [email protected]

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 [email protected]

# 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 [email protected]

# You can also restrict which keys SSH tries
ssh -i ~/.ssh/my-key.pem -o PubkeyAuthentication=yes [email protected]

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 [email protected]

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.

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

What this error means

Typical symptoms

Common causes

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

Advanced notes

Related errors

Official resources & further reading