In Linux, how does one manage the encryption key best?

In Linux, how does one manage the encryption key best?

Storing SSH encryption keys and remembering passwords can be a headache. Unfortunately, in today's years When malicious hackers and vulnerabilities are rampant, it is essential to take basic security measures. For many common users, this means that they only remember the password and may need to find an excellent software that stores the password, because we remind ordinary users not to use the same password for every website. But for those of us who are engaged in different IT industries, we need to go further on this basis. We also need to process encryption keys such as SSH keys, not just passwords.

One scenario is as follows: I run a server on the cloud for my master git software library. I have many public computers. All those computers need to log on to the central server to push and obtain content. I set git to use SSH. When git uses SSH, The way git logs on to the server is actually the same as starting the command line and using SSH commands to access the server. To configure everything, I created a configuration file in the. ssh Directory, which contains the Host item that provides the server name, Host name, login user, and key file path. Then, I can test the configuration by entering the following command:

Ssh gitserver

Soon I saw the bash shell of the server. Now, I can configure git and use the same item to log in with the stored key. It is quite easy, except for one problem: for every computer used to log on to that server, I need a key file. This means there will be more than one key file. I have several such keys on this computer and several on other computers. Just as there are countless passwords for common users, our IT staff will easily have countless key files in the end. How can this be done?

Clear mess

Before you start using a software to help manage keys, you have to do some basic work to find out how to handle keys and whether the questions we asked are reasonable. First, you need to know where your public key is and where your private key is. Suppose you already know the following:

1. Differences between public and private keys

2. Why can't I use the public key to generate a private key.

3. Use the authorized_keys file and where it is stored.

4. How do you use the private key to log on to the server with the corresponding public key in the authorized_keys file.

Here is an example. When you create an ECS instance on the Amazon Web Service (AWS) platform, you must provide an SSH key to connect to your server. Each key has a public part and a private part. Because you want your server to be secure, at first glance, you seem to put the private key on that server and bring the Public Key together. After all, you don't want that server to be publicly accessible, do you? But the opposite is true.

Keep the private key and place it around, instead of on a remote server.

You place the public key on the AWS server and keep the private key used to log on to the server. Keep the private key and place it around you, rather than on a remote server, as shown in.

The reason is: even if the public key is known to others, they cannot log on to the server because they do not have the private key. In addition, if someone does try to break into your server, all they find is the public key. You cannot use the public key to generate a private key. Therefore, if you use the same key on other servers, they cannot use this key to log on to other computers.

This is why you put the public key on your server to log on to the server through SSH. The private key is your private key. You are not allowed to put those private keys in others' hands.

But there is still a problem. Take my git server as an example. I have to make several decisions. Sometimes, I log on to a development server hosted elsewhere. On that development server, I need to connect to my git server. How can the development server connect to the git server? Use the private key. The problem exists here. In this scenario, I need to place the private key on a server hosted elsewhere. This may be dangerous.

Now let's look at another scenario: What if I use a single key to log on to multiple servers? If the intruder tries to get such a private key, the hacker can access the virtual network of the entire server after having the private key and prepare for some serious damage. This is not a good thing.

Of course, this raises another question: Should I use the same key for other servers? As I described earlier, this may be dangerous.

Finally, it sounds like a mess, but there are some simple solutions. One by one.

(Note: In addition to logging on to the server only, there are many places to use keys. However, I will introduce this scenario to show you the problems you are facing when processing keys .)

Pay attention to traffic codes

You can add a passphrase when creating a private key. With this pass code, the private key file uses the pass code to encrypt it. For example, if you store the public key on the server and log on to the server with the private key, you will see a prompt for entering the pass code. The key cannot be used without a pass code. In addition, you can configure the private key without a pass code at the beginning. In this way, you only need to log on to the key file on the server.

