SSH authentication fails because the server rejects keys stored in
authorized_keys if the file or its parent directories have insecure permissions. To fix this, ensure the
.ssh directory is set to mode 700 and the
authorized_keys file is set to mode 600. Additionally, verify that the SSH daemon configuration allows public key authentication and that the correct user context is active on both client and server sides.
Understanding Permission Security Models
The Secure Shell protocol enforces strict ownership and permission rules to prevent unauthorized access. If an attacker can modify your
authorized_keys file, they could append their own public key, bypassing password protection entirely. Consequently, OpenSSH and other secure implementations will silently ignore any key files that are writable by users other than the owner. This security feature often causes confusion because the error message does not explicitly state "permissions are wrong"; instead, it may simply report that authentication failed or fall back to password prompts.
When troubleshooting on systems like Kali Linux or NFS-mounted environments, you must check the permissions of three specific components: the home directory, the
.ssh folder, and the
authorized_keys file itself. The home directory should generally be accessible by the owner but not group-writable. The
.ssh directory must be exclusively accessible by the user, typically using octal permission 700. Finally, the key file must be readable only by the owner, requiring a setting of 600. Any deviation from these standards, such as a 644 permission set, will cause the SSH service to reject the key for safety reasons.
Correcting File Permissions on Linux
To resolve permission-related rejections, you need to adjust the access rights using the
chmod command. Start by navigating to the user's home directory where the
.ssh folder resides. Execute the following commands to enforce the correct hierarchy of access controls.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
After adjusting the permissions, verify the changes by listing the directory contents with the
ls -la command. You should see output indicating that only the owner has read, write, and execute privileges for the directory, and only read and write privileges for the key file. If the output shows any 'w' (write) bits for group or others, the SSH daemon will continue to reject the connection. It is also critical to ensure that the ownership of these files matches the current user account. Use the
chown command if necessary to assign the correct user and group ownership.
sudo chown -R $USER:$USER ~/.ssh
This process ensures that the operating system recognizes the integrity of the authentication mechanism. On NFS mounts, additional care is required because network file systems may default to different permission schemes or map users differently across hosts. Always confirm that the UID (User ID) and GID (Group ID) match between the client and server when dealing with shared storage volumes.
Verifying SSH Daemon Configuration
Even with perfect permissions, the SSH server might refuse to use public keys if the daemon is misconfigured. Check the main configuration file, usually located at
/etc/ssh/sshd_config, to ensure that public key authentication is enabled. Look for the line
PubkeyAuthentication yes. If this line is commented out or set to no, the server will ignore your key regardless of local file settings.
You should also verify that the
AuthorizedKeysFile directive points to the correct location. The default path is typically
.ssh/authorized_keys, but some distributions customize this. If the path is altered, ensure your key is placed in the new specified directory. After making any changes to the configuration file, restart the SSH service to apply the updates. On Debian-based systems like Kali Linux, use the command
sudo systemctl restart sshd.
For further reading on related connectivity issues, you might find
Troubleshooting kex_exchange_identification Error in Linux SSH Connection helpful if you encounter handshake failures alongside permission errors. Another common issue involves remote execution scripts, which can be addressed by reviewing
Pass pw for remote user in bash line when ssh from linux to windows for context on automation challenges.
Debugging Connection Failures
If permissions and configuration are correct but the issue persists, enable verbose logging on the client side. Run the SSH command with the
-v flag to see detailed output. Using
-vvv provides even more granular information about each stage of the negotiation process. Look for lines indicating "Offering public key" followed by "Server accepts key". If the server rejects the key here, review the server logs in
/var/log/auth.log or
/var/log/secure for specific rejection reasons.
Common log entries include "bad permissions" or "invalid key". These messages confirm that the server detected a security violation during the authentication attempt. Ensure that the public key being offered matches the one stored in the
authorized_keys file exactly. Corrupted lines or extra whitespace in the key file can also cause mismatches. Regenerate the key pair if corruption is suspected, ensuring you copy the public key precisely without adding newlines or spaces.
Handling NFS and Network Storage Specifics
NFS environments introduce unique challenges regarding identity mapping. If the server and client do not share the same UID for the username, the SSH daemon may perceive the file as owned by a different user, leading to permission errors. Use the
id command on both machines to compare UIDs. If they differ, you may need to adjust the NFS mount options or create a matching user account on the server side.
Additionally, check the NFS export options on the server side. Options like
no_root_squash or specific permission masks can override standard Unix permissions. Ensure that the NFS share is mounted with appropriate flags that respect the underlying file system security model. Testing the connection locally on the server can help isolate whether the issue is network-wide or specific to the NFS implementation.
Frequently Asked Questions
Why does SSH ignore my key even though permissions are correct?
Check if the SSH daemon is configured to disable public key authentication in
sshd_config. Also, verify that the key format is valid and not corrupted by extra characters. Ensure that the user account has a valid shell defined in
/etc/passwd.
Can I use 644 permissions for authorized_keys?
No, 644 permissions allow group and world-readable access, which SSH considers insecure. The file must be restricted to owner-only access using 600 permissions. Using broader permissions will cause the server to silently reject the key for security reasons.
How do I check if my SSH key is properly formatted?
Use the
ssh-keygen -l -f ~/.ssh/id_rsa.pub command to inspect the key fingerprint. If the command returns an error, the key file may be corrupted or in an unsupported format. Re-generate the key pair if the file appears invalid or unreadable.
What should I do if NFS mounts reset my permissions?
Configure your NFS mount options to preserve ownership and permissions correctly. Use the
nosuid and
nodev flags to enhance security while maintaining proper access controls. Regularly audit the permissions after mounting to ensure they remain consistent with SSH requirements.
Does SELinux affect SSH key authentication?
Yes, SELinux contexts can block SSH from reading key files if the labels are incorrect. Use the
restorecon command to reset the security contexts of the
.ssh directory and its contents. Verify the context using
ls -Z to ensure it matches the expected SSH type.