How to fix No more authentication methods to try. in SSH

Use verbose SSH mode to see what authentication methods the server is offering and which keys your client is trying:

ssh -v [email protected]

Look for lines like:

debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey

This tells you what the server will accept. If the server only lists publickey but you expected to use a password, password auth is disabled server-side. If you see SSH offering several keys in a row before the connection drops, you are likely hitting the server's MaxAuthTries limit (see step 8).

Check that your private key file exists and has correct permissions:

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_rsa 2>/dev/null

A usable key should look like:

-rw------- 1 user group 411 Jan 15 10:30 /home/user/.ssh/id_ed25519

If you have no key at all, generate one (Ed25519 is the modern default; use RSA 4096 only if you need compatibility with older servers):

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

If permissions are too open, SSH will silently refuse the key. Fix them:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

Instead of relying on SSH to find your key automatically, point it at the exact key:

ssh -i ~/.ssh/id_ed25519 [email protected]

For a non-default key name or location:

ssh -i ~/.ssh/my-custom-key [email protected]

For Git operations (works with GitHub, GitLab, Bitbucket, etc.):

GIT_SSH_COMMAND="ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes" git clone [email protected]:user/repo.git

For SCP or rsync:

scp -i ~/.ssh/id_ed25519 file.txt [email protected]:/destination/
rsync -e "ssh -i ~/.ssh/id_ed25519" file.txt [email protected]:/destination/

Adding -o IdentitiesOnly=yes ensures only this key is offered, which also helps avoid the MaxAuthTries problem in step 8.

If the server has no matching authorized key, you must register your public key. If you still have temporary password access:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

Or add it manually with correct permissions:

cat ~/.ssh/id_ed25519.pub | ssh [email protected] \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

If you have no access to the server at all, you'll need to:

- Ask the server administrator to add your public key.
- Use a different authentication method that is enabled.
- For a cloud instance, use the provider's console/recovery flow (e.g. EC2 Instance Connect, a serial console, or attaching the volume to another instance) to install the key.

If you have a ~/.ssh/config file, verify it points at the correct identity for this host:

cat ~/.ssh/config

A correct entry looks like:

Host example.com
    HostName host.example.com
    User myuser
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

If the IdentityFile path is wrong or the file doesn't exist, SSH may fall through to other keys and then run out of methods. Fix the path as needed.

If you don't have a config file yet, create one:

cat >> ~/.ssh/config << 'EOF'
Host example.com
    HostName host.example.com
    User myuser
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
EOF

chmod 600 ~/.ssh/config

If you rely on the SSH agent, confirm your key is loaded:

ssh-add -l

This lists the keys the agent currently holds. If your key isn't listed, add it:

ssh-add ~/.ssh/id_ed25519

If the key is passphrase-protected, this prompts for the passphrase once.

On macOS, you can have the key loaded from the Keychain automatically by adding this to ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

A very common cause of this error is connecting as the wrong user. Cloud images ship with a specific default login user, and using the wrong one means none of your keys will be accepted.

# Amazon EC2 - Ubuntu AMI
ssh -i ~/.ssh/key.pem ubuntu@<ec2-public-ip>

# Amazon EC2 - Amazon Linux / RHEL
ssh -i ~/.ssh/key.pem ec2-user@<ec2-public-ip>

# Amazon EC2 - Debian
ssh -i ~/.ssh/key.pem admin@<ec2-public-ip>

# DigitalOcean / Linode default droplet (often root, unless you created another user)
ssh -i ~/.ssh/id_ed25519 root@<server-ip>

# Google Compute Engine (the username gcloud/OS Login assigns you)
ssh -i ~/.ssh/google_compute_engine <your-username>@<gce-public-ip>

Check your provider's documentation for the correct default user on your image.

Note: managed Git hosts and PaaS platforms are NOT raw SSH shells, so the patterns above don't apply to them:

- GitHub / GitLab / Bitbucket only accept Git over SSH using a key in your agent (not a .pem). Test connectivity with ssh -T [email protected] (or [email protected] / [email protected]); a success returns a greeting, not a shell.
- Heroku has no SSH login; use heroku run bash -a <app> for a one-off dyno shell instead.

If your agent holds several keys, SSH offers them one by one. The server counts each as an attempt and, once it hits its MaxAuthTries limit (default 6), it closes the connection before SSH ever reaches the correct key, producing this error. Restrict SSH to just the right key:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected]

Or set IdentitiesOnly yes in the host's ~/.ssh/config block (see step 5).

Repeated failed attempts can also get your IP temporarily banned. If you have server access, inspect the auth logs:

# On the remote server
sudo tail -f /var/log/auth.log        # Debian/Ubuntu
sudo tail -f /var/log/secure          # RHEL/CentOS/Fedora

Look for entries like:

sshd: Too many authentication failures for user
sshd: Connection closed by authenticating user user X.X.X.X port XXXX [preauth]

And check for fail2ban / firewall blocks:

sudo fail2ban-client status sshd     # is your IP banned?
sudo iptables -L -n                   # inspect firewall rules

If you're locked out, wait for the ban window to expire or have the administrator unban your IP (e.g. sudo fail2ban-client set sshd unbanip <your-ip>).