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.
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.
The most common mistake is using the wrong username. Different systems use different default users:
# 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: piWhen connecting, specify the username explicitly:
ssh username@hostname
ssh -l username hostnameNot:
ssh hostname # This uses your local username, which may not exist on the remote serverSSH requires strict permissions on your private key. It must be readable only by you:
# 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_ed25519If permissions are wrong (like 644 or 777), SSH will refuse to use the key:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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.Incorrect directory permissions also cause authentication failures:
# 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:
# Check home directory permissions
ls -ld ~
# Should be 755 (drwxr-xr-x) or more restrictive, NOT 777
# Fix if needed:
chmod 755 ~Your public key must exist in the remote server's authorized_keys file. The easiest method is ssh-copy-id:
# 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@hostnameIf ssh-copy-id is not available, do it manually:
# 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_keysIf you have multiple SSH keys, SSH tries them in order. You can specify which key to use:
# 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 myserverThe 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.
SSH agent (ssh-add) caches your keys. If you have many keys, SSH might exceed MaxAuthTries before trying the right one:
# 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_ed25519Or configure ~/.ssh/config to only use specific keys for specific hosts:
Host *
IdentitiesOnly yes
Host server1
IdentityFile ~/.ssh/key1
Host server2
IdentityFile ~/.ssh/key2Use ssh -v to see exactly what is happening during the connection:
# Single -v for basic debugging
ssh -v username@hostname
# Multiple -v for more detail
ssh -vv username@hostname
ssh -vvv username@hostname # Most verboseLook for lines indicating the authentication method being attempted:
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: passwordIf it skips directly to "authentication failures exceeded", it means MaxAuthTries was hit (see step 6 above).
On the remote server, SSH might be rejecting your authentication method. Check the server config:
# 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 attemptsIf settings need to be changed:
# Edit the config (as root)
sudo nano /etc/ssh/sshd_config
# Make changes, then restart SSH:
sudo systemctl restart sshd
# or
sudo service sshd restartAfter restarting, try connecting again.
The server logs can reveal exactly why authentication is failing:
# 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.
Older SSH servers may not support modern key types:
# 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@hostnameMost modern servers support both Ed25519 and RSA-4096. If neither works, check what the server accepts in the sshd_config:
sudo grep "PubkeyAcceptedKeyTypes" /etc/ssh/sshd_configUnderstanding 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:
# ~/.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_rsaFor CI/CD (GitHub Actions, GitLab CI, etc.):
# 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 gitThen in your workflow:
- 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'Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH