How BASIC knowledge helps us solve a ~2 million views question

You can check out the question here. It’s the problem with the SSH private key. The answer is at the end of the article, I have created links in the table of contents for you to navigate. However, to enjoy the “that makes sense” moment, I encourage you to walk through each part of the article.

Table of content

1. Introduction

2. Background knowledge - Encryption
   2.1 Definition
   2.2 Symmetric encryption
   2.3 Asymmetric encryption

3. Real-life examples of using SSH
   3.1 Using SSH with Git hosting service
   3.2 SSH configuration files

4. Answer the question

5. Wrap up

Introduction

To manipulate the remote server, we need a method that allows us to connect to them from our computer. SSH is one of those methods.

SSH is a method that helps us establish a secure connection to a remote server.

This connection allows us to work directly with the server’s shell. From there we can do all the tasks like we are doing with our machine.

In the next section, I would like to review some background knowledge before starting to talk about different use cases of this tool. This part will help us to understand the meaning of a config file or an error message. So that we can determine what we need to do even when copying someone’s magic commands from Google.

Background knowledge : Encryption

In the previous section, we mentioned security. SSH allows you to establish a secure connection. To do that, SSH uses different encryption algorithms.

Definition

You can find the classic full definition of encryption at this link. To keep it simple, I would like to use my version.

Encryption is expressing information in a form that cannot be understood unless we have the means to decode it.

There are 2 categories of encryption algorithms: symmetric encryption and asymmetric encryption.

Symmetric encryption

Symmetric encryption is a class of encryption algorithms in which the encryption and decryption phase share a single key (decryption is the reverse process of encryption). This key is a secret between the two parties in the conversation.

Symmetric encryption keeps the information exchanged confidentially. Only those with the key can decrypt the information.

Asymmetric encryption

In contrast to symmetric encryption, asymmetric encryption algorithms use 2 different keys to encrypt and decrypt information. Each person needs a key pair consisting of a public key and a private key. While the public key can be made public to everyone, the private key is private to each person and cannot be shared with anyone. When information is encrypted with one of the keys in a key pair, only the other key in the same pair can decrypt it.

(Notice the difference between a secret key and a private key. The private key cannot be shared. The secret key in symmetric encryption can be shared between the two parties.)

Asymmetric encryption also gives us the same security as symmetric encryption. If Alice encrypts the message with Bob’s public key, then only Bobs with his private key can decrypt the message.

In addition, it provides two extra possibilities that symmetric encryption does not:

• Allow us to identify who sent the information. (*)
• The person who sent the information cannot deny the action.

This is the case when Alice encrypts the message with her private key. Bob uses Alice’s public key to decrypt. If the decryption is successful, it proves that the message can only be sent from Alice. At the same time, Alice cannot deny that she sent this message. Because if it was sent by someone else, Bob couldn’t use the public key of Alice to decrypt.

The characteristic (*) is an important foundation for SSH because it helps the server identify who is connecting to the system. This allows the server to accept or reject the connection. Authentication using SSH does not require a password. Instead, each person will use his/her private key to connect to the server, and the server keeps track of the list of people who can connect (see authorized_keys in the next section). Comparing two authentication methods using password and using the private key, the latter is the winner because:

• Authentication with the private key tells us who accessed the system, and that person cannot deny the fact. In the first method, anyone who knows the password can connect to the system.
• By not using a password, authentication with a private key is more convenient. Each person in a group can use their private key to log into the common system instead of sharing a password. Password sharing in the workplace can expose the business to risks. Therefore, we should avoid shared passwords whenever possible.
• Private key authentication allows us to automate commands because the server shell does not prompt for the password.

Those are also the powers of SSH, and that’s why more and more systems move to this method. Now, we will talk about using SSH in practice.

Real-life examples of using SSH

Using SSH with Git hosting service

When working with Git hosting services like GitHub or GitLab, we can clone, push, pull a repository using HTTPS or SSH protocol.

If we use HTTPS, every time we push, pull … We need to enter the username and password.

If we use SSH, we need to give GitHub/GitLab our public key. Then, every time we push, pull, instead of having to enter the username and password, we just need to enter the password of the private key (passphrase). If we don’t use the passphrase, then we don’t need to type anything! GitHub uses the public key to verify who we are and check if we have permission to read/write the repository.

The second way is more convenient because we don’t have to manually type the username and passwords each time. If no passphrase is configured for the key, the push/pull command can be done by running a script. This allows us to automate the integration and deployment phase.

SSH configuration files

To configure SSH, we will work with the .ssh directory under the home directory. This is the directory where the important files to use the SSH protocol locate. They are authorized_keys, known_hosts, and config. Below, I would like to explain the meaning of each file:

• authorized_keys: This file contains a list of public keys that are allowed to access the system. When someone connects to the server, the message (encrypted with their private key) is decrypted by the public keys in this file. If the decryption is successful, the person is identified and is allowed to connect to the server.

So, if you want to access the servers using the SSH protocol, you just need to add your public key to this file. The same principle applied when AWS gives us a .ppk file to access the container.

• known_hosts: This file contains a list of public keys of remote servers that you have visited before. The information in the file helps the computer check the identity of the destination to make sure it is connecting to the right place, to avoid being redirected to a machine of a bad guy.
• config: This file contains SSH settings. When we use frequently one particular SSH connection, we can save the parameters of that connection to this file. Then, the SSH command can be shortened. For example, when you save the following text in the file ~/.ssh/config

Host alias  
   HostName hostname  
   User username  
   IdentityFile ~/.ssh/private_key

Then these 2 commands below will give the same result:

ssh alias
ssh username@hostname -i ~/.ssh/private_key

I use this config file to set up a second GitLab account. You can see the tutorial here.

Answer the question

Let’s go back to the question at the beginning. When the private key is not secured, you will see a message like this.

This is a common mistake when the private key is not protected as it should. In the theory section, we said that the private key is private to each person and is not shared with anyone. In this case, the key has a permission of 644, which means that the contents of the key can be read by anyone. That violates the principle of the private key and leads to the error.

The problem is clear, we need to limit the permission of the file. We can use the permission of read-only or read-write by the owner. And the magic command is:

chmod 400 ~/.ssh/[[PRIVATE KEY]]or chmod 600 ~/.ssh/[[PRIVATE KEY]]

Done!

Wrap up

SSH is a protocol that we use daily at work. At first, I blindly copied and pasted the commands I found from Stack Overflow and hope it will work. But I did not understand why. When I had to configure more complex cases or recently worked with GitLab CI/CD, I was very confused. After revising the basics, I better understand SSH now. Through this post, I hope we can see the close relationship between basic knowledge and practical usage and feel more confident when dealing with issues.

Resources

• https://stackoverflow.com/questions/9270734/ssh-permissions-are-too-open-error
• https://en.wikipedia.org/wiki/Encryption
• https://www.kratikal.com/blog/5-risks-of-password-sharing-at-work/
• https://www.keepersecurity.com/blog/2021/07/06/4-rules-for-safe-password-sharing-in-the-workplace/
• https://medium.com/uncaught-exception/setting-up-multiple-gitlab-accounts-82b70e88c437

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

I look forward to connecting with other people to learn from your perspectives. If you’ve ever had those “That makes sense!” moments, you can also share them in the comment section. That will help us learn from each other. Thank you for reading!