The "This private key will be ignored" warning appears when your SSH private key file has permissions that are too permissive. SSH is strict about key file security and will refuse to use keys that are readable by other users. Fixing this requires restricting the file permissions to be readable only by the owner.
SSH relies on cryptographic key pairs for secure, passwordless authentication. For security, SSH requires that private key files are readable only by their owner—no group or world permissions allowed. If SSH detects that a private key file has permissions broader than 600 (owner read/write only), it will ignore that key as a security precaution. When SSH encounters an unprotected private key, it logs a warning: ``` @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0777 for '/home/user/.ssh/id_rsa' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. ``` This is a critical security feature. If your private key is world-readable, anyone on the system could copy it and impersonate you. SSH refuses to proceed with authentication rather than accept this risk.
Use ls -la to view the permissions on your SSH private key:
ls -la ~/.ssh/id_rsaLook at the first column of output. It should show -rw------- (600) for a private key. For example:
-rw------- 1 user group 1704 Jan 4 10:30 /home/user/.ssh/id_rsaIf it shows anything other than -rw------- (like -rw-r--r--, -rw-rw-rw-, or -rwxrwxrwx), the permissions are too open.
Use chmod 600 to restrict the private key to be readable and writable only by you:
chmod 600 ~/.ssh/id_rsaThis removes all permissions for group and others, leaving only read and write for the owner.
If you have multiple private keys, fix them all:
chmod 600 ~/.ssh/id_*Caution: Don't accidentally include your public key (.pub) in this command. Public keys can be safely set to 644 or 600.
The ~/.ssh directory itself must also have restrictive permissions:
chmod 700 ~/.sshThis allows only you to read, write, and execute (access) the directory.
Verify with:
ls -ld ~/.sshShould show: drwx------ (700)
While you're at it, set correct permissions on other SSH files:
# For all private keys
chmod 600 ~/.ssh/id_*
# For public keys (can be more permissive)
chmod 644 ~/.ssh/id_*.pub
# For authorized_keys on this machine
chmod 600 ~/.ssh/authorized_keys
# For SSH config file (if it exists)
chmod 600 ~/.ssh/config
# For known_hosts (can be 644)
chmod 644 ~/.ssh/known_hostsVerify everything is correct:
ls -la ~/.ssh/Expected output:
total 32
drwx------ 2 user group 4096 Jan 4 10:30 .
drwxr-xr-x 15 user group 4096 Jan 4 10:30 ..
-rw------- 1 user group 1704 Jan 4 10:30 id_rsa
-rw-r--r-- 1 user group 391 Jan 4 10:30 id_rsa.pub
-rw------- 1 user group 399 Jan 4 10:30 authorized_keys
-rw-r--r-- 1 user group 2097 Jan 4 10:30 known_hostsAfter fixing permissions, test your SSH connection:
ssh -v user@remote-hostUse the -v flag (verbose) to see detailed output. Look for lines like:
Trying private key: /home/user/.ssh/id_rsa
Authentications that can continue: publickey
Offering public key: /home/user/.ssh/id_rsa
...
Authenticated with keyIf you see "Authenticated with key", the fix worked!
If SSH still fails but no longer shows the "unprotected private key" warning, the permissions are now correct but the authentication failure is due to a different issue (e.g., key not in authorized_keys).
Windows doesn't use Unix permissions, but OpenSSH on Windows still enforces security checks. To fix this:
1. Right-click the private key file (e.g., id_rsa)
2. Click "Properties"
3. Go to the "Security" tab
4. Click "Advanced"
5. Click "Disable inheritance" and choose "Remove all inherited permissions"
6. Click "Add" and add your user account with "Full Control"
7. Remove "SYSTEM" and "Administrators" if present (only your user should have access)
8. Click "Apply" and "OK"
Alternatively, use PowerShell with administrative privileges:
# For a specific key file
$keyPath = "$env:USERPROFILE\.ssh\id_rsa"
$acl = Get-Acl $keyPath
$acl.SetAccessRuleProtection($true, $false)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$env:USERNAME", "FullControl", "Allow")
$acl.SetAccessRule($rule)
Set-Acl -Path $keyPath -AclObject $aclFile Ownership: In addition to permissions, SSH also checks file ownership. The private key must be owned by the user running SSH. If the owner is incorrect, SSH will also refuse to use it:
# Check ownership
ls -l ~/.ssh/id_rsa
# Fix ownership if needed (replace 'user' with your username)
chown user:user ~/.ssh/id_rsa
chown user:user ~/.sshumask and Future Key Generation: To prevent this issue in the future, ensure new keys are created with correct permissions. When using ssh-keygen, it should create files with mode 600 by default. However, if your shell's umask is set too permissively (e.g., 0002), you may need to adjust it:
# Check current umask
umask
# For SSH key operations, temporarily use restrictive umask
umask 0077
ssh-keygen -t ed25519 -C "[email protected]"
umask 0022 # restore defaultSymlinks and Special Cases: If your private key is accessed via a symlink, SSH checks the permissions of both the symlink and the target file. Both must be properly restricted. If your .ssh directory is a symlink, that should be fine as long as the target directory has correct permissions.
SELinux and AppArmor: On systems with mandatory access controls (SELinux on RHEL/CentOS, AppArmor on Ubuntu), SSH security contexts may also enforce restrictions. Standard chmod fixes should work, but if problems persist after fixing permissions, check security module logs:
# Check for SELinux denials
sudo ausearch -k ssh 2>/dev/null | tail
# Check AppArmor denials
sudo grep -i ssh /var/log/audit/audit.log 2>/dev/null | tailSomeone 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
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