SSH Error “permissions are too open” for Private Key File

1. Introduction

Keys are part of the Secure Shell (SSH) protocol. In fact, if used correctly, they provide an extra layer of protection.

In this tutorial, we explore permissions problems with SSH keys. First, we generate keys and configure them for access via a given user. Next, we discuss appropriate key permissions. Finally, we explain how to correct a key’s permissions and test the result.

For brevity and security reasons, we only consider the newest iteration of SSH version 2 (SSHv2) as implemented by OpenSSH.

We tested the code in this tutorial on Debian 11 (Bullseye) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments.

2. Key Generation

To start, let’s generate some keys with their defaults:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/baeldung/.ssh/id_rsa):
Created directory '/home/baeldung/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/baeldung/.ssh/id_rsa
Your public key has been saved in /home/baeldung/.ssh/id_rsa.pub
The key fingerprint is:
[...]

At this point, as the output states, we have one set of two keys:

• public key: /home/baeldung/.ssh/id_rsa.pub
• private key: /home/baeldung/.ssh/id_rsa

Importantly, these are default locations based on the home (/home) directory of the user (baeldung): $HOME.

For the sake of simplicity, we use the local machine as the client and server of the SSH session. So, we add the public key to the authorized_keys file for our user:

$ cat /home/baeldung/.ssh/id_rsa.pub >> /home/baeldung/.ssh/authorized_keys

Now, let’s put our new keys to use.

3. Private Key Permissions

After creating and setting up the keys, we just connect to localhost:

$ ssh localhost
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/root/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/root/.ssh/id_rsa": bad permissions
[...]

In this case, we encounter an error, which states our private key has the wrong permissions. Specifically, the SSH client does not allow the use of private keys accessible by others.

Let’s check our private key’s current permissions via ls:

$ ls -l /home/baeldung/.ssh/id_rsa
-rwxrwxrwx 1 baeldung baeldung 2590 Oct 10 06:56 /home/baeldung/.ssh/id_rsa

Here, the third and fourth columns tell us that baeldung is the name of both the owning user and group. The first column tells us that the owning user, members of the owning group, and everyone else all have full permissions to our private key file at /home/baeldung/.ssh/id_rsa, e.g., mode 0777.

If we’re after proper security, this is not acceptable.

4. Correcting Private Key Permissions

As the error text we saw earlier explains, the requirement is that our private key files are NOT accessible by others. In other words, we are to set a mode for each private key file between two extremes:

• 0400, the most restrictive, e.g., only read permissions to the owning user
• 0700, the least restrictive, e.g., only full permissions to the owning user

Essentially, we must not provide any permissions to any user that is not the owner, but the owner must still be able to at least read the files. In this case, we use chmod to apply the most restrictive access:

$ chmod 0400 /home/baeldung/.ssh/id_rsa
$ ssh localhost
[...]
baeldung $ 

Finally, let’s see what happens when we change the owner via chown:

$ chown user1:user1 /home/baeldung/.ssh/id_rsa
$ ls -l /home/baeldung/.ssh/id_rsa
-r-------- 1 user1 user1 2590 Oct 10 06:56 /home/baeldung/.ssh/id_rsa

At this point, if we are a superuser, SSH would allow us to continue because of several facts:

• as a superuser, we have permission over all files
• the file permissions are actually accurate as far as the SSH client is concerned (0400)

Indeed, as root, we’d only have to specify the correct user via -l or with the user@ syntax, as well as the key after an -i flag, and we’d be set.

5. Public Key Permissions

As a sidebar to the main problem of private keys, we might ask whether any of these permission requirements apply to public keys as well. In fact, there are recommendations but no universal rules.

In most scenarios, it’s best to protect the local copy of the key from modification by third parties. Essentially, this means a suggested mode between two extremes:

• 0400, which, as before, allows the owner alone to only read the key
• 0744, which enables the owner to

Effectively, the lower bound enables manipulation without modification and locks out external users, while the upper bound at least prevents external modification.

In any case, once our public key is in the authorized_keys file of a remote machine, we don’t really need it to log in – we only need the private key.

6. Summary

In this article, we looked at SSH key permissions, problems they may cause, and how to correct them.

In conclusion, SSH clients can and should define strict rules for storing and using private keys, as they can be considered equivalent to passwords.