Fix SSH 'Permissions Are Too Open' Error

It's maddening—you set up your SSH key, carefully pasted the public key to the server, and still get hit with Permissions 0644 for '/home/you/.ssh/id_rsa' are too open. You've been told to chmod 600 that file, maybe you already did, and it's still broken. Let's cut the crap and fix it for real.

The Fix: Set These Exact Permissions

OpenSSH's sshd is paranoid by design. It checks permissions on every file in the chain, not just the private key. Here's the one-shot fix:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/authorized_keys

Run this as your user, not root. Then test again:

ssh -i ~/.ssh/id_rsa user@server

If that still fails, check the home directory itself:

ls -la ~ | grep ' \.ssh'
# Should show: drwx------ 2 you you 4096 ... .ssh

The . directory (your home) must not be group- or world-writable. By default /home/you is usually 755, which is fine—but if you ever did chmod 777 ~, revert it: chmod 755 ~.

Why This Works

The reason step 3 works is that OpenSSH runs a multi-level permission check before it even looks at your key. What's actually happening here is that sshd (the server-side daemon) and ssh (the client) both enforce a strict security model: any file that could be modified by another user is a potential attack vector.

Specifically:

~/.ssh must be 700 — no group or world access. If someone else can ls your .ssh directory, they could see your key file names, then try to read them if permissions slip.
id_rsa must be 600 — only you can read or write it. Even your own group is denied. The logic: if a process somehow runs as your group (e.g., a CGI script), it shouldn't grab your key.
id_rsa.pub can be 644 — public keys are public. OpenSSH doesn't care about their permissions except that they shouldn't be writable by others.
authorized_keys must be 600 — if someone else can write to this file, they can add their own key. OpenSSH wants it locked down.

The error message "Permissions 0644 for '/home/user/.ssh/id_rsa' are too open" is actually from the client side, not the server. When you run ssh, it checks your private key's permissions before even sending it. If the key is too permissive, it refuses to use it. Same check happens server-side after the key arrives.

Less Common Variations

1. The `.ssh` Folder Is 755 (Some Distros)

Ubuntu's installer creates ~/.ssh with 700 by default. But if you copied your key from another system or restored from backup, the permissions may have been preserved as 755. This triggers the same error even if the key itself is 600. Fix: chmod 700 ~/.ssh.

2. You're Using Windows Subsystem for Linux (WSL)

WSL1 has a known issue: Windows file permissions don't map cleanly to Linux. The chmod command may appear to succeed but actually doesn't change the underlying NTFS permissions. Workaround: store your SSH keys inside WSL's native filesystem (~/.ssh is in /home/you/.ssh, not on a mounted Windows drive like /mnt/c). Or use WSL2, where the ext4 filesystem supports proper Linux permissions.

3. You Have Multiple Keys and One Is Bad

If you have ~/.ssh/id_rsa and ~/.ssh/id_ecdsa, SSH tries them in order. A malformed key (e.g., missing newline at the end) can fail silently, then the next key might also fail due to permissions on that file. Run ssh -v user@server to see exactly which key it's reading and where it stops.

4. The `authorized_keys` File on the Server Is Wrong

The server-side file at ~/.ssh/authorized_keys must also be 600 and owned by you. If you uploaded it with scp while permissions were wrong locally, the server copy inherits those wrong permissions. Log into the server and fix them there too.

5. SSH Config Overrides Directories

If you set IdentityFile in ~/.ssh/config to a file outside ~/.ssh, SSH still checks permissions on that path—and it's even stricter. Files outside ~/.ssh must be owned by you and not writable by group or world. That includes the directory containing the key. Best practice: keep keys in ~/.ssh.

Prevention

Set a one-line fix in your shell profile so you never forget:

# In ~/.bashrc or ~/.zshrc
alias fixssh='chmod 700 ~/.ssh; chmod 600 ~/.ssh/id_*; chmod 644 ~/.ssh/*.pub ~/.ssh/known_hosts'

Also, never copy SSH keys with cp -p or rsync -a across machines—those preserve permissions that may not be correct. Instead, use ssh-copy-id for public keys, and for private keys, copy the content via clipboard and paste into a new file with the right umask (022 for public, 077 for private).

One more thing: if you're in a team environment and someone says "just chmod 777 your key to make it work," don't. That's a bad idea and OpenSSH will reject it anyway. The error will then say bad permissions with a different code. Stick with 600. It's not negotiable.