SSH Permission denied publickey

Inspect auth logs, authorized_keys, file modes, and effective sshd policy before changing access.

Safest first command

grep -E 'Failed publickey|Accepted publickey|Authentication refused' /var/log/auth.log | tail -50

Before you run this

Expected output: Recent SSH authentication lines showing accepted keys, failed public-key attempts, or permission-related rejections.

When not to use it: Do not paste private keys or full auth logs into tickets or chat. Redact users, IPs, and key material first.

Expected output example

sshd[1234]: Failed publickey for demo from 192.0.2.25 port 51234 ssh2
sshd[1234]: Authentication refused: bad ownership or modes for directory /home/demo

How to read the result

If the server log mentions refused authentication or bad modes, inspect ownership and permissions before changing keys. If no attempt appears, check port, firewall, DNS, or whether the client reached the server.

Check the server-side reason

The client error is often generic. The server log can show whether sshd rejected the offered key, ignored authorized_keys, blocked a user, or never received the attempt.

grep -E 'Failed publickey|Accepted publickey|Authentication refused' /var/log/auth.log | tail -50
sudo sshd -T | grep -E 'authorizedkeysfile|pubkeyauthentication|allowusers|denyusers'

Inspect modes before chmod

Loose modes on home, .ssh, or authorized_keys can cause sshd to ignore a key file. Inspect the path chain first.

Common causes

Wrong public key offered by the client
authorized_keys in the wrong account
Loose home, .ssh, or authorized_keys permissions
sshd policy disabling public-key auth or restricting users
Client is hitting the wrong host or port

What not to change yet

Do not paste private keys into tickets or chat.
Do not chmod -R an entire home directory.
Do not restart sshd before validating config and keeping an active session open.

platform notes

Distro and service notes

Debian/Ubuntu

Authentication logs usually live in /var/log/auth.log.

RHEL/Fedora

Authentication logs often appear in /var/log/secure or journald.

Security

Auth logs can contain usernames, IPs, and key fingerprints; redact before sharing.

supporting commands