SSH File Permissions: Correct Modes for Keys and Config (2026)

SSH keys and configuration files require specific permissions to prevent unauthorized access and ensure secure operation.

Let’s see how this plays out in practice. Imagine you’ve just generated a new SSH key pair and are trying to use it to connect to a remote server.

# On your local machine:
ssh -i ~/.ssh/my_new_key user@remote.example.com

If your key file has overly permissive read/write access, the ssh client will refuse to use it, spitting out an error like:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/my_new_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key file should only be accessible by you.
...

This is SSH’s way of saying, "Hey, I can’t trust this key because anyone could have messed with it." The same principle applies to your ~/.ssh/config file and your ~/.ssh directory itself.

The ~/.ssh Directory

This directory is the central hub for all your SSH client-side configurations and credentials. Because it houses sensitive information, its permissions are critical.

Diagnosis: Check the permissions of your SSH directory:

ls -ld ~/.ssh

Common Causes & Fixes:

1. Too Broad Permissions (e.g., 755, 777): If ls -ld ~/.ssh shows something like drwxr-xr-x or drwxrwxrwx, it means group members or even the world can list its contents.

   • Fix: Restrict permissions to only your user:

     chmod 700 ~/.ssh
     

   • Why it works: 700 (octal) translates to rwx------. Only the owner (u) has read, write, and execute permissions. The x permission on a directory is necessary to cd into it or access its contents.

2. Ownership Issues: While less common for a user’s own .ssh directory, if it was created by root or another user, you might have issues.

   • Diagnosis: ls -ld ~/.ssh will show the owner and group.
   • Fix: Ensure you own the directory:

     sudo chown $(whoami):$(whoami) ~/.ssh
     

   • Why it works: This command changes the owner and group of the .ssh directory to your current user, ensuring you have control over its permissions.

SSH Private Key Files

These are the files containing your secret key (e.g., id_rsa, id_ed25519, my_new_key). They are the digital equivalent of your passport and are therefore highly sensitive.

Diagnosis: Check the permissions of your private key:

ls -l ~/.ssh/my_private_key

Common Causes & Fixes:

1. Group or World Readable (e.g., 644, 664): This is the most frequent culprit, as seen in the initial warning.

   • Fix: Restrict permissions to only your user:

     chmod 600 ~/.ssh/my_private_key
     

   • Why it works: 600 (octal) translates to rw-------. Only the owner (u) has read and write permissions. This prevents anyone else on the system from reading your private key.

2. Executable Permissions (e.g., 700, 644): Private keys should never be executable.

   • Fix: Ensure no execute bits are set:

     chmod u=rw,go= ~/.ssh/my_private_key
     # or more commonly, if you know it's already 6xx:
     chmod 600 ~/.ssh/my_private_key
     

   • Why it works: Removing the execute bit (x) ensures the file cannot be run as a program, which is irrelevant for a key file and adds a layer of safety.

3. Ownership Issues: Similar to the directory, if the key file is owned by another user.

   • Diagnosis: ls -l ~/.ssh/my_private_key will show the owner and group.
   • Fix: Ensure you own the key file:

     sudo chown $(whoami):$(whoami) ~/.ssh/my_private_key
     

   • Why it works: This grants your user ownership and control over the key file’s permissions.

SSH Public Key Files

These files (e.g., id_rsa.pub, id_ed25519.pub) contain your public key. They are designed to be shared, so their permissions are less strict but still important for consistency.

Diagnosis: Check the permissions of your public key:

ls -l ~/.ssh/my_public_key.pub

Common Causes & Fixes:

1. Too Restrictive Permissions: While less likely to cause an immediate error, if your public key is unreadable by you, you won’t be able to copy it to servers.

   • Fix: Ensure you can read it:

     chmod 644 ~/.ssh/my_public_key.pub
     

   • Why it works: 644 (octal) translates to rw-r--r--. The owner can read and write, while group members and others can only read. This is generally safe for public keys and allows tools like ssh-copy-id to function correctly.

2. Ownership Issues:

   • Diagnosis: ls -l ~/.ssh/my_public_key.pub will show the owner and group.
   • Fix: Ensure you own the public key file:

     sudo chown $(whoami):$(whoami) ~/.ssh/my_public_key.pub
     

   • Why it works: This ensures you have control over the file, allowing you to manage it or copy it as needed.

SSH Config File (~/.ssh/config)

This file contains directives for how your ssh client should behave, including host-specific settings, aliases, and which keys to use for which hosts. It can contain sensitive information like usernames or specific ports, though not the keys themselves.

Diagnosis: Check the permissions of your SSH config file:

ls -l ~/.ssh/config

Common Causes & Fixes:

1. Group or World Readable (e.g., 644, 666): If others can read your config, they might glean useful information about your server access.

   • Fix: Restrict permissions to only your user:

     chmod 600 ~/.ssh/config
     

   • Why it works: 600 (octal) means only the owner can read and write. This prevents other users on the system from seeing your SSH configurations.

2. Ownership Issues:

   • Diagnosis: ls -l ~/.ssh/config will show the owner and group.
   • Fix: Ensure you own the config file:

     sudo chown $(whoami):$(whoami) ~/.ssh/config
     

   • Why it works: This grants your user ownership and control over the config file.

The known_hosts File (~/.ssh/known_hosts)

This file stores the public host keys of servers you’ve connected to. It’s used to detect man-in-the-middle attacks.

Diagnosis: Check the permissions of your known_hosts file:

ls -l ~/.ssh/known_hosts

Common Causes & Fixes:

1. Too Broad Permissions (e.g., 644, 666): While less critical than private keys, overly permissive settings can still be a minor risk if someone could tamper with the list and potentially facilitate a MITM attack by removing a host you previously verified.

   • Fix: Ensure only you can modify it, but others can read it:

     chmod 644 ~/.ssh/known_hosts
     

   • Why it works: 644 (octal) allows the owner to read/write and others to read. This is standard for files that might be referenced by other processes but shouldn’t be modified by them.

2. Ownership Issues:

   • Diagnosis: ls -l ~/.ssh/known_hosts will show the owner and group.
   • Fix: Ensure you own the known_hosts file:

     sudo chown $(whoami):$(whoami) ~/.ssh/known_hosts
     

   • Why it works: This ensures you have control over the list of known hosts.

Summary of Recommended Permissions:

• ~/.ssh directory: 700 (drwx------)
• Private key files (e.g., id_rsa): 600 (-rw-------)
• Public key files (e.g., id_rsa.pub): 644 (-rw-r–r–)
• ~/.ssh/config: 600 (-rw-------)
• ~/.ssh/known_hosts: 644 (-rw-r–r–)

After ensuring these permissions are set correctly, the next potential issue you might encounter is a "ProxyCommand" misconfiguration in your ~/.ssh/config file, leading to connection timeouts or unexpected error messages about invalid options.