SSH enforces strict file permissions to prevent unauthorized access to your private keys. This error occurs when SSH detects that your private key file has permissions that are too permissive (world-readable or group-readable), which could expose your credentials to other users on the system.
SSH uses public-key cryptography where your private key must remain secret. If any other user on your system can read your private key file, they could impersonate you and gain unauthorized access to remote servers. SSH performs a security check before attempting authentication: it verifies that only the file owner (you) has read and write permissions, and that no other users or groups can access the key. If the permissions are too open (e.g., 644, 755, or 666), SSH refuses to use the key and displays this error. This is a critical security measure—even well-intentioned file sharing can compromise your accounts.
First, verify what permissions your private key currently has:
ls -l ~/.ssh/id_rsaOr check all files in your SSH directory:
ls -la ~/.ssh/Look for your private key file (typically named id_rsa, id_ed25519, id_ecdsa, or a custom name). The permissions will show something like:
- -rw------- 1 user group (600) - CORRECT, only you can read/write
- -rw-r--r-- 1 user group (644) - WRONG, group and others can read
- -rwxrwxrwx 1 user group (777) - WRONG, everyone has full access
If you see anything other than 600 for the private key, proceed to the next step.
Set the private key to be readable and writable by only the owner:
chmod 600 ~/.ssh/id_rsaReplace id_rsa with your actual key filename if it's different (e.g., id_ed25519, github-key).
Verify the fix:
ls -l ~/.ssh/id_rsaShould now show: -rw------- 1 user user (600 permissions)
Your .ssh directory must also have restrictive permissions (700):
chmod 700 ~/.sshVerify:
ls -ld ~/.sshShould show: drwx------ ... user user (700 permissions)
This ensures that only you can list, read, or modify files in your SSH directory.
While you're at it, set correct permissions for all SSH files:
# Fix public key (readable by anyone, but only writable by you)
chmod 644 ~/.ssh/id_rsa.pub
# Fix authorized_keys (readable/writable only by you)
chmod 600 ~/.ssh/authorized_keys
# Fix known_hosts (readable/writable only by you)
chmod 600 ~/.ssh/known_hosts
# Fix config file if present (readable/writable only by you)
chmod 600 ~/.ssh/configSummary of correct SSH permissions:
- ~/.ssh directory: 700 (drwx------)
- Private keys (id_rsa, id_ed25519): 600 (-rw-------)
- Public keys (id_rsa.pub): 644 (-rw-r--r--)
- authorized_keys: 600 (-rw-------)
- known_hosts: 600 (-rw-------)
- config: 600 (-rw-------)
After fixing permissions, test that SSH now works:
ssh -i ~/.ssh/id_rsa [email protected]Or test with a specific key using verbose mode to debug:
ssh -vvv -i ~/.ssh/id_rsa [email protected]The verbose output should show:
Trying private key: /home/user/.ssh/id_rsa
...
Authentications that can continue: publickey
...
Authenticated with RSA keyIf SSH still fails, the issue is not permissions—check that your public key is in authorized_keys on the remote server.
When generating new SSH keys, ensure proper permissions from the start:
# Generate a new key (automatically creates it with 600 permissions)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""
# Or with RSA (if you need wider compatibility)
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ""The ssh-keygen tool creates private keys with 600 permissions automatically. Just verify:
ls -l ~/.ssh/id_ed25519Should show -rw------- ... (600).
Advanced troubleshooting:
Windows PowerShell / ACLs: If using PowerShell or Git Bash on Windows, Unix-style chmod may not fully resolve the issue. Windows uses Access Control Lists (ACLs) instead. You may need to remove inherited permissions:
1. Right-click the key file → Properties → Security tab
2. Click "Advanced" → "Disable inheritance" → "Remove all inherited permissions"
3. Add only your user account with "Full Control"
This mimics Unix mode 600 in Windows.
WSL (Windows Subsystem for Linux): WSL supports Unix permissions, but inherited ACLs from Windows can interfere. If chmod 600 doesn't work:
# Set metadata in WSL to use Unix permissions
chmod 600 ~/.ssh/id_rsa
# Clear WSL permission caches
sudo chown $USER:$USER ~/.ssh/id_rsaHome Directory Permissions: SSH also checks that your home directory (~) is not world-writable. If ~ has 777 permissions, even with correct key permissions, SSH will reject the key:
# Verify home directory permissions
ls -ld ~
# Should show something like: drwxr-xr-x (755 or 750)
# If you see 777 or drwxrwxrwx, fix it:
chmod 755 ~SSH Agent Caching: If SSH agent has cached the key with wrong permissions, clear the cache:
ssh-add -D # Remove all keys from agent
ssh-add ~/.ssh/id_rsa # Re-add key (may prompt for passphrase)Custom Key Locations: If your key is in a non-standard location, apply the same rules:
chmod 600 /path/to/custom/keyAnsible / Terraform: Some tools bypass SSH client checks. If Ansible or Terraform still fails after fixing permissions, check the tool's own key permission validation in its logs.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation
How to fix "sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation" in SSH