SSH Auth Failure: Top 3 Fixes That Actually Work

1. Wrong permissions on ~/.ssh/authorized_keys (this is the most common)

I see this all the time. Someone copies their public key to a server, runs chmod 777 on everything, and wonders why SSH still says 'Permission denied (publickey).' The SSH daemon is picky about file permissions. Real strict. If your ~/.ssh directory or authorized_keys file is writable by anyone other than you, the daemon flat-out ignores it.

Fix it with these commands on the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Also check the home directory itself—it shouldn't be writable by group or others. Should be 755 or 700. Had a client last month whose home folder was 777 after a messy script ran. Took me 30 seconds to fix after they spent hours reinstalling SSH.

If your key still doesn't work, run sshd in debug mode to see exactly what's being rejected:

sudo /usr/sbin/sshd -d -p 2222

Then from another terminal, ssh to port 2222. The debug output will tell you if it's a permissions issue or something else. Look for lines like 'Authentication refused: bad permissions.'

2. SSH server isn't accepting password authentication (but you expected it to)

You try to log in with a password, and SSH says 'Permission denied.' No key, just a password. Chances are the server's sshd_config has PasswordAuthentication set to no. Many cloud providers do this by default now—Ubuntu 22.04, Debian 12, Amazon Linux 2. They assume you'll use keys.

To check, look at /etc/ssh/sshd_config:

grep PasswordAuthentication /etc/ssh/sshd_config

If it says 'no', you can change it to 'yes' (temporarily) or set up a key. If you do change it, remember to restart sshd:

sudo systemctl restart sshd

But here's the thing—don't leave password auth on for long if you're exposing SSH to the internet. Bots will hammer it. I always say: keys are better, but sometimes you need a password for initial setup or recovery. So use it, get your key in place, then turn it back off.

Another scenario: the server might have AllowUsers or DenyUsers set in sshd_config. Check those too:

grep -E 'AllowUsers|DenyUsers|AllowGroups|DenyGroups' /etc/ssh/sshd_config

If your user isn't in the allowed list, you're locked out. Simple as that.

3. Host key mismatch or known_hosts issue (common with IP changes)

You get a scary message like 'REMOTE HOST IDENTIFICATION HAS CHANGED' or 'WARNING: POSSIBLE DNS SPOOFING DETECTED.' This happens when the server's host key changed—reinstalled the OS, rebuilt the server, or cloned a VM. Your SSH client remembers the old key in ~/.ssh/known_hosts. If the keys don't match, it refuses to connect. That's a good security feature, but it can be a pain.

Fix: remove the offending line from known_hosts. Easiest way:

ssh-keygen -R server_ip_or_hostname

Then try connecting again. It'll prompt you to accept the new key. Do it and move on.

But if you're automating this (like in a script), you can temporarily disable strict checking—though I'd only recommend that for internal, trusted networks. Add this to your SSH config (~/.ssh/config):

Host my-server
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null

That's risky. Only do it if you know what you're doing. For most people, just deleting the old key is enough.

One more thing: if the server's host key is actually corrupt or missing, regenerate it:

sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server   # Debian/Ubuntu
sudo ssh-keygen -A                     # RHEL/Fedora

Then restart sshd. Don't do this unless you're sure—it'll break connections for anyone who has the old key in known_hosts.

Quick-reference summary table