Yunfi

Yunfi

tg_channel
github
email
HomeArchives

Solution for the UNPROTECTED PRIVATE KEY FILE issue in ssh.

#ssh151
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. It explains that the permissions of the private key file should not allow access by others. 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 correcting the permissions of the private key file. It emphasizes the importance of securing the private key file and mentions that the permissions of the public key file should also be considered. Overall, the article highlights the significance of maintaining proper permissions for SSH keys to ensure security.

title: Solution to the UNPROTECTED PRIVATE KEY FILE issue in ssh
tags:

  • ssh
    category:
  • Troubleshooting
    date: 2023-07-01
    toc: true
    cover: /img/ssh-unprotected-private-key.webp
    plink: ssh-unprotected-private-key

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 was being used in Windows to WSL. I simply copied it over using the file explorer. However, this method resulted in the file permissions being set to 0644, which means that any user can read the file and only the owner can modify it. These insecure permissions caused sshd to reject the private key, resulting in the inability to ssh into a VPS or perform git operations. The solution is simple: change the permissions.

Complete Solution#

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 SSH key permissions. First, we generate keys and configure them for access by a given user. Next, we discuss the appropriate 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 environments that comply with the POSIX standard.

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 simply 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 indicating that 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 error message we saw earlier, the requirement is that our private key file "is not 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 permissions
  • 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 by using the -l option or 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, we may 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 the local copies of keys from modifications by third parties. Essentially, this means that the recommended modes fall between two extremes:

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

Regardless, once our public key is in the authorized_keys file on the 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 SSH key permissions and the problems they can cause, as well as how to correct them.

In summary, the SSH client 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.