DEV Community

dpm_bush
dpm_bush

Posted on Originally published at sshflow.com

chmod 600 Explained: Secure Files Without Breaking Directories

When OpenSSH refuses to use a private key because its permissions are too open, chmod 600 is often the fix. It gives the file’s owner read and write access while removing all permissions for the group and everyone else.

chmod 600 ~/.ssh/id_ed25519
Enter fullscreen mode Exit fullscreen mode

That mode is useful for private keys and other credentials—but it is not a universal permission setting. In particular, applying it to a directory removes the execute permission needed to enter or traverse it.

Reading the number 600

A three-digit chmod mode represents permissions for three classes, in order: owner, group, and others. Each digit adds up read (4), write (2), and execute (1) permissions.

Digit Class Permissions
6 Owner Read (4) + write (2)
0 Group None
0 Others None

So 600 corresponds to rw-------. The owner can read and change the file; other local users have no permission bits set. chmod 0600 has the same ordinary permission effect as chmod 600.

To check a file’s current mode, use:

ls -l ~/.ssh/id_ed25519
Enter fullscreen mode Exit fullscreen mode

A listing beginning with -rw------- indicates a regular file with mode 600. The initial - distinguishes a regular file from a directory, whose listing begins with d.

Why it helps with private SSH keys

A personal private key should not be accessible to other users on the machine. If a key is group- or world-readable, OpenSSH may warn that the private key file is unprotected and ignore it.

Set a restrictive mode on the actual key file:

chmod 600 ~/.ssh/id_ed25519
Enter fullscreen mode Exit fullscreen mode

The exact filename depends on the key you use. A personal RSA key might instead be at ~/.ssh/id_rsa.

The important rule is that group and others should have no access to a personal private key. 600 is a common choice because the owner can still update the file. 400 also restricts access to the owner, but makes the file read-only for that owner:

chmod 400 ~/.ssh/id_ed25519
Enter fullscreen mode Exit fullscreen mode

For a fuller breakdown of which permissions OpenSSH checks on SSH keys and related files, remember that fixing the key alone may not address permissions or ownership issues elsewhere in ~/.ssh.

Don’t use 600 on a directory

Files and directories use execute permission differently. On a file, execute allows it to run as a program. On a directory, execute allows traversal: entering it or reaching an item inside it by path.

This means chmod 600 is usually wrong for a directory. It leaves the owner with read and write, but no execute permission. Even the owner may then be unable to enter the directory or access its contents by path.

For a private directory such as ~/.ssh, use 700 instead:

chmod 700 ~/.ssh
Enter fullscreen mode Exit fullscreen mode

That grants the owner read, write, and execute access, while giving group and others none. Be especially careful with recursive permission changes: applying a file mode to every directory and file in a tree can make directories unusable. See how to apply recursive chmod changes without flattening file and directory permissions before changing an entire tree.

Other files that may need 600

The same owner-only read/write mode can make sense for files containing secrets, such as a project’s .env file:

chmod 600 .env
Enter fullscreen mode Exit fullscreen mode

It can also be appropriate for credential files such as .pgpass or .netrc when only the owning account should access them. Permissions are not encryption, though: 600 limits access through the file’s Unix permission bits; it does not encrypt the contents or protect against every privileged process or system-level access control.

A public SSH key is different from a private key. A .pub file is intended to be shared, so it does not need the same secrecy as the private key. Don’t apply private-key rules to every file just because it lives in ~/.ssh.

What about Windows?

On native Windows, file access is controlled through Windows ACLs, not simply Unix permission bits. Running chmod 600 in a Windows shell does not by itself guarantee that a key stored on an NTFS filesystem is restricted to your account. If native Windows OpenSSH rejects a key, check and adjust its ACLs rather than assuming the Unix mode secured it.

In short: use 600 for a personal secret file when its owner needs read/write access, use 400 when owner-only read access is enough, and use 700 for a private directory. The right mode depends on whether you are protecting a file or preserving directory traversal.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Top comments (0)