linux troubleshooting guide

SSH Public Key Denied: What to Check First

Separate key rejection, account policy, file mode, and sshd configuration problems before changing access rules.

Problem

SSH login fails with public-key errors, but the cause might be the wrong key, loose file modes, a disabled account, AllowUsers policy, password-auth settings, or a service-side rejection. Guessing with chmod or copying keys blindly can make access weaker or break the wrong account.

First rule

Inspect the server-side evidence first. Do not overwrite authorized_keys or loosen permissions until you know whether sshd rejected the key, ignored the file, blocked the user, or never saw the attempt.

Audience

VPS owners, Linux administrators, developers locked out of SSH, and certification students practicing access triage

Cert context

Useful for LPIC-1, LFCS, and Linux+ style practice around users, groups, SSH, file permissions, logs, and defensive access review. This is independent study support, not provider-approved training.

quick start

Safe first commands

grep -E 'Failed publickey|Accepted publickey|Authentication refused' /var/log/auth.log | tail -50
sudo sshd -T | grep -E 'authorizedkeysfile|pubkeyauthentication|passwordauthentication|allowusers|denyusers'
find ~/.ssh -maxdepth 1 -type f -printf '%m %p\n'
namei -l ~/.ssh/authorized_keys

Start with the auth log

The SSH client usually reports a generic failure. The server log is where you see whether sshd rejected a key, refused a mode, blocked a user, or accepted a different login method.

grep -E 'Failed publickey|Accepted publickey|Authentication refused' /var/log/auth.log | tail -50
journalctl -u ssh --since '30 minutes ago' --no-pager

Check account and key inventory

A public key can be present under the wrong account, duplicated across accounts, or attached to a user that should not have shell access. Inventory before editing.

find /home -path '*/.ssh/authorized_keys' -print 2>/dev/null
awk -F: '$7 ~ /sh$/ {print $1, $7}' /etc/passwd

Inspect modes before changing them

Loose permissions on home directories, .ssh, or authorized_keys can make sshd ignore the key file. Inspect the full path chain first so the fix is narrow.

namei -l ~/.ssh/authorized_keys
stat -c '%A %U:%G %n' ~/.ssh ~/.ssh/authorized_keys

Read effective sshd policy

The active sshd configuration may differ from the file you opened because includes, Match blocks, or defaults changed the effective value.

sudo sshd -T | grep -E 'authorizedkeysfile|pubkeyauthentication|passwordauthentication|allowusers|denyusers'
grep -nE '^(AllowUsers|DenyUsers|PubkeyAuthentication|AuthorizedKeysFile|PasswordAuthentication)' /etc/ssh/sshd_config

triage logic

How to read the result

logs show Authentication refused: bad ownership or modes

sshd may be ignoring the key file because a directory or file in the path is writable by the wrong user or group.

Next: Use namei and stat to find the exact path segment, then fix only that target.

logs show Failed publickey for the expected user

The server saw an attempt for that account but did not accept the offered key.

Next: Confirm the public key is present in the correct authorized_keys file and that sshd is using the expected AuthorizedKeysFile setting.

no server-side log appears

The client may be reaching the wrong host, wrong port, firewall, or a different SSH service.

Next: Check DNS, port, listener, and firewall before editing keys.

safety notes

Slow down here

Do not paste private keys into web tools, logs, tickets, or command output.
Do not chmod recursively across home directories to fix one SSH login.
Keep an existing working session open before changing sshd policy or restarting SSH.

related commands