This error occurs when SSH has exhausted all available authentication methods on the remote server without successfully authenticating. It means the client tried every configured authentication method but all were rejected, usually because the required credentials weren't provided or don't match what's configured on the server.
SSH authentication is a multi-step process where the client and server negotiate which authentication methods are available and acceptable. This error appears after the SSH protocol handshake completes but authentication fails at the application level. The server has either rejected all authentication attempts (publickey, password, keyboard-interactive, etc.) or disabled authentication methods that you're trying to use. When SSH says "no more authentication methods to try," it means it cannot offer any additional credentials to the server.
Use verbose SSH mode to see what authentication methods the server is offering:
ssh -v [email protected]Look for lines like:
Authentications that can continue: publickey,passwordThis tells you what the server will accept. If you only see publickey but you're trying to use password, that's your problem.
Check that your private key file exists and has correct permissions:
ls -l ~/.ssh/id_rsaShould output something like:
-rw------- 1 user group 1704 Jan 15 10:30 /home/user/.ssh/id_rsaIf the file doesn't exist, generate a new SSH key:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ""If permissions are wrong, fix them:
chmod 600 ~/.ssh/id_rsaInstead of relying on SSH to find your key automatically, specify it directly:
ssh -i ~/.ssh/id_rsa [email protected]For non-default key locations or names:
ssh -i ~/.ssh/my-custom-key [email protected]For Git operations:
GIT_SSH_COMMAND="ssh -i ~/.ssh/id_ed25519" git clone [email protected]:user/repo.gitFor SCP or rsync:
scp -i ~/.ssh/id_rsa file.txt [email protected]:/destination/Copy your public key to the server's authorized_keys file. If you have temporary password access:
ssh-copy-id -i ~/.ssh/id_rsa [email protected]Or manually:
cat ~/.ssh/id_rsa.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"If you don't have any access to the server, you'll need to:
- Request the server administrator add your public key
- Use a different authentication method that's enabled
- Contact your hosting provider if it's a cloud instance
If you have a ~/.ssh/config file, verify it correctly specifies your identity:
cat ~/.ssh/configLook for entries like:
Host example.com
User myuser
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yesIf the IdentityFile path is wrong or doesn't exist, SSH will fail. Fix the path if needed.
If you don't have a config file but want to set it up:
cat >> ~/.ssh/config << EOF
Host example.com
User myuser
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yes
EOF
chmod 600 ~/.ssh/configIf you're relying on SSH agent, verify your key is loaded:
ssh-add -lThis lists all keys in the agent. If your key isn't listed, add it:
ssh-add ~/.ssh/id_rsaIf your key is password-protected, this will prompt for the passphrase once.
On macOS with M1/M2 chips using newer OpenSSH, add to ~/.ssh/config:
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_rsaDifferent operating systems and hosting providers use different default SSH users:
# Amazon EC2 (Ubuntu)
ssh -i ~/.ssh/key.pem ubuntu@ec2-instance-ip
# Amazon EC2 (Amazon Linux 2)
ssh -i ~/.ssh/key.pem ec2-user@ec2-instance-ip
# DigitalOcean (Ubuntu)
ssh -i ~/.ssh/key.pem root@droplet-ip
# Linode (Ubuntu)
ssh -i ~/.ssh/key.pem root@linode-ip
# Heroku Dyno
ssh -i ~/.ssh/key.pem [email protected]
# GitHub
ssh -i ~/.ssh/key.pem [email protected]
# Bitbucket
ssh -i ~/.ssh/key.pem [email protected]Check your hosting provider's documentation if unsure which user to use.
If you've made many failed authentication attempts, the server may temporarily block further attempts. Check server-side logs if you have access:
# On the remote server
sudo tail -f /var/log/auth.log # Linux
sudo log stream --predicate 'eventMessage contains[cd] "sshd"' --level debug # macOSLook for patterns like:
sshd: Received disconnect from X.X.X.X port XXXX [preauth]
sshd: Connection closed by authenticating user user X.X.X.X port XXXX [preauth]
sshd: Too many authentication failures for userIf you're locked out, wait 15-30 minutes or ask the server administrator to reset the auth counter.
Also check for IP-based access restrictions (firewall, fail2ban):
sudo iptables -L -n # Check firewall rules
sudo fail2ban-client status sshd # Check fail2ban statusAdvanced troubleshooting tips:
MaxAuthTries Limit: SSH servers limit authentication attempts (default 6) to prevent brute force attacks. If SSH tries many keys from an agent before reaching your correct key, the server closes the connection. Set IdentitiesOnly yes in ~/.ssh/config to prevent this.
PKCS#11 and Hardware Keys: If you're using hardware security keys or PKCS#11 modules, the SSH client might prefer those over regular keys. Explicitly specify IdentityFile and use IdentitiesOnly yes to control which keys are offered.
SELinux and AppArmor: Some Linux distributions with SELinux or AppArmor enabled may restrict SSH's ability to read private keys from certain directories. Ensure the key file is in an accessible location and has correct SELinux contexts if applicable.
ssh-agent and tmux/screen: If you're running commands in tmux or screen sessions, the SSH_AUTH_SOCK environment variable might not be inherited properly. Reconnect to your agent session or explicitly pass the socket: SSH_AUTH_SOCK=/tmp/ssh-agent.sock ssh user@host.
Different Keys for Different Hosts: Use Host blocks in ~/.ssh/config to specify different keys for different servers, preventing key exhaustion on servers with low MaxAuthTries:
Host github.com
IdentityFile ~/.ssh/github_key
IdentitiesOnly yes
Host bitbucket.org
IdentityFile ~/.ssh/bitbucket_key
IdentitiesOnly yesSomeone 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