How to fix Authentication failed. in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 404 views

SSH authentication failed occurs when the server rejects your login credentials or keys. This can happen due to incorrect credentials, permission issues with key files, wrong key usage, or server configuration mismatches.

Quick fix

Fixes Authentication failed.

# Check what username you are trying
echo $USER

# Common default users:
# - Ubuntu/Debian: ubuntu
# - Amazon Linux: ec2-user
# - CentOS/RHEL: centos or ec2-user
# - Alpine: root
# - Raspberry Pi: pi
  1. Verify you are using the correct username
  2. Check private key file permissions
  3. Fix SSH directory and authorized_keys permissions
  4. Copy your public key to the remote server
ssh — error
# Check what username you are trying
echo $USER
# Common default users:
# - Ubuntu/Debian: ubuntu
# - Amazon Linux: ec2-user
# - CentOS/RHEL: centos or ec2-user
# - Alpine: root
# - Raspberry Pi: pi
Authentication failed.

What this error means

The "Authentication failed" error indicates that SSH is unable to verify your identity on the remote server. SSH authentication can fail for several reasons: - **Public key authentication failures**: Your SSH key is not in the server's `authorized_keys` file, has incorrect permissions, or the server is not configured to accept public key authentication - **Password authentication failures**: Wrong password, expired password, or the server has password authentication disabled - **Key permission issues**: Private or public key files have overly permissive permissions (not 600/644) - **Too many failed attempts**: OpenSSH cuts off connections after exceeding MaxAuthTries (default 6) - **Configuration mismatches**: Client and server have incompatible authentication methods enabled - **Agent issues**: SSH is trying multiple keys from ssh-agent, exhausting allowed attempts - **User restrictions**: The user is not allowed to log in via SSH (AllowUsers, DenyUsers directives) The error is often vague and doesn't indicate which specific authentication method failed or why, making troubleshooting require systematic checks.

Typical symptoms

  • SSH connection rejected with 'Authentication failed' or 'Permission denied'
  • Works from one machine but fails from another
  • Works with password but not with keys, or vice versa
  • Able to connect yesterday but not today
  • Multiple SSH connection attempts get blocked
  • CI/CD deployments fail at SSH connection step
  • 'Too many authentication failures' error appears
  • Connection closes immediately after attempting authentication

Common causes

  1. Private key permissions are too open (not 600 or 400)
  2. Public key not added to remote server's ~/.ssh/authorized_keys
  3. Using wrong private key for the target server
  4. SSH key has wrong file permissions (should be exactly 600 or 400)
  5. Home directory or ~/.ssh directory has overly permissive permissions
  6. Too many SSH keys in ssh-agent, exceeding MaxAuthTries limit
  7. Server has PubkeyAuthentication disabled in /etc/ssh/sshd_config
  8. Server has PasswordAuthentication disabled but you're using a password
  9. Incorrect username for the remote server
  10. Server's authorized_keys file has wrong permissions (should be 644 or 600)
  11. User account on remote server has login restrictions (AllowUsers, DenyUsers)
  12. SSH key is outdated or uses unsupported algorithm (e.g., ssh-dss on modern servers)
  13. Wrong SSH port configured
  14. Firewall blocking SSH connection before authentication attempt
  15. Server requires password change on next login (PAM configuration)

How to fix "Authentication failed."

1Verify you are using the correct username

The most common mistake is using the wrong username. Different systems use different default users:

bash
# Check what username you are trying
echo $USER

# Common default users:
# - Ubuntu/Debian: ubuntu
# - Amazon Linux: ec2-user
# - CentOS/RHEL: centos or ec2-user
# - Alpine: root
# - Raspberry Pi: pi

When connecting, specify the username explicitly:

bash
ssh username@hostname
ssh -l username hostname

Not:

bash
ssh hostname  # This uses your local username, which may not exist on the remote server
2Check private key file permissions

SSH requires strict permissions on your private key. It must be readable only by you:

bash
# Check current permissions
ls -la ~/.ssh/id_rsa

# Should look like:
# -rw------- (600) or -r-------- (400)

# Fix permissions if needed
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_ed25519

If permissions are wrong (like 644 or 777), SSH will refuse to use the key:

bash
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
3Fix SSH directory and authorized_keys permissions

Incorrect directory permissions also cause authentication failures:

bash
# On YOUR LOCAL MACHINE:
chmod 700 ~/.ssh              # Directory: drwx------
chmod 644 ~/.ssh/id_rsa.pub   # Public key: -rw-r--r--
chmod 600 ~/.ssh/id_rsa       # Private key: -rw-------

# ON THE REMOTE SERVER (after connecting):
chmod 700 ~/.ssh                 # Directory: drwx------
chmod 644 ~/.ssh/authorized_keys # File: -rw-r--r--

# Or more restrictive (also acceptable):
chmod 600 ~/.ssh/authorized_keys # File: -rw-------

The home directory itself should also not be world-writable:

bash
# Check home directory permissions
ls -ld ~

# Should be 755 (drwxr-xr-x) or more restrictive, NOT 777
# Fix if needed:
chmod 755 ~
4Copy your public key to the remote server

Your public key must exist in the remote server's authorized_keys file. The easiest method is ssh-copy-id:

bash
# Copy your default public key (~/.ssh/id_rsa.pub)
ssh-copy-id username@hostname

# Copy a specific key
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@hostname

If ssh-copy-id is not available, do it manually:

bash
# First, display your public key
cat ~/.ssh/id_rsa.pub

# Copy the entire output, then log in to the remote server
# (you may need to use password authentication temporarily)
ssh username@hostname

# On the remote server:
mkdir -p ~/.ssh
touch ~/.ssh/authorized_keys
chmod 644 ~/.ssh/authorized_keys

# Paste your public key (from above) into authorized_keys
# You can use nano, vi, or echo:
echo "ssh-rsa AAAAB3NzaC1y..." >> ~/.ssh/authorized_keys
5Specify the correct private key explicitly

If you have multiple SSH keys, SSH tries them in order. You can specify which key to use:

bash
# Use a specific key
ssh -i ~/.ssh/id_ed25519 username@hostname

# Or configure it in ~/.ssh/config
Host myserver
  HostName hostname
  User username
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

# Then just connect with:
ssh myserver

The IdentitiesOnly yes directive is crucial if you have many keys in ssh-agent. It tells SSH to only use the keys explicitly specified in the config, not all keys in the agent.

6Clean up SSH agent if you have too many keys

SSH agent (ssh-add) caches your keys. If you have many keys, SSH might exceed MaxAuthTries before trying the right one:

bash
# List all keys currently loaded in ssh-agent
ssh-add -l

# Remove all keys
ssh-add -D

# Remove a specific key
ssh-add -d ~/.ssh/old_key

# Add only the keys you need
ssh-add ~/.ssh/id_ed25519

Or configure ~/.ssh/config to only use specific keys for specific hosts:

bash
Host *
  IdentitiesOnly yes

Host server1
  IdentityFile ~/.ssh/key1

Host server2
  IdentityFile ~/.ssh/key2
7Debug with verbose SSH output

Use ssh -v to see exactly what is happening during the connection:

bash
# Single -v for basic debugging
ssh -v username@hostname

# Multiple -v for more detail
ssh -vv username@hostname
ssh -vvv username@hostname  # Most verbose

Look for lines indicating the authentication method being attempted:

bash
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

If it skips directly to "authentication failures exceeded", it means MaxAuthTries was hit (see step 6 above).

8Check server-side configuration

On the remote server, SSH might be rejecting your authentication method. Check the server config:

bash
# On the remote server (if you can access it):
sudo cat /etc/ssh/sshd_config | grep -E "^(PubkeyAuthentication|PasswordAuthentication|MaxAuthTries|AllowUsers|DenyUsers)"

# Common settings:
PubkeyAuthentication yes   # Must be yes for key-based auth
PasswordAuthentication yes # Must be yes for password auth
MaxAuthTries 6             # Number of allowed failed attempts

If settings need to be changed:

bash
# Edit the config (as root)
sudo nano /etc/ssh/sshd_config

# Make changes, then restart SSH:
sudo systemctl restart sshd
# or
sudo service sshd restart

After restarting, try connecting again.

9Check server logs for more details

The server logs can reveal exactly why authentication is failing:

bash
# On the remote server, check the auth log
sudo tail -50 /var/log/auth.log           # Ubuntu/Debian
sudo tail -50 /var/log/secure             # CentOS/RHEL
sudo log show -predicate 'process == "sshd"' -last 1h  # macOS

