chmod 400 (r--------)

What it means

chmod 400 gives the file's owner permission to read it, and nobody else any permission at all. Not even the owner can write to it without changing the mode first. In ls -l it shows as -r--------.

Each digit is a sum: read is 4, write is 2, execute is 1. So 4 means read only, and 0 means nothing.

The symbolic form of the same command is:

chmod u=r,go= key.pem

On a file

The owner can open and read the file. Writing fails with "Permission denied" until the owner adds write access back (chmod 600). Root ignores read and write bits, so root can still read and change the file.

Note that 400 does not stop the owner from deleting the file. Deleting or renaming is controlled by the permissions of the directory that holds it, not by the file's own mode. Tools like rm ask for confirmation on a write-protected file, but go ahead if you answer yes or pass -f.

On a directory

400 is almost never what you want on a directory. Read without execute lets the owner list the names inside (ls dir), but not open, cd into or stat anything in it. ls -l prints a row of question marks and "Permission denied" for every entry. Directories need execute (x) to be usable; see chmod 700 for a private directory.

Typical uses

• SSH private keys. OpenSSH refuses a private key that group or others can read, with "UNPROTECTED PRIVATE KEY FILE". Both 400 and 600 are accepted. Many cloud providers tell you to run chmod 400 on a downloaded .pem key so you can't overwrite it by accident.
• TLS private keys and secrets that are written once and only read afterward, by a service running as the file's owner.
• Files you want to protect from your own mistakes, like a generated config you should not hand-edit.

chmod 400 ~/.ssh/id_ed25519
ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.10

If a program needs to rewrite the file later (for example, a tool that rotates its own token), use chmod 600 instead, which adds write for the owner.

Pitfalls

• Wrong owner. 400 only helps if the right user owns the file. If root owns the key and you connect as yourself, you can't read it. Fix ownership with chown user:user file first.
• Recursive changes. chmod -R 400 dir removes execute from the directory and every subdirectory, which locks you out of the tree. Apply file and directory modes separately:

find ~/.secrets -type d -exec chmod 700 {} +
find ~/.secrets -type f -exec chmod 400 {} +

• Backups and sync tools. Some tools copy files with their mode, and some reset it. Check the mode after restoring a key, since a key restored as 644 is rejected by SSH.

Security notes

400 keeps other local users from reading the file, but it doesn't protect against anything running as you or as root. Keep private keys off shared accounts, and protect them with a passphrase if they leave the server.

Related modes

• chmod 600: owner can read and write. The usual mode for keys and .env files.
• chmod 444: read-only for everyone.
• chmod 700: the private directory that should hold such files, like ~/.ssh.

Try other combinations in the chmod calculator, which converts between octal, symbolic and checkbox form.