The "WARNING: UNPROTECTED PRIVATE KEY FILE!" warning appears when your SSH private key file has overly permissive permissions. OpenSSH requires private keys to be readable only by you (mode 600 or 400) as a security measure. When permissions are too open, SSH refuses to use the key and falls back to password authentication.
SSH uses cryptographic key pairs for secure, passwordless authentication. To prevent private keys from being stolen or misused, OpenSSH strictly validates that private keys are accessible only to their owner. When OpenSSH detects that a private key has group or world-readable permissions (like 644, 755, or similar), it displays this warning banner and refuses to use the key for authentication. This is a critical security feature—a world-readable private key could be compromised, allowing anyone with access to your system to impersonate you. The error typically appears in verbose SSH output (`ssh -v`) and is followed by an authentication failure. The key is silently ignored, and SSH falls back to other authentication methods like password login or different keys.
First, verify what permissions your private key currently has:
ls -la ~/.ssh/id_rsaOr for Ed25519 keys:
ls -la ~/.ssh/id_ed25519Look at the leftmost characters. You'll see something like:
- -rw------- (600) — Correct, key is only readable by you
- -r-------- (400) — Also correct, key is read-only by you
- -rw-r--r-- (644) — Too open! Readable by group and others (WRONG)
- -rwxr-xr-x (755) — Much too open (WRONG)
If you see 644, 755, or any permissions beyond 600/400, you need to fix them.
Use chmod to set the correct permissions. The most common fix is 600 (readable and writable by owner only):
chmod 600 ~/.ssh/id_rsaOr for Ed25519 keys:
chmod 600 ~/.ssh/id_ed25519Or for any other private key by path:
chmod 600 /path/to/private-keyAlternatively, you can use 400 (read-only) instead of 600:
chmod 400 ~/.ssh/id_rsaBoth 600 and 400 are acceptable. The difference is whether you want to allow yourself to write to the key file (600) or make it read-only (400).
Verify the fix worked:
ls -la ~/.ssh/id_rsaOutput should show -rw------- or -r--------.
The ~/.ssh directory itself also needs correct permissions. Set it to 700 (accessible only by you):
chmod 700 ~/.sshCheck it:
ls -ld ~/.sshShould show: drwx------ (700).
This is critical because if others can write to ~/.ssh, they could potentially modify your authorized_keys file or other sensitive files.
While you're at it, ensure other SSH files have correct permissions:
# Public keys should be readable (644)
chmod 644 ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/id_ed25519.pub
# authorized_keys should be readable only by you (600)
chmod 600 ~/.ssh/authorized_keys
# known_hosts should be readable only by you (600)
chmod 600 ~/.ssh/known_hosts
# config file should be readable only by you (600)
chmod 600 ~/.ssh/configCheck everything at once:
ls -la ~/.ssh/Expected output:
drwx------ 2 user group 4096 Jan 4 10:00 .
-rw------- 1 user group 3243 Jan 4 10:00 id_rsa
-rw-r--r-- 1 user group 743 Jan 4 10:00 id_rsa.pub
-rw------- 1 user group 2048 Jan 4 10:00 authorized_keys
-rw------- 1 user group 1024 Jan 4 10:00 known_hostsAfter fixing permissions, test your SSH connection:
ssh user@remote-hostOr with verbose output to see which key is being used:
ssh -v user@remote-hostYou should see output like:
Trying private key: /home/user/.ssh/id_rsa
...
Authentications that can continue: publickey
Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
Authentication succeeded (publickey).The "UNPROTECTED PRIVATE KEY FILE" warning should be gone, and authentication should work without falling back to password prompts.
If your private key is in a custom location (e.g., AWS .pem files, GitHub deploy keys):
# Fix the specific key file
chmod 600 /path/to/your/custom-key.pem
# Or if it's in a custom directory, fix that too
chmod 700 /path/to/custom/.ssh-like-directoryWhen using such keys with SSH, explicitly specify them:
ssh -i /path/to/custom-key.pem user@remote-hostOr add to your ~/.ssh/config:
Host my-custom-host
User ec2-user
IdentityFile /path/to/custom-key.pemUmask and New Keys: When you generate new SSH keys with ssh-keygen, it automatically sets correct permissions (600 for private keys, 644 for public keys). However, if your shell has a permissive umask (like 0022 or 0002), files created by other tools might inherit those permissions. Check your umask:
umaskIf it shows something other than 0022, you may need to adjust it in ~/.bashrc or ~/.zshrc:
umask 0022File Transfer Methods: When copying SSH keys between systems, the transfer method matters:
- scp and rsync preserve permissions correctly
- cp preserves permissions if the source is correct
- Browser downloads and email attachments default to 644
- Git clone of repositories containing keys might not set correct permissions
Windows/WSL Hybrid: If using Windows Subsystem for Linux (WSL) with Windows SSH tools, key permissions might be inherited from Windows NTFS ACLs. WSL can interpret these as permissive. Use chmod 600 inside WSL to fix.
Subkey Permissions: If using multiple keys with specific host configurations, ensure EVERY private key file has 600 permissions, not just id_rsa. Check:
for key in ~/.ssh/id_*; do
if [ ! -f "$key.pub" ]; then
chmod 600 "$key"
fi
doneSSH Agent: Using ssh-agent doesn't bypass permission checks—the agent still validates key permissions before using them. Fixing permissions is essential regardless of whether you use ssh-agent.
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
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
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" 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