Yunfi

Yunfi

tg_channel
github
email
HomeArchives

Resolution of the UNPROTECTED PRIVATE KEY FILE issue in ssh

#ssh203
AI Translation
This post is translated from Chinese into English through AI.View Original
AI-generated summary
The article discusses the issue of an unprotected private key file in SSH and provides a solution to fix it. The problem arises when the permissions of the private key file are too open, allowing access to other users. The solution is to change the permissions of the file to 0700. The article also provides a step-by-step guide on generating SSH keys and discusses the importance of proper permissions for both private and public keys. It emphasizes the need for strict rules and security measures when handling private keys, as they are equivalent to passwords.

TL;DR#

Issue#

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/chris/.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 "/home/chris/.ssh/id_rsa": bad permissions

Unable to use the ssh private key with the above warning message.

Solution#

chmod 0700 ~/.ssh/id_rsa

Replace the path with your own private key path.

Background#

After reinstalling WSL, I wanted to transfer the ssh key that Windows was using to WSL, so I simply copied it over in File Explorer. However, this method resulted in the file permissions being set to 0644, which means that any user can view it and only the owner can modify it. These insecure permissions would cause sshd to refuse to use this private key, resulting in incomplete ssh connections to VPS and git operations. The solution is simple: just change the permissions.

Complete Method#

The following content is from SSH Error “permissions are too open” for Private Key File by Hiks Gerganov, translated into Chinese by me and ChatGPT.

1. Introduction#

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

In this tutorial, we will explore the issue of permissions for SSH keys. First, we generate keys and configure them for access by a given user. Next, we discuss the proper key permissions. Finally, we explain how to correct the permissions of the keys and test the results.

For the sake of brevity and security, we will only consider the latest iteration of SSH version 2 (SSHv2) 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. Generating Keys#

First, let's generate some keys with the default settings:

$ 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 a pair of two keys:

  • Public key: /home/baeldung/.ssh/id_rsa.pub
  • Private key: /home/baeldung/.ssh/id_rsa

It is important to note that these are the default locations based on the user (baeldung) and the home directory (/home) - $HOME.

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

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

Now, let's use our new keys.

3. Private Key Permissions#

After creating and setting up the keys, we just need to 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 that indicates our private key has incorrect permissions. Specifically, the SSH client does not allow the use of a private key that can be accessed by others.

We use the ls command to check the current permissions of the private key:

$ 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 the username and group name of the owner (baeldung). The first column tells us that the owner, members of the owner's group, and all other users have full permissions on our private key file /home/baeldung/.ssh/id_rsa, with the mode set to 0777.

If we aim for proper security, this is unacceptable.

4. Correcting Private Key Permissions#

As explained in the previous error message, the requirement is that our private key file should "not be accessible by others". In other words, we need to set the mode of each private key file between two extremes:

  • 0400, the most strict, allowing only the owner read permission, for example
  • 0700, the least strict, allowing only the owner full permissions

Essentially, we should not provide any permissions to any non-owner users, but the owner should still be able to at least read these files. In this case, we use the chmod command to apply the most strict access permissions:

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

Finally, let's see what happens when we change the owner using the chown command:

$ 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 root, SSH will allow us to proceed because of the following facts:

  • As root, we have permissions for all files
  • As far as the SSH client is concerned, the file permissions are actually accurate (0400)

In fact, as root, we only need to specify the correct user either through the -l option or using the user@ syntax, and specify the key using the -i flag to complete the setup.

5. Public Key Permissions#

As a side note to the main issue of private keys, one might wonder if the same permissions requirements apply to public keys as well. In reality, there are recommendations but no universal rules.

In most cases, it is best to protect local copies of keys from modifications by third parties. Essentially, this means that the recommended modes fall between the two extremes:

  • 0400, same as before, allowing only the owner to read the key
  • 0744, allowing the owner to operate without modification and preventing external users, at least

However, once our public key is in the authorized_keys file on a remote machine, we don't actually need it to log in - we only need the private key.

6. Summary#

This article covered the issue of permissions for SSH keys, the problems they can cause, and how to correct them.

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

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.