SSH Key Auth Fails on Group-Writable Home Directories

Introduction

When SSH rejects a user's key and falls back to a password prompt, one cause is a group-writable or world-writable home directory. With StrictModes enabled (the OpenSSH default), sshd refuses to read authorized_keys from a home directory it considers insecure, so key authentication fails even when the key and the ~/.ssh permissions are correct.

This is one of several possible causes, and a single server-side log line confirms it: Authentication refused: bad ownership or modes for directory. If that line is absent, a different problem is at fault and this fix doesn't apply. See the Notes section for the other causes to check.

This applies to Rocky Linux 8, 9, and 10 running OpenSSH with the default StrictModes yes.

Problem

A subset of users can't log in with their SSH keys. The key is present, ~/.ssh and authorized_keys have correct ownership and permissions, and password authentication still works. Copying a working user's .ssh permissions doesn't help, because the problem isn't in .ssh. It's one level up, on the home directory itself, which is group-writable or world-writable.

This pattern is common on shared systems such as HPC (High Performance Computing) login nodes and Open OnDemand deployments, where home directories are created in bulk and can inherit a group-write bit.

Symptoms

From the user's point of view, they're prompted for a password when connecting even though their key is installed, while other users on the same system log in with their keys normally.

On the wire, the client offers the key, the server rejects it, and SSH falls back to password authentication. A verbose client trace (ssh -vvvv localhost) shows the key being offered and then the method list restarting:

debug1: Next authentication method: publickey
debug1: Offering public key: /home/user01/.ssh/id_rsa RSA SHA256:...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
...
debug1: Next authentication method: password
user01@localhost's password:

The affected user's home directory is group-writable, while a working user's isn't:

# broken user
drwxrwx--- 2 user01 user01 4096 Jun 29 15:10 /home/user01

# working user
drwx------ 2 user02 user02 4096 Jun 29 14:53 /home/user02

The server-side sshd log (journalctl -u sshd or /var/log/secure) confirms the cause:

Authentication refused: bad ownership or modes for directory /home/user01

Resolution

These steps require root or sudo to read the sshd log and adjust another user's home directory.

1. Confirm the cause. The sshd log on the target host shows the rejection for the affected user's home directory. If this line isn't present, key authentication is failing for a different reason and the remaining steps won't help.

   Authentication refused: bad ownership or modes for directory /home/user01
   

2. Confirm StrictModes is enabled (this is the default):

   sshd -T | grep -i strictmodes
   

   strictmodes yes
   

3. Remove group and other write permissions from the affected user's home directory:

   chmod g-w,o-w /home/user01
   

4. Confirm the user can now authenticate with their key, then correct the remaining home directories. This targets only the immediate home directories and skips stray files and symlinks. Adjust the base path where home directories actually live, which may not be /home on HPC systems:

   find /home -mindepth 1 -maxdepth 1 -type d -exec chmod g-w,o-w {} +
   

SSH requires that the home directory, ~/.ssh, and authorized_keys aren't writable by group or other. Target permissions are 0755 or stricter on the home directory (0700 is common), 0700 on ~/.ssh, and 0600 on authorized_keys.

Root cause

StrictModes yes tells sshd to check the ownership and permissions of the home directory and SSH files before trusting authorized_keys. A group-writable or world-writable home directory would let another account in that group add a key and log in as the user, so sshd refuses to use the file. Key authentication then fails and SSH moves to the next allowed method, which presents as a password prompt. Because the loose permission is on the home directory and not inside .ssh, matching a working user's .ssh permissions doesn't resolve it.

Notes

⚠️ WARNING Disabling StrictModes (StrictModes no in /etc/ssh/sshd_config) also stops the rejection, but it's not recommended. It removes the protection against another user in the same group planting a key in a writable home directory and impersonating the account. Fix the directory permissions instead.

Where home directories are created by automated provisioning or an identity service, check the default umask or the directory-creation logic so new home directories don't come out group-writable.

If the sshd log doesn't show the bad ownership or modes for directory message, the cause is elsewhere. Check the permissions on ~/.ssh (0700) and authorized_keys (0600), whether the correct public key is present in authorized_keys, the SELinux context on the home directory (restorecon -Rv /home/user01), and whether PubkeyAuthentication is disabled in sshd_config.

References & related articles

OpenSSH sshd_config manual (StrictModes)
Unable to SSH to Compute Nodes After Image Update
Enabling Local User Login with Active Directory Authentication Using Kerberos
How to Enable 2FA-Enabled SSH Log-ins for Rocky Linux