How to fix @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ in SSH

SSHBEGINNERHIGHUpdated Jan 4, 2026· 223 views

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.

Quick fix

Fixes @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

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 permissions on other SSH files
ssh — error
ls -la ~/.ssh/id_rsa
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

What this error means

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.

Typical symptoms

  • SSH displays the UNPROTECTED PRIVATE KEY FILE warning banner
  • SSH authentication fails even though you have the correct private key
  • SSH falls back to password authentication despite having key-based auth set up
  • The error appears in verbose output (`ssh -v`) but not always in normal output
  • Works on one system but not another (different umask or file transfer methods)
  • Recently copied or downloaded a private key that worked before

Common causes

  1. Downloaded private key from a browser or email client, which defaults to permissive permissions (644 or 666)
  2. Copied or transferred key from another system without resetting permissions
  3. Unpacked SSH key from a tar/zip archive that didn't preserve Unix file permissions
  4. Accidentally ran chmod with wrong permissions on the key file or ~/.ssh directory
  5. Misconfigured umask in shell profile (default umask is too permissive for SSH)
  6. Transferred key over SMB, NFS, or other network filesystem that doesn't preserve permissions correctly
  7. Git clone or file download set permissions based on filesystem defaults, not SSH requirements

How to fix "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"

1Check the current permissions on your private key

First, verify what permissions your private key currently has:

bash
ls -la ~/.ssh/id_rsa

Or for Ed25519 keys:

bash
ls -la ~/.ssh/id_ed25519

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

2Fix the private key file permissions

Use chmod to set the correct permissions. The most common fix is 600 (readable and writable by owner only):

bash
chmod 600 ~/.ssh/id_rsa

Or for Ed25519 keys:

bash
chmod 600 ~/.ssh/id_ed25519

Or for any other private key by path:

bash
chmod 600 /path/to/private-key

Alternatively, you can use 400 (read-only) instead of 600:

bash
chmod 400 ~/.ssh/id_rsa

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

bash
ls -la ~/.ssh/id_rsa

Output should show -rw------- or -r--------.

3Fix the ~/.ssh directory permissions

The ~/.ssh directory itself also needs correct permissions. Set it to 700 (accessible only by you):

bash
chmod 700 ~/.ssh

Check it:

bash
ls -ld ~/.ssh

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

4Fix permissions on other SSH files

While you're at it, ensure other SSH files have correct permissions:

bash
# 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/config

Check everything at once:

bash
ls -la ~/.ssh/

Expected output:

bash
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_hosts
5Try SSH again to confirm the fix

After fixing permissions, test your SSH connection:

bash
ssh user@remote-host

Or with verbose output to see which key is being used:

bash
ssh -v user@remote-host

You should see output like:

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

6For keys in non-standard locations

If your private key is in a custom location (e.g., AWS .pem files, GitHub deploy keys):

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

When using such keys with SSH, explicitly specify them:

bash
ssh -i /path/to/custom-key.pem user@remote-host

Or add to your ~/.ssh/config:

bash
Host my-custom-host
  User ec2-user
  IdentityFile /path/to/custom-key.pem

Advanced notes

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

bash
umask

If it shows something other than 0022, you may need to adjust it in ~/.bashrc or ~/.zshrc:

bash
umask 0022

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

bash
for key in ~/.ssh/id_*; do
  if [ ! -f "$key.pub" ]; then
    chmod 600 "$key"
  fi
done

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

Frequently asked questions

What does "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @" mean?
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.
How do I fix "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @"?
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.
What causes "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @"?
Downloaded private key from a browser or email client, which defaults to permissive permissions (644 or 666) Copied or transferred key from another system without resetting permissions Unpacked SSH key from a tar/zip archive that didn't preserve Unix file permissions
Is the "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @" 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