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

SSH refusing to use a private key with a “too open” warning is a security check, not a cosmetic complaint. If another local account can read your private key, it could use that key to authenticate to any server that trusts it.

On Linux and macOS, the usual fix is chmod 600 for the private key. But not every file in ~/.ssh needs the same permissions, and sometimes the problem is ownership rather than the mode.

The useful defaults

For a typical Linux or macOS setup, these are safe starting points:

File or directory	Suggested mode	Why
~/.ssh	700	Keeps the directory accessible only to its owner
Private key, such as id_ed25519	600 or 400	Prevents group and other users from reading it
Public key, such as id_ed25519.pub	644	Public keys aren’t secret; this is a convention
authorized_keys	600	Prevents other local users from reading or changing the trusted-key list
known_hosts	644	The contents aren’t secret; avoid allowing others to edit the file
~/.ssh/config	600	Prevents other users from changing your SSH client settings

These are practical defaults, not a claim that OpenSSH enforces every mode exactly. The key distinction is whether a file contains a secret, or whether another user could modify something SSH relies on.

Fix a private key that is too open

If the warning names a private key, restrict access to its owner:

chmod 600 ~/.ssh/id_ed25519

Replace the filename with the key you actually use. For an RSA key, for example:

chmod 600 ~/.ssh/id_rsa

Mode 600 means the owner can read and write the file, while group and other users have no access. 400—owner read-only—is also accepted for a private key you don’t need to modify.

A typical warning may look like this:

WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'id_rsa' are too open.

Then set the directory and other common files to their safe defaults as needed:

chmod 700 ~/.ssh
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts
chmod 600 ~/.ssh/config

You don’t need to have every file listed. If a file doesn’t exist, skip it; chmod reports an error for a missing path. For a closer look at what modes like 600 mean—and when they’re appropriate—see this explanation of chmod 600 and SSH file permissions.

Don’t treat every SSH file as a private key

The .pub file is designed to be shared with servers. OpenSSH doesn’t enforce a specific mode for it, so 644 is convention, not a requirement to keep its contents secret.

authorized_keys is on the server side. It lists public keys that are permitted to log in to the account. With the usual StrictModes setting, the important server-side risk is unauthorized write access: another local user who can edit the file could add a key of their own. 600 is a cautious default. A mode such as 644 can also pass that write-permission check because it doesn’t allow group or other users to write, but it exposes the list unnecessarily.

If you’re unsure what belongs in that file or why its permissions affect login, read this guide to the SSH authorized_keys file.

When changing the mode doesn’t work

Permissions and ownership are separate checks. Inspect the files with:

ls -la ~/.ssh

Look for the owner as well as the permission string. If you created a key using sudo, restored it from a backup, or copied it from another machine, it may belong to root or another account. Your normal user may not be able to change its permissions, and SSH may still reject it.

For a key that should belong to your current user, correct its ownership explicitly:

sudo chown "$USER":"$USER" ~/.ssh/id_ed25519

Use the actual key path, and don’t apply ownership changes blindly to unrelated files. If server-side public-key authentication still fails after checking the files, the issue may also be the username, the key being offered, or whether the matching public key is installed on the server.

The server checks the path above authorized_keys, too. In particular, with StrictModes enabled, a home directory writable by group or other can cause key authentication to fail even if the files inside ~/.ssh look correct. Inspect it with:

ls -ld ~

If group or other has write access, remove just those write bits:

chmod g-w,o-w ~

Windows uses ACLs, not chmod

On Windows, Unix permission bits don’t control access to SSH keys. The built-in OpenSSH client checks the file’s Windows access control list (ACL) instead. Inspect it in PowerShell with:

icacls $HOME\.ssh\id_ed25519

A private key should be owned by you and inaccessible to other users. If it was moved from a location with broad inherited access, inspect the ACL before changing it; chmod isn’t the fix for Windows ACLs.

The simple rule: protect private keys from being read by anyone else, protect SSH configuration and server-side key lists from unauthorized modification, and verify ownership when permission changes alone don’t resolve the error.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.