# Look for entries like:
# "Invalid user username from 1.2.3.4"
# "User username not allowed because account is locked"
# "Public key from 1.2.3.4 not in authorized_keys"

These messages often pinpoint the exact issue: wrong username, user restrictions, or key not found.

10Verify SSH key algorithm compatibility

Older SSH servers may not support modern key types:

bash
# Check your key type
ssh-keygen -l -f ~/.ssh/id_rsa    # RSA
ssh-keygen -l -f ~/.ssh/id_ed25519  # Ed25519

# If the server is very old and rejects Ed25519, try RSA:
ssh -i ~/.ssh/id_rsa username@hostname

# If the server is very new and rejects RSA or DSS, generate a modern key:
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@hostname

Most modern servers support both Ed25519 and RSA-4096. If neither works, check what the server accepts in the sshd_config:

bash
sudo grep "PubkeyAcceptedKeyTypes" /etc/ssh/sshd_config

Advanced notes

Understanding SSH authentication flow:

SSH tries authentication methods in this order (usually):
1. Public key authentication (using ssh-agent or keys in config)
2. GSSAPI authentication
3. Keyboard-interactive (password prompt)
4. Password authentication

After 6 failed attempts (MaxAuthTries), the connection is closed. If you have many keys in ssh-agent, each one counts as an attempt.

Why "Authentication failed" is vague:

The message "Authentication failed" doesn't distinguish between:
- Wrong password
- Public key not in authorized_keys
- Key permissions wrong
- User not allowed to log in
- Server misconfiguration
- Network timeout

This is intentional for security (not revealing which usernames exist). Always use ssh -v and server logs to diagnose.

SSH config best practices:

bash
# ~/.ssh/config - Recommended setup
Host *
  ServerAliveInterval 60
  ServerAliveCountMax 3
  IdentitiesOnly yes          # Only use explicitly configured keys
  AddKeysToAgent yes          # Automatically add keys to ssh-agent

Host myserver
  HostName example.com
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  Port 2222

Host github.com
  IdentityFile ~/.ssh/github_key

Host *
  IdentityFile ~/.ssh/id_ed25519
  IdentityFile ~/.ssh/id_rsa

For CI/CD (GitHub Actions, GitLab CI, etc.):

bash
# Generate a deployment key without passphrase
ssh-keygen -t ed25519 -f deploy_key -N ""

# Add public key to server's authorized_keys
ssh-copy-id -i deploy_key.pub user@server

# Store private key as a secret in your CI/CD platform
# Do NOT commit the private key to git

Then in your workflow:

yaml
- name: Deploy
  env:
    SSH_PRIVATE_KEY: ${{ secrets.DEPLOY_KEY }}
  run: |
    mkdir -p ~/.ssh
    echo "$SSH_PRIVATE_KEY" > ~/.ssh/deploy_key
    chmod 600 ~/.ssh/deploy_key
    ssh -i ~/.ssh/deploy_key user@server 'deploy.sh'

Frequently asked questions

What does "Authentication failed." mean?
The "Authentication failed" error indicates that SSH is unable to verify your identity on the remote server. SSH authentication can fail for several reasons: - Public key authentication failures: Your SSH key is not in the server's authorized_keys file, has incorrect permissions, or the server is not configured to accept public key authentication - Password authentication failures: Wrong password, expired password, or the server has password authentication disabled - Key permission issues: Private or public key files have overly permissive permissions (not 600/644) - Too many failed attempts: OpenSSH cuts off connections after exceeding MaxAuthTries (default 6) - Configuration mismatches: Client and server have incompatible authentication methods enabled - Agent issues: SSH is trying multiple keys from ssh-agent, exhausting allowed attempts - User restrictions: The user is not allowed to log in via SSH (AllowUsers, DenyUsers directives) The error is often vague and doesn't indicate which specific authentication method failed or why, making troubleshooting require systematic checks.
How do I fix "Authentication failed."?
SSH authentication failed occurs when the server rejects your login credentials or keys. This can happen due to incorrect credentials, permission issues with key files, wrong key usage, or server configuration mismatches.
What causes "Authentication failed."?
Private key permissions are too open (not 600 or 400) Public key not added to remote server's ~/.ssh/authorized_keys Using wrong private key for the target server
Is the "Authentication failed." 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