Introduction

The UNPROTECTED PRIVATE KEY FILE! message appears when your SSH client decides that the private key file is too accessible to other users on the machine. This is a local file-permission problem, not an AWS networking problem, and the fix is usually to tighten the permissions on the .pem file before trying the EC2 connection again.

Why SSH Rejects the Key

A private key is supposed to be private. If the file can be read or modified by other users, OpenSSH treats that as a security risk and refuses to use the key.

That is why a command like this can fail:

ssh -i my-key.pem [email protected]

If my-key.pem is readable by group or other users, the SSH client prints the warning and ignores the file.

This behavior is intentional. SSH would rather refuse the key than risk using one that is stored insecurely.

Fix the Permissions on Linux or macOS

On Unix-like systems, the normal fix is:

chmod 400 my-key.pem

That means:

• owner can read
• nobody else gets any permission

Some people use:

chmod 600 my-key.pem

That is also usually acceptable because the owner can read and write, while group and others still get nothing.

After that, try the SSH command again:

ssh -i my-key.pem [email protected]

For most EC2 login failures with this specific message, that is enough.

Confirm the File Really Changed

If you want to verify the permissions, run:

ls -l my-key.pem

You should see something close to:

-r--------  1 user  staff  1679 Jan  8 12:00 my-key.pem

or:

-rw-------  1 user  staff  1679 Jan  8 12:00 my-key.pem

If the permission string still shows any group or world access, SSH may continue to reject the key.

Windows Considerations

On Windows, the same root issue exists, but the fix is based on NTFS permissions rather than chmod. If you are using OpenSSH on Windows, you may need to remove inherited permissions and restrict access to your user account.

For example, with icacls:

icacls .\my-key.pem /inheritance:r
icacls .\my-key.pem /grant:r "$($env:USERNAME):R"

If you are using WSL, the easiest approach is often to place the key inside the Linux filesystem and use normal Linux permissions there:

cp /mnt/c/Users/YourName/Downloads/my-key.pem ~/
chmod 400 ~/my-key.pem

That avoids some of the friction that can happen with Windows-mounted paths.

Do Not Confuse This With Other EC2 SSH Errors

This particular error is only about key-file permissions. It is not the same as:

• wrong username such as ubuntu vs ec2-user
• wrong security group rules
• instance not reachable
• wrong key pair entirely

If you fix the permissions and SSH still fails, the next step is to read the new error message carefully. The problem may have shifted from local file security to network access or instance login details.

Safer Key-Handling Practices

Once the immediate issue is fixed, it is worth cleaning up how the key is stored.

Good habits include:

• keep the key in a private directory such as ~/.ssh
• avoid leaving the key in shared download folders
• do not send the private key in chat or email
• keep a secure backup if the instance depends on that key

For example:

mkdir -p ~/.ssh
mv my-key.pem ~/.ssh/
chmod 400 ~/.ssh/my-key.pem

Then connect with:

ssh -i ~/.ssh/my-key.pem [email protected]

This is cleaner and more predictable than using a key directly from the downloads folder.

Common Pitfalls

The most common pitfall is running chmod on the wrong file or in the wrong directory and then retrying SSH without actually fixing the key being used.

Another mistake is assuming the AWS side is broken because the login target is EC2. The UNPROTECTED PRIVATE KEY FILE! message is about the local machine, not the instance.

A third issue is tightening the file permissions but leaving the key in an awkward location such as a synced or shared directory. The file may work, but the storage choice is still poor security practice.

Finally, Windows users often try Unix-only advice without adapting it to NTFS permissions or WSL filesystem behavior.

Summary

• 'UNPROTECTED PRIVATE KEY FILE! means the SSH client thinks the private key file is too accessible.'
• On Linux and macOS, chmod 400 my-key.pem is the usual fix.
• On Windows, use NTFS permission changes or move the key into WSL and secure it there.
• This error is local to your machine and separate from EC2 networking or username issues.
• Store EC2 private keys in a private location such as ~/.ssh and keep their permissions strict.