Dennis HilkLinux Fix LabDE

SSH, Security & Permissions

SSH ignores an authorized public key

A valid public key can be ignored when its file or parent directories are writable by other users. Inspect the server-side path first.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • The same public key works for another account.
  • Server logs mention ownership or modes of authorized_keys.

Relevant environment

OpenSSH server; run path checks as the affected account on the server. Configuration tests need root to inspect host keys.

Recognizable messages (synthetic examples)
sshd[411]: Authentication refused: bad ownership or modes for directory /home/example

Inspect the named file or directory; the line does not prove the key itself is invalid.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • StrictModes may reject an authorized_keys path writable by another account.
  • AuthorizedKeysFile or a Match block may point to a different file.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Run on the server as the account receiving the login; shows each path component without exposing key material.

namei -l "$HOME/.ssh/authorized_keys"

Interpret the result: Check the owner and group/other write bits on the home directory, .ssh and key file; a missing component means this is not the configured path.

Check 2

On the server, replace ACCOUNT, CLIENT_NAME and the documentation IP with the actual login and client; root may be required. Test mode does not start a listener.

/usr/sbin/sshd -T -C user=ACCOUNT,host=CLIENT_NAME,addr=192.0.2.10

Interpret the result: Read authorizedkeysfile, strictmodes and pubkeyauthentication. Match-specific output separates a path problem from disabled key authentication.

Evidence-guided next steps

Correct the confirmed ownership and write bits

If the inspected path is correct, record its current owner, modes and ACLs. Set .ssh to owner-only access and authorized_keys to owner read/write, commonly 0700 and 0600; remove inappropriate group/other write access from the parent. Change only these paths.

Precautions: Preserve deliberate shared-directory ACLs; do not recursively chmod the home directory or disable StrictModes.

Recovery / rollback: Use the recorded metadata to undo only unintended changes. Keep the key path protected; remove the new key if its authorization must be withdrawn.

Did this solution help you?

Share this solution#

Install the public key at the effective location

If sshd -T selects another file, back it up and add the intended public key there through an existing authorized session. Retain its existing keys and options. A centrally managed key source should be changed through its management system.

Precautions: Never copy the private key to the server. Keep the existing session until a separate login has been checked.

Recovery / rollback: Remove only the added public-key line or restore the saved file, keeping other accounts’ keys intact.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.