Fix SSH "Permissions Are Too Open" (UNPROTECTED PRIVATE KEY FILE)

SSH just refused your key with a wall of @ symbols and WARNING: UNPROTECTED PRIVATE KEY FILE!. The fix is one line: tighten the private key so only you can read it.

chmod 600 ~/.ssh/id_ed25519

That clears the error immediately. The rest of this page is the why, the full set of permissions SSH checks, and the ownership trap that chmod alone does not fix.

What the error actually says

Run anything that loads the key and SSH stops you cold:

The number in the message (0644, 0640, 0444, whatever yours is) is the current mode. Anything that grants group or other a single bit on a private key trips the check. SSH then refuses to use the key and falls back to the next auth method, which is usually why you also see Permission denied (publickey).

Why SSH is this strict

A private key is a secret. If any other account on the machine can read the file, they can copy your key and impersonate you on every server that trusts it. So OpenSSH refuses to load a private key whose permissions let anyone but the owner read it. On the server side the same rule is enforced by StrictModes, which is on by default in sshd: a world-writable ~/.ssh or authorized_keys gets silently ignored, and you are left wondering why key auth "stopped working."

This almost always shows up after you copied keys from another machine (a backup, a new laptop, a Docker bind mount, a cloud sync folder) and the loose permissions came along for the ride. Freshly generated keys already have the right modes; see how to create an SSH key for that flow.

The full set of permissions SSH expects

Fixing the private key clears the immediate error, but ~/.ssh has several files and SSH checks all of them. Set the lot:

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

Here is what each file should look like on Linux and macOS:

A correct ~/.ssh looks like this:

chmod is not enough if the owner is wrong

chmod sets the mode, but SSH also checks who owns the file. If the key is owned by root (the classic result of running sudo ssh-keygen), no amount of chmod as your normal user will help, because you cannot even change a file you do not own. Fix the owner first:

sudo chown -R $USER:$USER ~/.ssh && chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519

One more owner-level trap: your home directory must not be group- or world-writable either. If chmod 700 ~/.ssh did not help, check ~ itself with ls -ld ~ and tighten it (chmod g-w,o-w ~). sshd walks the whole path and refuses keys sitting under a loosely-permissioned home.

Windows: it is ACLs, not chmod

Windows OpenSSH does not use Unix modes. It checks NTFS ACLs, and the error text is the same. The fix is to strip inherited permissions so only your account (and SYSTEM/Administrators) can read the key, which is what the icacls ... /inheritance:r /grant:r commands above do. A key in your own %USERPROFILE%\.ssh is usually scoped correctly already; you mostly hit this after copying a key in from elsewhere.

FAQ

See also

• How to Create an SSH Key in 2026: generate a key with the right permissions from the start, and why you should never sudo ssh-keygen.
• SSH Cheat Sheet: the rest of the SSH surface, including the ~/.ssh/config and ssh-copy-id this error often interrupts.
• How to find files by owner, group, or permission: audit a whole tree for the loose modes that cause this.