🚨 SSHD Error: 'Authentication refused: bad ownership or modes for file' — Cause, Fix, and Troubleshooting Guide

What this error means

Public-key login failed because sshd, with StrictModes enabled, refuses to trust an authorized_keys file (or the directories leading to it) when the permissions or ownership are too loose. If another user could write to your home, .ssh, or authorized_keys, they could inject a key — so sshd ignores the file entirely.

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

This is logged server-side in /var/log/auth.log (or /var/log/secure); the client just sees Permission denied (publickey). The fix is to tighten ownership and modes, not to weaken sshd.

How it manifests on the host

• Key-based login fails with Permission denied (publickey) even though the key is correct.
• Server logs show Authentication refused: bad ownership or modes for file ... or ... for directory ....
• It broke after restoring a home directory from backup, changing usernames/UIDs, or a careless chmod -R.
• One user is affected while others log in fine.

System configuration causes

• World/group-writable home or .ssh. StrictModes rejects the whole chain if any parent is group/other-writable.
• Wrong ownership. authorized_keys or .ssh is owned by root or a different UID after a restore or useradd mismatch.
• Loose authorized_keys mode. The file is 0644+group-write or worse.
• Home restored with broad ACLs or a default umask that left group-write on.
• Shared home via NFS with squashed/incorrect ownership.

Interrogating the host

# Read the exact server-side reason
sudo grep -E 'Authentication refused|bad ownership' /var/log/auth.log | tail   # or /var/log/secure

# Inspect the full ownership/mode chain for the user
ls -ld /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keys

# Is StrictModes on? (default yes)
sudo sshd -T | grep -i strictmodes

# Any ACLs widening access beyond the mode bits?
getfacl /home/deploy/.ssh 2>/dev/null

sshd requires: home not group/other-writable, .ssh = 700, authorized_keys = 600, all owned by the user.

Remediation

1. Correct ownership and modes for the whole chain:

sudo chown deploy:deploy /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keys
sudo chmod 755 /home/deploy          # or 750; must NOT be group/other-writable
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

2. Strip over-broad ACLs if getfacl showed extra write grants:

sudo setfacl -b /home/deploy/.ssh /home/deploy/.ssh/authorized_keys

3. Verify from the server log on the next attempt:

sudo tail -f /var/log/auth.log     # attempt the login again; the refusal should be gone

4. Keep StrictModes on. Do not disable it as a workaround — it is a genuine security control. Fix the permissions instead.

Hardening the host

• Never set StrictModes no to “fix” this — it lets any writable-home vector plant an authorized key.
• A group-writable home directory is enough to trigger this even when .ssh itself looks correct; check the whole path.
• Watch UID mismatches after migrations/restores — files can carry a numeric owner that no longer maps to the user.
• On NFS-mounted homes, confirm the export does not squash ownership in a way that trips StrictModes.

Related system errors

• SSH ‘Permission denied (publickey)’ Error Guide
• SSH ‘UNPROTECTED PRIVATE KEY FILE’ Permissions Error Guide
• Hardening SSH Access to Production Servers with AI