Fixing sshd Authentication Refused: Bad Ownership or Modes for Directory /data

Resolve the sshd: Authentication refused: bad ownership or modes for directory /data error by correcting the file permissions and ownership of the user's home directory. SSH requires strict security constraints on home directories and key files to prevent unauthorized access, so using chmod and chown restores the necessary configuration.

Understanding the Security Constraint

OpenSSH enforces rigorous security policies regarding file ownership and permissions to protect against privilege escalation and unauthorized data access. When a user attempts to log in via SSH, the daemon checks the integrity of the home directory and associated configuration files. If the home directory is writable by group members or others, or if it has incorrect ownership, the server refuses authentication to mitigate potential security risks. This behavior is documented in the How to troubleshoot a long delay when connecting over SSH? guide, which highlights how strict permission checks can impact connection stability. The error specifically points to the directory specified as the user's home, often /data in custom configurations, indicating that the current mode violates these baseline security requirements.

Why Strict Permissions Matter

The primary reason for this refusal is that OpenSSH considers world-writable or group-writable home directories insecure. An attacker could potentially modify the .ssh directory or authorized_keys file if they have write access to the parent directory. By enforcing strict ownership and mode settings, SSH ensures that only the intended user can manage their cryptographic keys and environment variables. This protection is critical for maintaining the confidentiality and integrity of remote access sessions.

Step-by-Step Resolution

To fix the authentication refusal, you must adjust the ownership and permissions of the affected directory. Follow these steps carefully to restore secure access without compromising system safety.

1. Identify the Affected User: Determine which user account is experiencing the login failure. You can check the logs or ask the user for their username. Let us assume the username is username for the following commands.
2. Correct Ownership: Use the chown command to ensure the home directory belongs exclusively to the user and their primary group. Run the following command:

   sudo chown -R username:username /data

   This recursively changes the owner of all files within the directory to the specific user.
3. Fix Directory Permissions: The home directory itself should not be writable by group or others. Set the permissions to 750 or 700. Execute:

   sudo chmod 750 /data

   This allows the owner full access, the group read and execute access, and denies access to everyone else.
4. Secure the .ssh Directory: Ensure the .ssh directory inside the home folder also has correct permissions. It should typically be owned by the user and have 700 permissions:

   sudo chmod 700 /home/username/.ssh

   If your setup uses /data as the root, apply similar logic to any nested .ssh folders.
5. Verify Authorized Keys: Check the authorized_keys file permissions. It should be 600 (read/write for owner only). Incorrect permissions here can also cause authentication failures.

   sudo chmod 600 /data/.ssh/authorized_keys

   For more details on key file directives, refer to Troubleshooting sshd_config Ignoring AuthorizedKeysFile Directive.

Verifying the Fix

After applying the changes, test the connection to ensure the issue is resolved. Attempt to log in from a client machine using the same user account. If the login succeeds, the permissions were indeed the cause of the refusal. Monitor the /var/log/auth.log or /var/log/secure file for any new errors during the connection attempt. If the problem persists, check for SELinux contexts that might be interfering with the new permissions.

Checking SELinux Contexts

On systems running SELinux, such as RHEL, CentOS, or Fedora, standard Unix permissions are not enough. You may need to restore the default security context for the home directory. Use the restorecon command to reset the labels:

sudo restorecon -Rv /data

This ensures that SELinux policies align with the file structure and ownership changes you made. Failure to address SELinux contexts can result in continued access denials even after fixing Unix permissions.

Preventing Future Issues

To avoid recurrence, ensure that any new users created have their home directories initialized with correct permissions. When using tools like useradd, verify the -m flag creates the directory with appropriate defaults. Additionally, regular audits of home directory permissions can help identify misconfigurations early. Avoid manually setting overly permissive modes like 777 on sensitive directories. Understanding the underlying security model helps maintain a robust SSH infrastructure. For related connectivity issues, see Understanding SSH Config Matching Rules to ensure your client configurations do not inadvertently trigger security warnings.

Frequently Asked Questions

What happens if I leave the home directory group-writable?

OpenSSH will refuse authentication because it considers group-writable home directories insecure. This policy prevents other users in the same group from modifying your private keys or environment. You must set the directory to mode 750 or 700 to allow login.

Can I disable this security check in sshd_config?

No, there is no configuration option to disable this specific check. It is hardcoded into the SSH daemon for security reasons. Attempting to bypass it would expose your system to significant risks, such as key manipulation by local attackers.

Why does the error persist after changing permissions?

If the error continues, check the SELinux context of the directory. On SELinux-enabled systems, incorrect labels can block access even with proper Unix permissions. Use restorecon to reset the context to its default state for the home directory.

Does this error affect SFTP connections as well?

Yes, SFTP runs over the SSH protocol and inherits the same security checks. If SSH authentication is refused due to bad permissions, SFTP sessions will also fail. Correcting the ownership and modes resolves both SSH and SFTP access issues.

How do I find out which directory is causing the issue?

Check the SSH server logs, typically located at /var/log/auth.log or /var/log/secure. The log entry will explicitly state the path of the directory with bad ownership or modes. This allows you to target the specific directory needing correction.