Best experience in managing encryption keys on Linux, linux keys

Best experience in managing encryption keys on Linux, linux keys
GuideIt has always been a headache to store SSH encryption keys and remember passwords. However, unfortunately, in the current world full of malicious hackers and attacks, basic security prevention is essential. For many common users, most users can only remember their passwords, or they may find a good program to store their passwords, just as we remind these users not to use the same password on each website.

But for people in various IT fields, we need to raise this issue to a level. We need to use an encryption key like an SSH key, not just a password.
Imagine a scenario: I have a server running on the cloud that serves as my master git library. I have many working computers, all of which need to log on to the central server for push and pull operations. Here I set git to use SSH. When git uses SSH, git actually logs on to the server using SSH, just as if you opened a server using SSH commands. To make these configurations better, I create a configuration file under my. ssh Directory, which contains a host item with the server name, host name, Login User, key file path, and other information. Then, I can run the following command to test whether the configuration is correct.

ssh gitserver

Soon I can access the bash shell on the server. Now I can configure git to log on to the server using the same configuration item and the stored key. This is simple, but there is a problem: for every computer I use to log on to the server, I need a key file, which means that the key file is stored in many places. I will store these key files on the current computer, and all my other computers need to store these files. Just like users with a lot of passwords, our IT staff are also overwhelmed by these many key files. What should we do?

Clear

Before we start to help you manage keys, you need to have basic knowledge about how to use keys and understand the meaning of the questions below. At the same time, there is a premise and the most important thing. You should know where your public key and private key should be. Then assume that you should know:

Here is an example. When you create an ECS instance on Amazon's network service, you must provide an SSH key for connecting to your server. Each key has a public part (Public Key) and a private part (Private Key ). If you want to ensure the security of your server, you may put your private key on the server and bring your own public key. After all, you don't want your server to be publicly accessed, do you? However, the actual practice is the opposite.

You should put your own public key on the AWS server, and you hold the private key for logging on to the server. You need to protect the private key and put it under your control, rather than on some remote servers, as shown in.

The reason is: if the public key is known to others, it cannot be used to log on to the server because they do not have a private key. Further, if someone successfully captures your server, all they can find is the public key. They cannot generate a private key from the public key. At the same time, if you use the same public key on other servers, they cannot use it to log on to other computers.

This is why you need to put your own public key on your server to log on to these servers through SSH. Do not leave these private keys out of your control.

But there is still some trouble. Imagine an example of my git server. I need to make some choices. Sometimes I log on to the development server set up elsewhere, and on the development server, I need to connect to my git server. How can I connect my development server to the git server? It is obvious that the private key is used, but this will cause problems. In this scenario, I need to place the private key on a server located 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 obtains this private key, the hacker can use this private key to obtain the permissions of the entire server network, which may cause some serious damage, which is very bad.

At the same time, this also raises another question. Should I use the same key on these other servers? As I described earlier, it would be very dangerous.

Finally, it sounds a bit confusing, but there are some simple solutions. Let's organize it in a organized manner.

(Note: In addition to logging on to the server, there are many areas where the private key is required. However, the scenario I proposed can show you the problems you are facing when using the key .)

Regular Password

When creating your key, you can choose whether to include a password for use. With this password, the private key file itself will be 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. Alternatively, you can configure your key without a password, and then log on to the server by using the key file.

In general, it is more convenient for users to use a password, but in many cases, I strongly recommend that you use a password because if the private key file is stolen, the hacker who steals the key still cannot use it unless he or she can find the password. Theoretically, this will save you a lot of time, because you can delete the public key file from the server before the attacker discovers the password to protect your system. Of course there are other reasons for using passwords, but in many cases this is more valuable to me. (For example, my Android tablet has VNC software. The tablet has my key. If my tablet is stolen, I will immediately delete the public key from the server so that its private key does not work, whether there is a password or not .) However, in some cases, I do not use a password because there is no valuable data on the server I am 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 logging on, you need to determine whether each user needs a separate key. (In general, this should be the case; you do not want to share the private key between users. In this way, when a user leaves the organization or loses trust, you can delete the user's public key without having to create a new key for other users. Similarly, by using the shared key, they can log on as others, which is even worse .) But another problem 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 images? When you copy your server, is every key identical? Different ECs software allows you to configure how to choose from. You can allow these servers to use the same key or generate a new key for each server.

If you are operating on these replicated servers, if you need to use different keys to log on to two different systems, but most of them are the same, it may cause confusion. However, sharing the same key on the server poses a security risk. Or, third, if your key has login requirements (such as an encrypted driver), you will need the same key in many places. As you can see, whether you need to use the same key on different servers is not the decision I can make for you; there is a trade-off among them, you need to decide what is the best.

Eventually, you may have:

(If you are using keys in other situations, the same universal theory can also be applied to how to use keys, how many keys are needed, whether they are shared, and how you handle public and private keys .)

Security Methods

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

In your situation, you may decide that you do not want to use a password on the system that you log on to frequently. For example, this system may be a testing machine that developers log on to multiple times a day. This is fine, but you need to adjust your rules. You can add a rule: you cannot log on to the machine through a mobile device. In other words, you need to build your rules based on your own situation. Do not assume that a specific solution is universally available.

Software

As for software, it is surprising that there are not many good and reliable software solutions for storing and managing private keys in the real world. But should there be? Consider this. If you have a program that stores all the keys of all your servers and the program is locked by a quick key, is your key really safe? Or, similarly, if your key is stored on your hard disk and used for fast access by SSH programs, does the key management software actually provide any protection?

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

Or, another option is to change to a different position. In the Docker world, you can adopt a different approach, as described by the SSH and Docker blogs.

But how to manage the private key? If you have searched, you cannot find a lot of software to choose from, because I have mentioned before. The private key is stored on your hard disk, A management software may not be able to mention more additional security. However, I use this method to manage my keys:

First, my. ssh/config file contains many host items. I want to log on to a single host, but sometimes I have more than one host. This can happen if I have many logon methods. For servers that place my git repository, I have two different logon items; one is restricted to git and the other is used for bash access for general purposes. This logon option set for git has great restrictions on the machine. Do you still remember the git key I mentioned previously stored on a remote development machine? Okay. Although these keys can be used to log on to one of my servers, the accounts used are strictly restricted.

Second, most private keys contain passwords. (If you need to enter the password multiple times, use ssh-agent .)

Again, I have some servers that I want to be more careful with. I will not place these host items in my host file. This is closer to social engineering. The key file is still in progress, but it may take a longer time for attackers to find the key file and analyze the corresponding machines. In this case, I need to manually create a long SSH command. (Not that terrible .)

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

Occasionally, we receive some questions at linux.com asking for suggestions on software that manages keys. However, let's take a look back at this problem because there is no universal solution. Your questions should be based on your own situation. Do you simply try to find a location to store your key file? Are you looking for a way to manage multiple users, where everyone needs to insert their own public key into the authorized_keys file?

Through this article, I have covered the basic knowledge in this area. I hope that you can understand how to manage your key, and only when you ask the correct question, whatever software you are looking for (or even if you need another software), it will appear.

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