“Permissions are too open”: fixing SSH key permissions

SSH is fussy on purpose: if anyone else could read your private key, it refuses to use it. Here are the exact permissions it wants, and the one-line fixes.

The error

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/sam/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

Mode 0644 means everyone on the machine can read the file. SSH treats a readable private key as a leaked key and skips it, then usually falls back to asking for a password or fails with Permission denied (publickey). It often happens after copying keys from another computer, a USB stick, a zip file or a shared folder, which reset the mode.

The permissions SSH wants

Ownership matters as much as mode: chown -R $USER: ~/.ssh fixes keys that were copied in as root. On the server side, sshd silently ignores authorized_keys when the file, the .ssh folder or the home folder is writable by anyone else (the StrictModes setting), which is the usual cause of “my key is in authorized_keys but it still asks for a password”.

New to the three-digit numbers? chmod 755 and 644 explained breaks them down, and the number base converter shows each digit as read, write and execute bits.

Fixing it on Windows

Windows' built-in OpenSSH does the same check using file permissions instead of chmod. In PowerShell:

icacls $env:USERPROFILE\.ssh\id_ed25519 /inheritance:r
icacls $env:USERPROFILE\.ssh\id_ed25519 /grant:r "$($env:USERNAME):(R)"

The first line stops the file inheriting access from its folder, the second gives read access to you alone. Keys kept in WSL should live inside the Linux file system (~/.ssh in WSL), not under /mnt/c, where chmod does not stick by default.

Making a new key the right way

ssh-keygen -t ed25519 -C "laptop-2026"

ssh-keygen creates the files with the right modes already. Ed25519 keys are short, fast and supported everywhere modern; use -t rsa -b 4096 only for very old servers. Add a passphrase and let ssh-agent remember it, so a stolen laptop doesn't mean a stolen login. The comment after -C is just a label; it is visible to anyone who sees the public key, so keep it neutral.

Other key errors, decoded

Getting Permission denied (publickey) instead? Follow the publickey guide.

• Permission denied (publickey): the server tried every key you offered and accepted none. Run ssh -v user@host to see which files were offered; check the public key really is in the server's authorized_keys and that the permissions above are right.
• Load key "...": invalid format: the file is damaged or not a key at all, often Windows line endings or a missing final newline after copy-paste. A private key starts with -----BEGIN OPENSSH PRIVATE KEY-----.
• Too many authentication failures: your agent offered too many keys before the right one. Point at one key with -i plus IdentitiesOnly yes in ~/.ssh/config.
• REMOTE HOST IDENTIFICATION HAS CHANGED: not a permissions problem. See the full walkthrough in Host key verification failed — confirm the change is expected, then remove one line with ssh-keygen -R host.

Comparing fingerprints? ssh-keygen -lf key.pub prints the SHA256 fingerprint SSH shows on first connect. Not sure what a blob of text is? Paste a public key (never a private one) into What is this?.

Questions

Published 4 November 2026.