SSH still asking for a password? The 6 causes and fixes

Why SSH still asks for a password

You set up a key, but SSH keeps prompting for a password — which means the server isn't accepting your key and is falling back to password auth. Having id_rsa and id_rsa.pub sitting in ~/.ssh on your laptop proves nothing on its own: a key only works once its public half is a line inside ~/.ssh/authorized_keys on the server, under the exact account you log in as, on files whose permissions sshd is willing to trust. The cause is almost always one of six things: the public key isn't in authorized_keys, the file or directory permissions are too open, you're logging in as the wrong user, the client isn't offering the key, sshd has key auth disabled, or SELinux mislabeled the files. Here's how to find which, fastest first.

The 30-second version. Take away the password fallback so the failure stops hiding behind a prompt:

ssh -v -o PreferredAuthentications=publickey -o IdentitiesOnly=yes -i ~/.ssh/id_rsa you@host

Now you get an error instead of a prompt, and the debug1: lines tell you which half is broken: if you see Offering public key: … id_rsa followed by Permission denied (publickey), your key reached the server and the server rejected it (causes 1, 2, 3, 6). If the key is never offered, the problem is on your client (cause 4). If the connection dies with no mutual signature algorithm, jump to the RSA section.

First: is it asking for a password or a passphrase?

These two prompts look alike at 2am and mean opposite things. Read yours carefully before changing anything.

If it's the passphrase prompt and you just don't want to type it every time, load the key into the agent instead of re-fixing the server:

eval "$(ssh-agent -s)"          # start an agent if you have none
ssh-add ~/.ssh/id_ed25519       # Linux / WSL
ssh-add --apple-use-keychain ~/.ssh/id_ed25519   # macOS: store it in the Keychain
ssh-add -l                      # what's loaded right now

Everything below is about the first prompt — the one that means the server said no.

The six causes

"I just set up an SSH key but it still demands a password"

The brand-new-key case has its own short path, because a key that has never worked once fails differently from one that stopped working. Do these five in order — most people are fixed by step 3.

1. Prove the key exists on the server, for the right user. Log in with the password (that still works) and look:

   whoami                       # the account the key must be installed for
   cat ~/.ssh/authorized_keys   # your public key should be here, one key per line

   Empty file, missing file, or no such directory means the key was never installed — ssh-copy-id you@host from the client and try again. Note that sudo during setup is a classic trap: keys pasted while root land in /root/.ssh/authorized_keys, which does nothing for ubuntu@host.
2. Prove it's the same key your client offers. Fingerprints don't lie. On the client and then on the server:

   ssh-keygen -lf ~/.ssh/id_rsa.pub        # client: 3072 SHA256:AbC… you@laptop (RSA)
   ssh-keygen -lf ~/.ssh/authorized_keys   # server: one line per installed key

   If your client fingerprint isn't in the server's list, you installed a different key (or an old one). If ssh-keygen -lf errors on authorized_keys, the file is corrupt — see the paste problems below.
3. Fix permissions. Ninety percent of "the key is right there and it still asks" ends here. See the #1 fix.
4. Check the server log while you connect. One line usually names the cause outright — how to read it.
5. Check the client is actually offering it. ssh -v you@host, look for Offering public key. Nothing offered means -i, an agent, or a ~/.ssh/config entry is needed.

Let the server tell you

The fastest diagnosis is the server's auth log while you connect. From a session that does work (or the console):

sudo tail -f /var/log/auth.log    # Debian/Ubuntu
sudo journalctl -u ssh -f         # systemd

