chmod 600: owner read and write only (rw-------)

What it means

chmod 600 gives the owner read and write access, and takes every permission away from the group and from everyone else. It's the standard mode for private files. In ls -l it shows as -rw-------.

Who	Digit	Read	Write	Execute	Symbolic
Owner (u)	6	yes	yes	no	`rw-`
Group (g)	0	no	no	no	`---`
Others (o)	0	no	no	no	`---`

6 is read (4) plus write (2). The symbolic equivalent:

chmod u=rw,go= ~/.ssh/id_ed25519

On a file

The owner can read and change the file. Other users can't read it, copy it or even see its contents through a backup made as their own account. Root is not affected by permission bits, so root can always read it.

On a directory

600 on a directory leaves out execute, so even the owner can't enter it or open the files inside. For a private directory use chmod 700.

Typical uses

File	Why 600
`~/.ssh/id_rsa`, `~/.ssh/id_ed25519`	OpenSSH refuses private keys that others can read ("UNPROTECTED PRIVATE KEY FILE")
`~/.ssh/authorized_keys`, `~/.ssh/config`	sshd's `StrictModes` (on by default) rejects them if group or others can write
`.env`, `config/secrets.yml`	Database passwords and API keys
`~/.pgpass`, `~/.netrc`, `~/.my.cnf`	Client password files; `psql` ignores `.pgpass` unless it is 600 or stricter
TLS private keys	Readable only by the service that owns them
`crontab` spool files, mail spools	Per-user private data

A typical fix for SSH:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys ~/.ssh/config
chmod 644 ~/.ssh/id_ed25519.pub

The public key can stay readable; only the private half needs 600.

Ownership matters as much as mode

600 means "only the owner". If your web app runs as www-data and the .env file belongs to deploy with mode 600, the app can't read it and fails at startup. You have two clean options:

Make the service user the owner: chown www-data: .env and keep 600.
Keep your user as owner, give the service's group read access, and use chmod 640: chown deploy:www-data .env && chmod 640 .env.

Don't fix it with 644 or 666. That hands the secrets to every account on the machine.

Recursive pitfalls

chmod -R 600 ~/.ssh strips execute from the .ssh directory itself, and then SSH can't read anything in it. Set files and directories separately:

find ~/.ssh -type d -exec chmod 700 {} +
find ~/.ssh -type f -exec chmod 600 {} +

Making new files private by default

New files get their mode from the program's request (usually 666 for files) minus your umask. With the common umask 022, files come out 644. Run umask 077 in a script before it writes secrets, and every file it creates will be 600 (and directories 700). Tools like ssh-keygen already create private keys as 600 on their own.

Security notes

600 protects against other local users, not against code running as you. A compromised app that runs as the file's owner can read it. Keep secrets out of the web root as well: a 600 file inside public/ can't be read by the web server, but a 644 one by mistake can be downloaded by anyone.

chmod 400: owner can only read, not write.
chmod 640: owner read/write, group read.
chmod 700: the matching mode for private directories.
Port 22 (SSH): where the keys are used.

Check any mode in the chmod calculator.