SSH Key Permissions: When to Use chmod 600 or 700

Use chmod 600 for a private SSH key when its owner needs read and write access, and use chmod 700 for the .ssh directory so only the owner can list, change, or enter it. OpenSSH rejects private keys that other users can access. Check ownership as well as mode, because chmod cannot fix a key owned by the wrong account. The SSH-permissions lesson provides safe practice paths before you change a real key.

For a private Ed25519 key in your home directory, run:

chmod 600 "$HOME/.ssh/id_ed25519"

Mode 600 means:

SSH needs to read the private key, but other accounts should not. A read-only mode such as 400 can also satisfy that access rule when the owner does not need to modify the file. 600 is the common practical choice for a key managed by its owner.

Do not apply the same rule blindly to the public key ending in .pub. A public key is designed to be shared and is not secret. The private key is the sensitive file that OpenSSH refuses to use when it is accessible by others.

Directories need execute, also called search, permission to access entries inside them. Protect the directory with:

chmod 700 "$HOME/.ssh"

Mode 700 gives the owner read, write, and search access while granting no access to the group or other users. Using 600 on a directory would remove its search bit, which can prevent the owner from opening files inside even though the directory is readable.

Avoid a recursive shortcut such as chmod -R 700 "$HOME/.ssh". It would add execute permission to every regular file and erase intentional differences between private keys, public keys, configuration, and known-host files. Change the directory and the specific private key separately.

Inspect both paths after changing them:

ls -ld "$HOME/.ssh"
ls -l "$HOME/.ssh/id_ed25519"

The directory should begin with drwx------, and the private key should begin with -rw-------. The owner shown in both rows should be the account that runs ssh.

If the mode is correct but the owner is not, investigate before changing it. On a personal system, the intended repair may look like this:

sudo chown "$USER" "$HOME/.ssh/id_ed25519"

Do not copy that command onto a shared or managed system without confirming its account policy. The chown guide explains ownership checks and recursive risks separately.

Files stored on Windows-mounted, network, container, or otherwise managed filesystems may not expose Unix permission bits normally. If chmod reports success but ls -l shows no useful change, check the mount and filesystem semantics instead of repeatedly widening access.

Use ssh -v host to inspect which identity file SSH attempts, but do not paste verbose logs publicly without removing hostnames, usernames, and paths. A correct mode on one key does not help if SSH is loading a different file.

For the underlying octal system, read chmod numbers explained. OpenSSH documents its private-key access checks in the ssh manual.