$ Linux One Liners
Back to problems

problem hub

Read-only, sensitive output

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.

What to check next

Authentication refused: bad ownership or modes

Means: sshd found the account path or key file too open and ignored it.

Next step: Inspect the home, .ssh directory, and authorized_keys modes before changing them.

Find Loose authorized_keys Modes

Failed publickey appears for the expected user

Means: The client reached sshd, but the offered key was not accepted for that account.

Next step: Inventory authorized keys and compare the intended account and key comment or fingerprint.

Inventory SSH authorized_keys

No matching auth log line appears

Means: The client may be reaching the wrong host, wrong port, or no server at all.

Next step: Check the effective sshd policy and connection target before editing keys.

Show SSH Auth Policy Order

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.

  1. grep -E 'Failed publickey|Accepted publickey|Authentication refused' /var/log/auth.log | tail -50
  2. 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.

SSH auth decision tree

Separate client trust problems from server-side public-key rejection. known_hosts warnings mean host identity changed; publickey failures mean sshd did not accept the offered key; bad modes mean sshd ignored the key file.

  1. ssh -vvv user@example.com
  2. grep -E 'Failed publickey|Accepted publickey|Authentication refused|bad ownership or modes' /var/log/auth.log | tail -50
  3. namei -l /home/demo/.ssh/authorized_keys
  4. stat -c '%A %U:%G %n' /home/demo /home/demo/.ssh /home/demo/.ssh/authorized_keys
  5. sudo sshd -T | grep -E 'pubkeyauthentication|authorizedkeysfile|allowusers|denyusers'

Bad fixes to avoid

Do not paste private keys into tickets, chmod an entire home directory, disable StrictModes, or restart sshd before validating config and keeping a working session open.

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.
  • Do not disable StrictModes to make one login work.
  • Do not delete known_hosts entries until you have verified the host identity change.

Stop and escalate if

  • You do not have an alternate working login path before changing SSH configuration or keys.
  • The output includes private keys, tokens, customer usernames, or hostnames that should not be shared.
  • A firewall, PAM, or sshd_config change could lock out remote administration.

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

Command path

Guides and drills