How to fix This private key will be ignored. in SSH

SSHBEGINNERHIGHUpdated Jan 4, 2026· 205 views

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.

Quick fix

Fixes This private key will be ignored.

ls -la ~/.ssh/id_rsa
  1. Check the current permissions on your private key
  2. Fix the private key file permissions
  3. Fix the .ssh directory permissions
  4. Fix other SSH files if needed
ssh — error
ls -la ~/.ssh/id_rsa
This private key will be ignored.

What this error means

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.

Typical symptoms

  • SSH connection attempts fail with password prompt even though you have SSH keys configured
  • Warning message appears: 'Permissions 0777 for ... are too open'
  • SSH falls back to password authentication instead of using your key
  • SSH key file is not being used for authentication despite being specified
  • GitHub/GitLab authentication fails even though SSH key is configured
  • CI/CD pipeline fails at deployment stage due to SSH authentication failure

Common causes

  1. Private key file has world-readable permissions (chmod 777, 755, 644, 666, etc.)
  2. File was copied from another system that didn't preserve Unix permissions
  3. Downloaded from a browser or email client that doesn't set restrictive permissions
  4. Extracted from a tar/zip archive without preserving original permissions
  5. Accidentally changed permissions while troubleshooting other issues
  6. Created by a tool or script that doesn't set correct default permissions
  7. Mounted from a Windows share or virtual filesystem that doesn't support Unix permissions

How to fix "This private key will be ignored."

1Check the current permissions on your private key

Use ls -la to view the permissions on your SSH private key:

bash
ls -la ~/.ssh/id_rsa

Look at the first column of output. It should show -rw------- (600) for a private key. For example:

bash
-rw------- 1 user group 1704 Jan  4 10:30 /home/user/.ssh/id_rsa

If it shows anything other than -rw------- (like -rw-r--r--, -rw-rw-rw-, or -rwxrwxrwx), the permissions are too open.

2Fix the private key file permissions

Use chmod 600 to restrict the private key to be readable and writable only by you:

bash
chmod 600 ~/.ssh/id_rsa

This removes all permissions for group and others, leaving only read and write for the owner.

If you have multiple private keys, fix them all:

bash
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.

3Fix the .ssh directory permissions

The ~/.ssh directory itself must also have restrictive permissions:

bash
chmod 700 ~/.ssh

This allows only you to read, write, and execute (access) the directory.

Verify with:

bash
ls -ld ~/.ssh

Should show: drwx------ (700)

4Fix other SSH files if needed

While you're at it, set correct permissions on other SSH files:

bash
# 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_hosts

Verify everything is correct:

bash
ls -la ~/.ssh/

Expected output:

bash
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_hosts
5Test SSH authentication with your key

After fixing permissions, test your SSH connection:

bash
ssh -v user@remote-host

Use the -v flag (verbose) to see detailed output. Look for lines like:

bash
Trying private key: /home/user/.ssh/id_rsa
Authentications that can continue: publickey
Offering public key: /home/user/.ssh/id_rsa
...
Authenticated with key

If 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).

6For Windows users: Fix permissions via Properties

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:

powershell
# 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 $acl

Advanced notes

File 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:

bash
# 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 ~/.ssh

umask 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:

bash
# Check current umask
umask

# For SSH key operations, temporarily use restrictive umask
umask 0077
ssh-keygen -t ed25519 -C "your-email@example.com"
umask 0022  # restore default

Symlinks 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:

bash
# 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 | tail

Frequently asked questions

What does "This private key will be ignored." mean?
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.
How do I fix "This private key will be ignored."?
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.
What causes "This private key will be ignored."?
Private key file has world-readable permissions (chmod 777, 755, 644, 666, etc.) File was copied from another system that didn't preserve Unix permissions Downloaded from a browser or email client that doesn't set restrictive permissions
Is the "This private key will be ignored." error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading