The best experience for managing encryption keys on Linux

Guide storing SSH encryption keys and remembering passwords has always been a daunting problem. But unfortunately, in a world full of malicious hackers and attacks, basic security precautions are essential. For many ordinary users, most people can only remember the password, they may also find a good program to store the password, as we remind these users not to use the same password on each site.

But for people in every IT field, we need to raise this matter one level. We need to use encryption keys such as SSH keys, not just passwords.
Imagine a scenario: I have a server running on the cloud that serves as my main git repository. I have a lot of working computers, all of which need to log in to this central server to do push and pull operations. Here I set git to use SSH. When git uses ssh, git actually logs on to the server as SSH, as if you were to open a server command line through an SSH command. In order to set these up, I create a configuration file in my. SSH directory that contains a host item with information such as the server name, hostname, login user, key file path, and so on. I can then test the configuration correctly by entering the following command.

SSH Gitserver

Soon I'll be able to access the server's bash shell. Now I can configure git to log on to the server using the same configuration items and stored keys. This is simple, but there is a problem: For every computer I want to log into the server, I need a key file, which means that the key file needs to be put in many places. I'll store these key files on the current computer, and my other computers will need to store them. Just like those with a lot of passwords, our IT staff are overwhelmed by these very many key files. What do we do?

Clean up

Before we begin to help you manage the keys, you need to have some basic knowledge of how the keys should be used, and understand the meaning of the questions below. At the same time, there is a premise, but also the most important, you should know where your public key and private key should be put. Then assume you should know:

1. The difference between the public key and the private key;
2. Why can't you generate the private key from the public key, but vice versa?
3. The purpose of the Authorized_keys file and what it contains;
4. How to use the private key to log in to a server in the Authorized_keys file on which your corresponding public key is stored.

Here's an example. When you create a cloud server on Amazon's Web service, you must provide an SSH key to connect to your server. Each key has a public part (the public key) and a private part (the private key). If you want your server to be secure, at first glance you may need to put your private key on the server and you will have your own public key. After all, you don't want your server to be publicly accessible, right? But the practice is exactly the opposite.

You should put your own public key on the AWS server, and you hold the private key that is used to log on to the server. You need to protect the private key and put it in your control, not on some remote servers, as shown in.

The reasons are as follows: If the public key is known by others, they cannot be used to log on to the server because they do not have a private key. Further, if someone successfully hacked into your server, all they could find was the public key, and they could not generate the private key from the public key. Also, if you use the same public key on other servers, they can't use it to log on to another computer.

That's why you put your own public key on your server to log in to these servers via SSH. You hold these private keys and don't let these private keys out of your control.

But there's a little bit of trouble. Imagine my git server example. I need to make some choices. Sometimes I log on to a development server that is set up somewhere else, and on the development server I need to connect to my git server. How do I make my development server connect to a git server? Obviously by using the private key, but there is a problem. In this scenario, I need to place the private key on a server that is set up somewhere else, which is quite dangerous.

A further scenario: what if I want to use a key to log on to many servers? If an intruder gets the private key, the person can use the private key to get access to the entire server network, which can cause some serious damage, which is very bad.

At the same time, this also brings up another question, should I really use the same key on these other servers? Because I just described it, it would be very dangerous.

Finally, this may sound confusing, but there are some simple solutions. Let's organize it in a structured way.

(Note that in addition to logging in to the server, there are many places that require a private key key, but the scenario I'm proposing can show you the problem you're facing when you use the key.) ）

General Password

When you create your key, you can choose whether to include a password when the key is used. With this password, the private key file itself is encrypted by the password. For example, if you have a public key stored on the server and you use the private key to log on to the server, you will be prompted to enter the password. This key cannot be used without a password. Or you can configure your key without a password, and then just need the key file to log in to the server.

In general, it is more convenient for users to not use a password, but in many cases I strongly recommend using a password because if the private key file is stolen, the person stealing the key will still not be able to use it unless he or she can find the password. In theory, this will save you a lot of time, because you can protect your system by removing the public key file from the server before the attacker discovers the password. Of course there are other reasons to use the password, but on many occasions this reason is more valuable to me. (For example, I have VNC software on my Android tablet.) There's my key on the tablet. If my tablet is stolen, I will immediately remove the public key from the server so that its private key has no effect, regardless of the password. But in some cases I don't use passwords because there is no valuable data on the server that I'm logging on to, depending on the situation.

Server Infrastructure