It is usually easier for users to use a pass code, but I strongly recommend that you use it in many cases. One reason is that if the private key file is stolen, the person who steals the file still cannot use it unless he can identify the pass code. Theoretically, this can win you time, because you can delete the public key from the server before the attacker detects the Traffic Code, thus protecting the system. There are other reasons to use the pass code, but it is worth using in many cases. (For example, I installed VNC software on an Android tablet. The tablet has my private key. If the tablet is stolen, I can immediately log on to the server from the tablet to abolish the public key, making the private key useless. It doesn't matter if there is any access code .) However, in some cases, I do not use a pass code, because the server I log on to may not have much valuable data on it. This depends on the specific situation.

Server infrastructure

How you design server infrastructure affects how keys are managed. For example, if you have multiple users to log on, you need to determine whether each user has a separate key. (Generally, they should obtain separate keys; you do not want users to share private keys. In this way, if a user leaves the enterprise or loses trust, you can abolish the user's key without generating a new key for each other. Similarly, if shared keys are used, they can log in as each other, which is equally bad .) But another problem is how to allocate servers. For example, do you use a certain tool (such as Puppet) to allocate many servers? Are multiple servers created based on their own images? If you copy a server, do you need the same key for each server? Different ECs software allows you to configure this aspect, depending on how you choose. Allows the server to obtain the same key or generate a new key for each server.

If you are dealing with a replication server, it will be confusing if you need to use different keys to log on to two different servers with similar other features. On the other hand, there is a security risk for several servers to share the same key. Or, if your password needs to be used outside of login (such as mounting an encrypted drive), then you need the same key in multiple places. As you can see, whether you need to use the same key on different servers is not a decision that I can make for you; there are some places to choose, you have to decide what is the most appropriate.

Finally, you may have:

• You need to log on to multiple servers;

• Log on to multiple users on different servers. each user has its own key;

• Each user has an additional key to log on to different servers.

(If you use a key in other cases-you may say how to use the key, how much the key is required, whether the key is shared, and how you process the Public and Private parts of the key, the same basic concepts will still apply .)

Security Methods

Once you know your infrastructure and unique circumstances, you need to develop a key management solution to help you guide how to distribute and store keys. For example, if my tablet is stolen, I hope that the public key can be abolished from the server before the tablet is used to access the server. Because of this, I need to consider the following situations in the overall plan:

1. It does not matter if the private key is stored on a mobile device, but they must contain a pass code.

2. There must be a way to quickly abolish the public key from the server.

In your case, you may decide not to use a pass code for systems that frequently log on. For example, the system may be a testing machine that developers log on to many times a day. That's good, but then you need to adjust the rules slightly. You may want to add a rule that does not allow you to log on to the machine from a mobile device. In other words, you need to develop procedures based on your own situation, rather than taking it for granted that everything is available.

Software

Let's talk about the software. Strangely, there are not many good and reliable software solutions to store and manage your private keys. Consider this: if there is a software that stores all the keys for all your servers and the software is protected by a quick password, is your key really secure? Or, if your private key is placed on a hard drive for fast access by SSH software, does the key management software provide any protection?

However, there are still some solutions for the entire infrastructure and the creation and management of public keys. I have mentioned Puppet. In the Puppet field, you can create modules to manage servers in different ways. The idea is that servers are dynamic and may not be precise copies of each other. Here is a clever method: Compile. This solution may or may not be suitable for you.

Or, another way is to completely change the line. In the Docker field, you can adopt a different method. This blog post on SSH and Docker is described in detail /.

But how about private key management? If you do not find many software solutions, I have mentioned the cause above. If the private key is placed on your hard drive, management software may not provide much extra security. However, I do use this method to manage keys:

First, I have multiple Host items in the. ssh/config file. I have a host for logon, but sometimes I have multiple items for a single host. This is the case if I want to log on multiple times. I have two different mechanisms to log on to the server hosting the git software library; one for git and the other for bash access for general purposes. Logons for git greatly restrict the permissions on that machine. Do you still remember the git key I mentioned earlier on a remote development machine? Although those keys can be used to log on to one of my servers, the accounts used are severely restricted.

Secondly, most of these private keys include the pass code. (If you have to enter the Traffic Code multiple times, you can use ssh-agent .)

Third, I do have some servers that want to be protected more seriously. I have no corresponding items in the Host file. This is more like a social engineering level, because the key file is still there, but it takes intruders a little longer to find the key file and find out which machine to start. In that case, I only need to manually enter a long ssh command (this is actually not that bad ).

As you can see, I don't use any special software to manage these private keys.

No comprehensive practices

We occasionally receive questions from readers asking them what software they can use to manage keys. But think about it first. This problem needs to be expressed in different ways, because there is no comprehensive solution. You should ask questions based on your own situation. Are you just trying to find a place to store the key file? Still looking for a way to manage multiple users, each user has its own public key, these public keys need to be inserted into the authorized_keys file?

I have introduced the basic aspects in this article. I hope you can understand how to manage keys only when you have raised the correct question, and what kind of software you should look for (if you really need additional software ).

English: How to Best Manage Encryption Keys on Linux