Fixing "UNPROTECTED PRIVATE KEY FILE" on a Mac

You copied a key onto a new Mac, or restored one from a backup, and now every connection ends like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/you/.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.

Nothing is broken and the key is fine. SSH is refusing to use it because anyone else with an account on this Mac could read it.

The fix

chmod 600 ~/.ssh/id_ed25519

Replace the filename with whatever key the error named — id_rsa, id_ecdsa, a work key with its own name. Then reconnect. That is the whole fix in the common case.

If you have several keys and want to correct all of them at once:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_* ~/.ssh/config
chmod 644 ~/.ssh/*.pub ~/.ssh/known_hosts

What the numbers mean

The three digits are owner, group, everyone.

• 600 — owner reads and writes, nobody else gets anything. This is what a private key needs. 400 (read-only for you) also works and some people prefer it.
• 644 — owner reads and writes, everyone else reads. Fine for a public key, fatal for a private one. This is what you get by default from a lot of copy operations, which is why this error is so common.
• 700 on the ~/.ssh directory — you can enter and list it, nobody else can.

SSH checks that the private key is not readable or writable by group or “other”. It does not care whether the Mac actually has other users; the check is on the bits, not on the situation.

Why the permissions were wrong in the first place

The usual culprits, because knowing which one it was tells you whether it will happen again:

• Copied from a USB stick, a FAT/ExFAT volume or a shared drive. Those filesystems do not store Unix permissions, so everything arrives as 777 or 644.
• Restored from a zip or a tarball made on another machine. unzip in particular does not preserve modes reliably.
• Copied with a Finder drag from a network share.
• Generated as root or with sudo, which leaves the file owned by root. Then chmod alone is not enough — see below.

When chmod is not enough: ownership

If chmod runs without complaint and the error persists, check who owns the file:

ls -le ~/.ssh/id_ed25519

If the owner is root rather than your username, fix that too:

sudo chown $(whoami):staff ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519

There is a third, rarer case specific to macOS: an ACL left over from a copy. ls -le shows ACL entries as extra numbered lines below the file. If you see any, strip them:

chmod -N ~/.ssh/id_ed25519

The other half of the problem: the server

The same rule applies on the server, and there it fails silently — you just get “Permission denied (publickey)” with no explanation, because sshd will not tell a stranger why it refused. This is by far the more frustrating version.

sshd runs a check called StrictModes on the account you are logging into, and refuses key authentication if anything in the chain is group- or world-writable:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 755 ~          # your HOME must not be group-writable

That last one catches people out constantly. A home directory at 775 or 770 — common after a usermod or on a box where someone added the user to a shared group — makes key auth fail while the permissions on .ssh and authorized_keys look perfectly correct.

To confirm it, look at the server’s auth log while you attempt a connection:

sudo tail -f /var/log/auth.log        # Debian/Ubuntu
sudo journalctl -u sshd -f            # RHEL/Fedora/Arch

Authentication refused: bad ownership or modes for directory /home/deploy is the message you are looking for, and it names the exact path to fix.

Passphrases are a different thing

Worth separating, because the two get conflated: file permissions stop other users on this machine from reading the key. A passphrase encrypts the key itself, so a copy that leaves the machine is useless without it.

They solve different problems and you want both. Adding a passphrase to a key you already have does not require regenerating it:

ssh-keygen -p -f ~/.ssh/id_ed25519

To avoid typing it on every connection, put this in ~/.ssh/config and macOS will hold it in your Keychain:

Host *
    AddKeysToAgent yes
    UseKeychain yes

The sandbox version of this on a Mac

If you use a Mac App Store SSH client, there is a related situation that looks like a permissions problem but is not. Sandboxed apps cannot read ~/.ssh at all — not because the mode is wrong, but because macOS does not grant the app access to that directory.

Upshell handles it by asking you to select the key through a file picker once. That grants the app access to that specific file, the key material goes into the Keychain, and it never has to touch ~/.ssh again. The file’s own permissions are irrelevant to that path, so a key that works in Upshell can still throw this error in Terminal, and vice versa.

Step by step

1. Read which file the error named — it prints the full path. Fix that one, not a guess.
2. chmod 600 <that file> — and chmod 700 ~/.ssh for the directory.
3. Reconnect. For most people it ends here.
4. If it persists, check ownership — ls -le on the key. Root-owned needs sudo chown $(whoami):staff; visible ACL lines need chmod -N.
5. If the error changed to “Permission denied (publickey)”, move to the server — chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, chmod 755 ~, and read /var/log/auth.log while you retry.

Questions people ask

Is chmod 400 better than 600 for an SSH key?

Only marginally, and mostly as a reminder to yourself. 400 makes the key read-only so you cannot overwrite it by accident. SSH accepts both; it only objects to group and other having access.

Why does SSH care if I am the only user on this Mac?

Because it checks the permission bits, not your circumstances. It has no way to know whether another account exists now or will exist next month, and a private key is exactly the file where being strict is worth the friction.

I fixed the permissions and still get Permission denied (publickey)

Then the client-side problem is solved and you have hit the server-side one. Check ~/.ssh (700), ~/.ssh/authorized_keys (600) and the home directory itself (not group-writable) on the server, then read its auth log — it will name the offending path.

Do public keys need restrictive permissions too?

No. A .pub file is meant to be handed out; 644 is normal and SSH does not complain about it. Only private keys are checked.