It says exactly why — Authentication refused: bad ownership or modes for file … (that's cause #2), or user not allowed, etc. On the client side, ssh -v user@host shows whether your key is even being offered (cause #4). A quick decoder for the lines you'll actually see:

No shell access at all to read the log? Ask sshd itself, on a spare port, with full debug output — it prints the reason straight to your terminal without disturbing the running service:

sudo /usr/sbin/sshd -d -p 2222      # console/rescue session on the server
ssh -p 2222 you@host                # from the client, in another window

The #1 fix: permissions

OpenSSH silently ignores authorized_keys if it's too readable. On the server, for the login user:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

Also make sure your home directory isn't group- or world-writable (chmod g-w,o-w ~). This single cause accounts for most "key installed but still asks for password" cases. The mirror image on the client — your private key being too open — is UNPROTECTED PRIVATE KEY FILE.

Why SSH asks for a password even with id_rsa.pub

This is the most common way the whole thing feels illogical: ~/.ssh/id_rsa.pub is right there, you can cat it, and SSH still wants a password. The file on your machine is not the thing that authenticates you. Only a copy of its contents inside authorized_keys on the server does. Five specific ways an existing id_rsa.pub still fails:

• It was never transferred. Generating a key does not install it. ssh-keygen creates the pair; ssh-copy-id (or a paste into authorized_keys, or your cloud console's key field) installs it.
• The paste got mangled. A public key is one single line: ssh-rsa AAAAB3Nza… you@laptop. Copying it out of a text editor, an email, or a browser wraps it across several lines, or drops the ssh-rsa prefix, or adds Windows CRLF endings. Any of those and sshd skips the line without comment. Check the server side:

  wc -l ~/.ssh/authorized_keys   # should equal the number of keys, not more
  cat -A ~/.ssh/authorized_keys  # trailing ^M means CRLF — strip with dos2unix

  The other half of this: appending with cat id_rsa.pub >> authorized_keys when the existing file has no trailing newline glues two keys into one broken line, killing the key that used to work as well.
• You copied the wrong file. id_rsa (no extension) is the private key and must never leave the client; putting it in authorized_keys does nothing. Equally, moving only id_rsa.pub to a new laptop gives you a public key with no private key behind it — nothing to sign with, so nothing is offered.
• It's installed for a different account. authorized_keys is per user. Under /home/ubuntu it authenticates ubuntu@host and nobody else.
• The key is fine, the signature algorithm isn't — the modern RSA-only trap, below.

The RSA-specific gotcha: "no mutual signature algorithm"

This one hits id_rsa and never hits id_ed25519, which is why the same setup works for a colleague and not for you. OpenSSH 8.8 (2021) disabled the old ssh-rsa signature scheme by default because it uses SHA-1. RSA keys themselves are not deprecated — OpenSSH has signed with RSA/SHA-256/512 (rsa-sha2-256, rsa-sha2-512) since 7.2. The failure only appears when one side can't do the newer scheme, typically a modern client against an ancient server (OpenSSH < 7.2 — CentOS 6/7-era boxes, appliances, some network gear, older Bitbucket/AIX installs). Your key is offered, no signature type is agreed, the attempt is abandoned silently, and you get a password prompt. In ssh -v it looks like:

debug1: send_pubkey_test: no mutual signature algorithm

Two fixes. Preferred: replace the key with one both sides accept — ssh-keygen -t ed25519, then ssh-copy-id it. If the old server can't do Ed25519 either, re-enable SHA-1 signing for that host only, in ~/.ssh/config:

Host legacy-box
  HostName 10.0.0.9
  PubkeyAcceptedAlgorithms +ssh-rsa
  HostKeyAlgorithms +ssh-rsa

(PubkeyAcceptedAlgorithms is the current name; on OpenSSH older than 8.5 use PubkeyAcceptedKeyTypes. On RHEL/CentOS the equivalent is system-wide: RHEL 9's default crypto policy rejects SHA-1 signatures outright, and sudo update-crypto-policies --set DEFAULT:SHA1 re-permits them. RHEL 9 also enforces a 2048-bit minimum RSA size, so a 1024-bit id_rsa from years ago is refused no matter how correctly it's installed.)

The other fixes

• Key not installed / wrong user — re-copy it to the right account with ssh-copy-id. Installing it for root doesn't help you log in as ubuntu.
• Client not offering it — point at the right key: ssh -i ~/.ssh/mykey user@host, or see use a specific key.
• sshd disabled it — set PubkeyAuthentication yes in /etc/ssh/sshd_config, then sudo systemctl restart ssh.

When it's none of the six: the edge cases

Permissions, wrong user and a missing key cover most of it. If you've ruled all six out and the prompt is still there, it's one of these — the causes most pages skip.

• Too many keys offered. An agent with a dozen keys offers them one at a time; the server's MaxAuthTries (default 6) cuts you off before it reaches the right one, and you get a password prompt. The log says Too many authentication failures. Fix: ssh -o IdentitiesOnly=yes -i ~/.ssh/thekey you@host, and set IdentitiesOnly yes per host in ~/.ssh/config.
• You edited the wrong config file. Ubuntu 22.04+ and most cloud images start /etc/ssh/sshd_config with Include /etc/ssh/sshd_config.d/*.conf, and in sshd config the first value found for a keyword wins. A drop-in like 50-cloud-init.conf therefore beats your edit further down the main file. Check the effective config rather than the file you edited:

  sudo sshd -T | grep -iE 'pubkeyauth|authorizedkeysfile|passwordauth'
  sudo sshd -T -C user=you,host=example.com,addr=203.0.113.5 | grep -i pubkey   # resolves Match blocks too

• Match blocks and Allow/Deny lists. PubkeyAuthentication no or DenyUsers/AllowGroups inside a Match User/Match Address block can disable keys for you specifically while everyone else is fine. The sshd -T -C form above is the only reliable way to see it.
• AuthorizedKeysFile points somewhere else. Default is .ssh/authorized_keys .ssh/authorized_keys2; hardened images and directory-integrated servers often relocate it (or replace it with AuthorizedKeysCommand pulling keys from LDAP/SSSD/IAM). Then your correctly-installed file is simply never read.
• Encrypted home directory. With eCryptfs or fscrypt, /home/you is unreadable until after you authenticate — so sshd can't read ~/.ssh/authorized_keys on the very connection that needs it, and key auth can never succeed. The fix is to store the file outside the encrypted home and point sshd at it, e.g. AuthorizedKeysFile /etc/ssh/authorized_keys/%u (root-owned directory, file owned by the user, mode 600).
• NFS-mounted home with root_squash. sshd reads authorized_keys before dropping privileges; a squashed root can be denied the read. Same symptom, nothing wrong with your key.
• Windows server, administrator account. If the target account is in the local Administrators group, Windows OpenSSH ignores C:\Users\you\.ssh\authorized_keys and reads C:\ProgramData\ssh\administrators_authorized_keys instead (that's a Match Group administrators rule at the bottom of the shipped sshd_config). That file must be UTF-8 without a BOM and grant access to only SYSTEM and Administrators — anything looser is silently ignored:

  icacls.exe C:\ProgramData\ssh\administrators_authorized_keys /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"
  Restart-Service sshd

• SELinux context, in detail. Copying authorized_keys in from /tmp or an unpacked archive leaves it labelled wrong. ls -Z ~/.ssh should show ssh_home_t; if it doesn't, restorecon -R -v ~/.ssh. The log line is Authentication refused with an AVC denial in /var/log/audit/audit.log.
• Account locked or expired. sudo passwd -S you showing L, or an expired password, makes PAM refuse the session even with a perfect key: User you not allowed because account is locked.
• Disk full on the server. A full /home breaks writes you assumed succeeded — the "saved" key file may be empty. df -h and re-check with cat.

On a phone

The painful part of this on mobile is reading the verbose log and matching it to a cause. If you have any working session to the box, select the auth.log line and ask the assistant — TermAI's AI reads it and tells you it's a permissions problem vs a missing key vs a config issue, with the exact command. And because TermAI stores its key in the device Keychain and deploys it for you, the client-side causes (wrong key offered, bad key file permissions) don't happen in the first place.

FAQ

I just set up an SSH key but it still asks for a password — what's wrong?
The server isn't accepting your new key, so it falls back to password auth. In order of likelihood: the public key isn't in that user's ~/.ssh/authorized_keys, the ~/.ssh permissions are too open (700 for the directory, 600 for the file), you're logging in as the wrong user, or the client isn't offering the key. Run ssh -v to see which — and fix the permissions first, it's the most common cause.

Why does SSH ask for a password even though I have id_rsa.pub?
Because id_rsa.pub on your own machine authenticates nothing. It has to be copied — as one unbroken line — into ~/.ssh/authorized_keys on the server, under the account you log in as. Confirm it really is by comparing fingerprints: ssh-keygen -lf ~/.ssh/id_rsa.pub on the client, ssh-keygen -lf ~/.ssh/authorized_keys on the server. If the fingerprint appears on both and it still prompts, it's permissions (~/.ssh 700, authorized_keys 600, home not group-writable) or — for RSA keys specifically — the ssh-rsa signature problem.

Does having id_rsa and id_rsa.pub in ~/.ssh mean my key is "set up"?
No. ssh-keygen only creates the pair; nothing has been sent anywhere. Installation is a separate step: ssh-copy-id you@host, or pasting the public key into the server's authorized_keys / your provider's key field. Until that happens SSH has no choice but to ask for a password.

I copied id_rsa.pub into authorized_keys and it still asks for a password.
Check the file wasn't mangled in transit. It must be exactly one line per key, starting with ssh-rsa/ssh-ed25519, with Unix line endings. wc -l ~/.ssh/authorized_keys should equal your key count, and cat -A should show no ^M. A missing trailing newline on the old file also glues two keys together when you append, breaking both.

Why does my RSA key work on one server but get a password prompt on another?
The failing server is probably too old to do RSA/SHA-2 signatures, and OpenSSH 8.8+ clients refuse the SHA-1 ssh-rsa scheme by default. ssh -v shows send_pubkey_test: no mutual signature algorithm. Either switch to an Ed25519 key or add PubkeyAcceptedAlgorithms +ssh-rsa for that host — details here.

It asks for a passphrase, not a password — same problem?
No, the opposite: Enter passphrase for key '…/id_rsa' means key authentication is working and your local key file is encrypted. Load it into an agent once (ssh-add ~/.ssh/id_rsa, or ssh-add --apple-use-keychain on macOS) and it stops asking.

ssh -v says "Offering public key" but I still get a prompt — now what?
Your client did its job; the server rejected the key. Move to the server log (sudo journalctl -u ssh -f) — it names the reason, usually Authentication refused: bad ownership or modes.

Do I need to run ssh-add?
If your private key lives somewhere non-standard, or your key has a passphrase and isn't being offered, yes — load it into the agent with ssh-add ~/.ssh/id_ed25519 (check what's loaded with ssh-add -l). If you use the default key path and no agent, the client offers the key directly and you don't need it. On a phone client like TermAI this is handled for you — the key is stored on-device and offered automatically.

Why does SSH still ask for a password after I added my key?
The server isn't accepting the key, so it falls back to password. Most often the permissions on ~/.ssh (700) or authorized_keys (600) are too open, the key is under the wrong user, or it was never added. Check /var/log/auth.log.

How do I confirm my key is being offered?
Run ssh -v user@host — look for "Offering public key". If it isn't, point the client at the key with -i.

It says "bad ownership or modes" — what now?
That's the permissions cause: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, and make sure your home directory isn't group-writable.

Could the server have key auth disabled?
Yes — check PubkeyAuthentication yes in /etc/ssh/sshd_config and restart sshd. Verify with sudo sshd -T | grep -i pubkeyauth rather than by reading the file: a drop-in under /etc/ssh/sshd_config.d/ may be overriding it.

My key works on Linux but Windows Server still prompts.
If the account is a local administrator, Windows OpenSSH reads C:\ProgramData\ssh\administrators_authorized_keys, not the one in your profile — and ignores it unless it's UTF-8 (no BOM) with ACLs limited to SYSTEM and Administrators.

Quick Facts

• Meaning: the server rejected your key and fell back to password
• #1 cause: permissions — ~/.ssh 700, authorized_keys 600, home not group-writable
• Diagnose: /var/log/auth.log server-side, ssh -v client-side
• Also: wrong user, key not offered, PubkeyAuthentication no, SELinux context
• id_rsa.pub on your laptop ≠ installed: it must be one unbroken line in the server's authorized_keys
• Prove it's the same key: ssh-keygen -lf the .pub on the client and authorized_keys on the server, compare fingerprints
• RSA-only trap: no mutual signature algorithm = old server + SHA-1 ssh-rsa disabled since OpenSSH 8.8
• Passphrase prompt ≠ password prompt: the first means key auth is working