SSH Key Permissions: Fix “Too Open” Errors Without Guesswork

SSH key permission errors indicating a "too open" warning are a security measure rather than an aesthetic one. Unauthorized access to a private key could allow another account to authenticate to servers that recognize it. On Linux and macOS systems, the standard resolution is to set the private key permissions to "chmod 600". However, not all files within the ~/.ssh directory require identical permissions, and occasionally the issue may stem from ownership instead of the file mode. Here are practical default settings for a standard Linux or macOS setup:

File or directory Suggested mode Why

~/.ssh 700 Only accessible to the owner

Private key, like id_ed25519 600 or 400 Prevents other users from reading

Public key, such as id_ed25519.pub 644 Public keys are not secret; this is a standard

authorized_keys 600 Prevents local users from altering the list of trusted keys

known_hosts 644 The contents themselves are not secret; avoid allowing others to edit

~/.ssh/config 600 Prevents other users from modifying your SSH client settings

These guidelines are practical, not an absolute mandate enforced by OpenSSH. The critical factor is whether a file contains sensitive data or if another user could alter something that SSH depends on. To address a key that is too permissive, adjust the permissions to "chmod 600" for the private key file. Replace the filename with the specific key you are using.

For an RSA key, the command would be "chmod 600 ~/.ssh/id_rsa". The "600" mode signifies that the owner can read and write the file, while group and other users have no access. Alternatively, "400"—owner read-only—is also an acceptable setting for a private key that doesn't require modifications.

Typical warnings might appear as follows: "WARNING: UNPROTECTED PRIVATE KEY FILE! Permissions 0644 for 'id_rsa' are too open." To correct this, adjust the directory and other common files to their recommended defaults. Use "chmod 700 ~/.ssh" for the directory, "chmod 644 ~/.ssh/id_ed25519.pub" for public keys, "chmod 600 ~/.ssh/authorized_keys" for the authorized keys file, "chmod 644 ~/.ssh/known_hosts" for the known hosts file, and "chmod 600 ~/.ssh/config" for the SSH configuration file.

It is unnecessary to apply these changes to every file listed; if a file is missing, ignore the corresponding chmod command.

Unfamiliarity with these permission modes can be addressed through educational resources like this explanation of "chmod 600" and SSH file permissions. It's crucial not to treat every file in the .ssh directory as a private key. The .pub file is intended for sharing with servers, and OpenSSH does not enforce a specific mode for it, so "644" is a convention, not a necessity to conceal the file's contents.

The authorized_keys file, which exists on the server side, lists public keys authorized to log into the account. The usual setting of "600" for this file is conservative, as it prevents unauthorized write access by local users who might add their own keys. If the purpose of this file is unclear, consult this guide to the SSH authorized_keys file.

It's important to note that not every permission issue can be resolved by changing mode. File permissions and ownership are distinct checks. Use "ls -la ~/.ssh" to inspect the files, observing both the owner and the permission string. If the key was created using "sudo", restored from a backup, or copied from another machine, it may belong to the root user or another account, which means you might not have permission to modify it.

Correct the ownership explicitly with "sudo chown $USER:$USER ~/.ssh/id_ed25519", and avoid changing ownership on unrelated files. If server-side public-key authentication persists despite file adjustments, the problem could also be related to the username, the key being used, or whether the appropriate public key is installed on the server.

The server also examines the permissions in the home directory specified in the authorized_keys file. Ensure the directory itself has no write permissions for group or other users by using "chmod g-w,o-w ~". On Windows, the situation differs as Windows uses ACLs rather than Unix permission bits to control access to SSH keys. To examine these permissions, use "icacls $HOME\.ssh\id_ed25519" in PowerShell.

The private key should only be readable by you and inaccessible to other users. If the key was moved from a location with broad inherited access, inspect the ACL before adjusting it; chmod is not a solution for Windows ACL issues. The fundamental principle remains the same: defend private keys from unauthorized reading, safeguard SSH configuration and server-side key lists from unauthorized modifications, and verify ownership if permission alterations alone do not resolve the issue.