When sshd ignores the AuthorizedKeysFile directive, it is almost always due to incorrect file permissions, SELinux policies, or a configuration syntax error. The most common cause is that the target key file or its parent directory allows group or other write access, which OpenSSH rejects for security reasons. Verify that the owner has exclusive write permission (600) and that the path in the configuration matches the actual file location exactly.
Understanding Permission Requirements
OpenSSH enforces strict security constraints on files containing public keys. If the server detects that the authorized keys file is writable by anyone other than the user who owns it, it will silently ignore the file to prevent unauthorized key injection. This behavior is intentional and cannot be disabled via simple configuration flags. The critical rule is that theauthorized_keys file must have permissions set to 600 or stricter. A common mistake is setting permissions to 644, which allows the group and others to read the file. While reading is often considered harmless, OpenSSH considers any write permission from non-owners as a security risk. Additionally, the directory containing the file must not be writable by group or others. Typically, this means the home directory itself should be 755 or 700, but never 777.
To correct these permissions, you must log into the server as the root user or use sudo. Identify the specific user account that is attempting to connect via SSH. Then, navigate to their home directory and adjust the permissions of the key file.
chmod 600 /home/username/.ssh/authorized_keys
chmod 700 /home/username/.ssh
chown -R username:username /home/username/.sshsystemctl restart sshd on systemd-based systems.
Verifying Configuration Syntax
Even with perfect permissions,sshd may appear to ignore your custom path if the configuration syntax is flawed. The AuthorizedKeysFile directive accepts multiple paths separated by spaces. It also supports macros like %u for the username and %h for the home directory.
If you are specifying an absolute path, ensure there are no typos. If you are using macros, verify that they resolve correctly for the test user. For example, if you specify AuthorizedKeysFile .ssh/keys/%u.pub, the system will look for /home/username/.ssh/keys/username.pub.
Before restarting the service, always validate your configuration file. Running a syntax check prevents service crashes and provides immediate feedback on errors.
sshd -tChecking SELinux and AppArmor Contexts
On systems with mandatory access controls enabled, such as Red Hat Enterprise Linux or CentOS, SELinux can block SSH from reading custom key locations. Even if permissions are correct, SELinux labels must allow the SSH daemon to access the file. If you have moved the authorized keys file to a non-standard location, such as/etc/ssh/keys/, you must update the SELinux context. You can check the current context using ls -Z. If the type is not ssh_pub_key_t or user_home_t, the daemon may be denied access.
To fix this, relabel the file using the following command:
restorecon -v /path/to/custom/authorized_keyssshd if you suspect a MAC policy issue.
Debugging Connection Attempts
When standard checks pass but connections still fail, enable verbose logging on the client side. Connecting with-vvv reveals exactly where the authentication process stops. Look for messages indicating that the server rejected the key or did not offer it.
On the server side, increase the LogLevel in sshd_config to DEBUG. This generates detailed logs in /var/log/auth.log or /var/log/secure. These logs will explicitly state if the file was skipped due to permissions or if it was not found. Once troubleshooting is complete, revert the log level to INFO to avoid excessive disk usage.
For more insights on connection performance, see How to troubleshoot a long delay when connecting over SSH?.
Frequently Asked Questions
Why does sshd ignore my custom AuthorizedKeysFile path?
The most likely reason is that the file or its parent directory has permissions that are too open. OpenSSH requires the file to be owned by the user and writable only by that user (mode 600). Any group or world write permission causes the file to be ignored.
Can I use 644 permissions for authorized_keys?
No, 644 permissions are strictly rejected by modern versions of OpenSSH. The file must be 600 or 400. Allowing group read access is generally safe, but allowing group write access is a critical security vulnerability that triggers silent failure.
How do I check if SELinux is blocking SSH keys?
You can check the audit logs for denials using the command ausearch -m avc -ts recent. If you see denials for sshd accessing your key file, you need to restore the correct SELinux context using restorecon.
What is the difference between AuthorizedKeysFile and AuthorizedKeysCommand?
AuthorizedKeysFile points to static files on the local filesystem. AuthorizedKeysCommand specifies an external program that dynamically generates keys based on the username. They serve different purposes and can be used together, but AuthorizedKeysFile is the standard method for static key management.
Why are my SSH keys being ignored after a server reboot?
This often happens if the file permissions were reset by a backup restoration script or if the ownership changed. Ensure that the user owns the .ssh directory and the authorized_keys file, and that permissions remain at 600 and 700 respectively.