SSH Authentication Loop: SSH Server Rejects Your Key Then Re-prompts

1. Wrong Permissions on .ssh Directory or authorized_keys

This is the #1 cause. OpenSSH is strict about file permissions. If your home directory, .ssh folder, or authorized_keys file is too permissive, the server silently rejects your key and falls back to password prompt. Then you type password, it fails, and the prompt comes again. That's the loop.

What's actually happening here is: The SSH server checks if anyone else could have modified your authorized_keys. If permissions allow group or world write, it assumes the file might be tampered with and refuses to use it. It doesn't tell you why – just goes back to asking for password.

# On the SERVER machine, fix permissions:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 755 ~
# Also make sure the files are owned by you
chown -R $USER:$USER ~/.ssh

Why step 3 matters: If your home directory is writable by others (e.g., drwxrwxr-x), SSH will also reject key auth. The server checks every directory in the path up to the authorized_keys file.

After fixing, test with verbose output:

ssh -vvv user@server

Look for lines like debug1: Authentication succeeded (publickey). If you see debug1: Offering public key but no success, permissions were likely wrong.

2. SSH Client Configuration Overriding the Key or Host Settings

You might have a config file in ~/.ssh/config that's silently breaking things. Common problems:

• IdentityFile pointing to a non-existent key or wrong path
• Host block matching your target but forcing a different key
• PreferredAuthentications set to password-only (then you can't use keys at all)

Real-world trigger: You copied a config from someone else's dotfiles, and it has IdentityFile ~/.ssh/company_key but you renamed that file. The client tries the wrong key, server rejects it, client falls back to password but server requires key first – loop again.

Fix: Temporarily rename (or delete) the config file and test:

mv ~/.ssh/config ~/.ssh/config.bak
ssh user@server

If that works, your config was the problem. Here's a clean config that usually works:

Host myserver
    HostName 192.168.1.100
    User myuser
    IdentityFile ~/.ssh/mykey
    PubkeyAuthentication yes
    PasswordAuthentication no

Note the last two lines – PubkeyAuthentication yes tells the client to try keys. PasswordAuthentication no stops the fallback loop so you see the real error.

3. Server-Side: Key Format Mismatch or Disabled Public Key Auth

Less common but happens. Your server might:

• Have PubkeyAuthentication no in /etc/ssh/sshd_config
• Use a newer key type (like ed25519) but the server only accepts RSA keys
• Have AuthenticationMethods set to something weird like password,publickey requiring both

Why it's tricky: The server won't tell you "I don't accept ed25519 keys" – it just says "permission denied" and loops you back. You need to check the server logs.

On the server, look at:

sudo tail -f /var/log/auth.log  # Debian/Ubuntu
sudo tail -f /var/log/secure    # RHEL/CentOS

You'll see lines like:

sshd[12345]: Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys
sshd[12345]: Failed publickey for user from 10.0.0.5 port 22 ssh2: RSA SHA256:xxxx

If you see Failed publickey followed by nothing, and your permissions are right, check the key format. Convert your private key with:

ssh-keygen -p -f ~/.ssh/mykey -m PEM

This forces the old PEM format which some old servers require. Newer servers prefer the default OpenSSH format, but PEM is widely supported.

Also check /etc/ssh/sshd_config for these lines:

PubkeyAuthentication yes
PasswordAuthentication no  # to force key-only
AllowUsers user1 user2     # make sure your user is listed

After changes, restart SSH:

sudo systemctl restart sshd   # or ssh, depends on distro

Quick-Reference Summary

Start with fix #1 – it solves 80% of these loops. If that doesn't work, move to #2, then #3. Most people waste hours on the server config when the real problem is that one wrong permission bit.