ThisCalculator

Everyday

SSH Key Permissions: Files and Access Rights to Check

Updated · Standard formula, shown below

SSH Key Permissions: Files and Access Rights to Check

To keep SSH key authentication working, the key files themselves must be private to your user, and the directories that contain them must not be writable by anyone else. Specifically, check that your private key (e.g., ~/.ssh/id_rsa) has permissions 600 (owner read/write only) and that the .ssh directory has 700 (owner read/write/execute only). This article explains exactly which files to inspect, what access rights are required, and how to fix common permission problems on Linux, macOS, and Windows.

Why SSH Key Permissions Matter

SSH uses public-key cryptography to authenticate you to a server. Your private key is the secret half of that pair—anyone who can read it can impersonate you on any system that trusts the corresponding public key. If your private key is world-readable, another user on the same machine could copy it and gain access to your accounts. Even if no one else is on the machine, SSH itself is strict: if the key file or its parent directory has overly permissive settings, the client refuses to use the key and falls back to password authentication (or fails entirely). This strictness is a deliberate safety feature, not a bug.

Which Files Should You Check?

When you run ssh, it reads configuration and keys from your user’s .ssh directory (usually ~/.ssh). The critical files to check are:

  • Private key files (e.g., id_rsa, id_ed25519, id_ecdsa) – these must be readable and writable only by you.
  • Public key files (e.g., id_rsa.pub) – these are not secret; they can be world-readable, but typical practice is to keep them 644.
  • The .ssh directory itself – it must not be writable by group or others.
  • Your home directory – on many systems, if the home directory is group-writable, SSH may reject the key.
  • Authorized keys file on the server (~/.ssh/authorized_keys) – this file controls who can log in; it should be owned by the target user and not writable by others.

Additionally, if you use a config file (~/.ssh/config), it should be 600 or 644—it may contain host aliases but rarely secrets, so 644 is acceptable.

Required Permission Values (and What They Mean)

Permissions in Unix are expressed as three digits: owner, group, and others. Each digit is the sum of read (4), write (2), and execute (1). For SSH key security, the recommended values are:

  • ~/.ssh directory: 700 (owner can read, write, and list; no one else can access).
  • Private key file: 600 (owner can read and write; no one else can read).
  • Public key file: 644 (owner read/write, others read-only) – safe because it’s public.
  • Home directory: 755 or 700 – the key point is that it must not be writable by group or others.

On macOS and Linux, you can check current permissions with ls -l ~/.ssh and fix them with chmod. For example:

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

If your home directory is group-writable (e.g., drwxrwxr-x), you may need chmod go-w ~ to remove write access for group and others.

How to Check and Fix on Linux/macOS

Here’s a step-by-step process to verify and correct permissions:

  1. Open a terminal.
  2. Run ls -ld ~ to see your home directory permissions. If the second-to-last character is w (group write) or the last is w (other write), fix with chmod go-w ~.
  3. Run ls -ld ~/.ssh – it should show drwx------ (700). If not, run chmod 700 ~/.ssh.
  4. Run ls -l ~/.ssh – list all files. For each private key (no .pub suffix), ensure it shows -rw------- (600). If not, run chmod 600 ~/.ssh/id_ed25519 (replace with your key name).
  5. For public keys, -rw-r--r-- (644) is fine; if they are more permissive, run chmod 644 ~/.ssh/*.pub.

After fixing, test with ssh -v user@host – the verbose output will show whether the key is accepted or rejected due to permissions.

Windows (OpenSSH) and WSL

On Windows 10/11 with the built-in OpenSSH client, the rules are similar but the file locations differ. Keys are typically in C:\Users\YourName\.ssh\. The client enforces the same Unix-style permissions when running in PowerShell or Command Prompt. To fix permissions, you can use icacls to reset ACLs:

icacls "C:\Users\YourName\.ssh\id_ed25519" /inheritance:r /grant:r "%USERNAME%":R

This removes inherited permissions and gives only your user read access. For the .ssh folder, use icacls ... /grant:r "%USERNAME%":F (full control) but remove other users. If you use WSL (Windows Subsystem for Linux), the Linux permissions apply inside the WSL filesystem, and you can use chmod as described above.

Common Permission-Related Errors and Fixes

When permissions are wrong, you may see errors like:

  • Permissions 0644 for 'id_rsa' are too open. – This is the most common. Fix with chmod 600.
  • Bad owner or permissions on ~/.ssh/config – The config file must be owned by you and not writable by others; use chmod 600 ~/.ssh/config.
  • Warning: unprotected private key file – same as “too openâ€�.
  • Permission denied (publickey) – This can be due to server-side authorized_keys permissions, not just local. On the server, ensure ~/.ssh is 700 and authorized_keys is 600.

If you’ve fixed local permissions but still get “Permission denied�, check the server’s authorized_keys file ownership and permissions. The file must be owned by the target user and not writable by others. Also verify that the home directory on the server is not group-writable.

Why SSH Is So Strict (and When You Can Relax)

SSH’s strictness is a security measure to prevent “Trojan horse� attacks: if a directory or file is writable by others, an attacker could replace your key with their own and hijack your connection. The check is done by the client before sending the key. On some systems, you can override the check with ssh -o StrictModes=no, but this is strongly discouraged because it disables a safety net. The only time you might relax permissions is for public keys (they are meant to be shared) or on a single-user machine where no other accounts exist—but even then, keeping the standard permissions is good practice.

Frequently Asked Questions

What is the exact permission for .ssh folder?

The .ssh directory should be 700 (drwx——). This gives you full access and denies everyone else any access, including listing the directory contents.

Can I use 644 for private key?

No. A private key with 644 is world-readable, which defeats the purpose. SSH will refuse to use it with a “too open� error. Always use 600 for private keys.

Do I need to check permissions on public key?

Public keys are not secret, so 644 is fine. However, if the public key is in a directory with strict permissions, it will still work because the directory’s permissions are what matter for access.

What if my home directory is group-writable?

SSH may reject your key because a group-writable home directory could allow others to modify your .ssh contents. Fix with chmod go-w ~ (remove write for group and others).

Why does SSH say “Permissions 0777 are too open� even after chmod?

If you’re on a filesystem that doesn’t support Unix permissions (like some mounted Windows drives), chmod may not work as expected. Move your keys to a native Linux filesystem (e.g., ~/.ssh in your home directory) and set permissions there.

Does the authorized_keys file on the server need specific permissions?

Yes. On the server, ~/.ssh should be 700 and ~/.ssh/authorized_keys should be 600. The file must be owned by the user who is logging in, and the home directory must not be writable by others.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.