Chmod 600 – Linux Permission Guide

Replace mykey.pem with your actual key filename. If you're on Windows and this doesn't work, see the Windows section below — NTFS handles permissions differently and needs a different fix.

What does chmod 600 mean?

In Linux, 600 is an octal representation of file system permissions that gives the owner read and write access and blocks everyone else completely. It's the standard for any file that should stay private and doesn't need to be executed — SSH keys, .env files, API credentials, and other secrets.

Why "600"? How the Numbers Work

Every digit in a chmod code is the sum of three values:

Add them together to build any permission digit:

So 600 reads as: 6 for owner (read + write), 0 for group (nothing), 0 for others (nothing).

Permission Matrix (rw-------)

Numeric vs Symbolic Notation

chmod accepts two equivalent styles. All three commands below produce identical results:

Letters used in symbolic mode: u = user (owner), g = group, o = others, a = all. Operators: + adds a permission, - removes it, = sets it exactly.

How to Verify It Worked

After running chmod, check with ls -l:

The six trailing dashes are what you're looking for — they confirm no one but you can touch the file. You can also check numerically with stat -c "%a %n" id_rsa, which should print 600.

The SSH Private Key Use Case

OpenSSH strictly enforces that private key files are readable only by their owner. If any other user on the system could read your key, anyone who compromised that user account could steal your key — so SSH refuses to use it at all. This enforcement is controlled by the StrictModes yes setting in sshd_config, which is on by default.

The moment your key's permissions slip to 644, 664, 755, or anything else group- or world-readable, you'll see this:

The complete recipe for a healthy ~/.ssh directory:

AWS EC2 .pem Keys (The Most Common Scenario)

If you just downloaded a key from the AWS console and tried to SSH into your EC2 instance, you almost certainly hit the "UNPROTECTED PRIVATE KEY FILE" warning. Files downloaded from a browser land in ~/Downloads with default permissions around 644 — too loose for SSH.

The fix, start to finish:

Windows: Why chmod 600 Often Doesn't Work

This trips up a lot of people new to SSH on Windows. You ran chmod 600 mykey.pem in Git Bash, it completed silently, and yet SSH still throws "UNPROTECTED PRIVATE KEY FILE." The reason: Windows filesystems use NTFS ACLs, not Unix permission bits. Git Bash and WSL try to emulate chmod, but the emulation doesn't always stick, and the OpenSSH client on Windows reads the real NTFS ACLs — not the fake Unix bits.

The real fix on Windows is to remove all inherited permissions and grant access only to your user. Three ways to do that:

icacls mykey.pem /inheritance:r
icacls mykey.pem /grant:r "%username%:R"

cp /mnt/c/Users/you/Downloads/mykey.pem ~/
chmod 600 ~/mykey.pem
ssh -i ~/mykey.pem ec2-user@host

Other Files That Should Be chmod 600

Any file containing credentials, tokens, or secrets belongs at 600 (or stricter). Here's the checklist:

600 vs 400 vs 700 — The Private Trio

These three permissions all mean "only the owner has access" — but they're different in subtle ways that matter. This is the #1 source of confusion in SSH guides.

chmod 600 vs Other Common Permissions

Can You Use chmod 600 on a Directory?

Technically yes — but you almost never should. Directories need the execute bit (1) to be enterable. A directory at 600 looks like this:

You can see the folder exists and list its entries by name, but you can't enter it or read any of its files. For a private directory, use 700 instead — that's what 700 was designed for.

Ownership Matters Too

600 only protects the file if the right user owns it. A key file at 600 owned by root is useless to you as a regular user — you can't read it, and SSH tries to read it as you.

Common pattern: you copied a key with sudo cp, which made root the owner. Fix with sudo chown $USER:$USER filename.

Troubleshooting

Frequently Asked Questions