How you design your own server infrastructure will affect how you manage your keys. For example, if you have many users logged in, you will need to decide whether each user needs a separate key. (in general, this should be true; you don't want to share the private key between users.) That way, when a user leaves the organization or loses trust, you can delete the user's public key without having to give the other person a new key. Similarly, by sharing the key, they can log in as someone else, which is even worse. But another question is how you configure your server. For example, do you use a tool like Puppet to configure a large number of servers? Do you create a large number of servers based on your own image? When you copy your server, are each key the same? Different cloud Server software allows you to configure how to choose, you can either use the same key for these servers, or you can generate a new key for each server.

If you are operating these replicated servers, it can cause confusion if users need to log on to two different systems with different keys, but most of them are the same. On the other hand, however, it is a security risk for the server to share the same key. or, thirdly, if your key has a need other than login (such as mounting an encrypted driver), you will need the same key in many places. As you can see, whether you need to use the same keys on different servers is not the decision I could make for you; there are tradeoffs, and you need to decide for yourself what is best.

In the end, you may have:

1. Multiple servers that need to be logged on
2. Multiple users log on to different servers, each with their own keys
3. Each user logs on to a different server with multiple keys

(If you are using keys in other situations, the same pervasive theory can be applied to how keys are used, how many keys are needed, whether they are shared, how you handle public-private keys, and so on.) ）

Security Methods

To understand your infrastructure and unique situations, you need to combine a key management scheme that will guide you how to distribute and store your keys. For example, as I mentioned earlier, if my tablet was stolen, I would remove the public key from my server and I hope this will be done before the tablet is used to access the server. In the same way, I will consider the following in my overall plan:

1. The private key can be placed on a mobile device, but must contain a password;
2. There must be a way to quickly remove the public key from the server.

In your case, you may decide that you do not want to use a password on a system that you frequently log on to, for example, the system may be a test machine that a developer logs on multiple times a day. It's no problem, but you need to adjust your rules a little bit. You can add a rule: You can't log on to the machine from a mobile device. In other words, you need to build your criteria according to your own situation, and don't assume that a scenario is universal.

Software

As for software, surprisingly, there are no good, reliable software solutions for storing and managing private keys in the real world. But should there be? Considering this, if you have a program that stores all the keys for all your servers, and the program is locked by a quick key, is your key really safe? Or similarly, if your key is placed on your hard drive for quick access to the SSH program, does the key management software really provide any protection?

However, there are many solutions for the overall infrastructure and the creation/management of public keys. I've already mentioned Puppet, in the world of Puppet, you can create modules to manage your servers in different ways. The idea is that the server is dynamic and does not need to replicate to each other accurately. Here's a smart way to use the same key on different servers, but for each user, use a different Puppet module. This scheme may or may not be suitable for you.

Alternatively, another option would be to completely change gears. In the world of Docker, you can take a different approach, as described in the SSH and Docker blogs.

But how do you manage the private key? If you have searched, you can't find a lot of software to choose from, for reasons I mentioned before; the private key is stored on your hard drive, and a management software may not be able to mention additional security. But I use this method to manage my keys:

First of all, there are many host entries in my. ssh/config file. I have a host item to log on to, but sometimes I have more than one item for a single host. This can happen if I have a lot of login options. I have two different logins for the server that placed my git library, one for Git, and another for general purpose bash access. This login option set for Git has a huge limit on the machine. Remember what I said earlier about my git key stored on a remote development machine? All right. Although these keys can be logged into one of my servers, the accounts used are strictly limited.

Second, most of the private keys contain passwords. (Consider using ssh-agent for situations where you need to enter the password multiple times.) ）

Again, I have some servers I want to protect more carefully, and I will not put these host items in my host file. This is closer to social engineering, where key files are still available, but it may take longer for an attacker to find the key file and analyze the corresponding machine. In this case, I need to manually punch out a long SSH command. (not so scary.) ）

At the same time you can see that I have not used any special software to manage these private keys.

Occasionally we get some questions at Linux.com, asking for advice on good software for managing keys. But to take a step back, the problem actually needs rethinking because there is no universal solution. The question you are asking should be based on your own situation. Are you simply trying to find a location to store your key file? Are you looking for a way to manage multi-user issues where everyone needs to insert their own public key into the Authorized_keys file?

Through this article, I have covered this basic knowledge, hope that you understand how to manage your key, and only when you ask the right question, whether you look for any software (even if you need additional software), it will appear.

Free to provide the latest Linux technology tutorials Books, for open-source technology enthusiasts to do more and better: http://www.linuxprobe.com/

The best experience for managing encryption keys on Linux