How do I best manage encryption keys on Linux?

Storing the SSH encryption key and remembering the password can be a very painful thing to do. Unfortunately, it is essential to do basic security precautions in today's years of rampant hacking and vulnerability. For many ordinary users, this means just remembering the password and possibly finding a good piece of software to store the password, because we remind ordinary users not to use the same password for each site. But for those of us who work in different it industries, we need to build on this. We also deal with encryption keys such as SSH keys, not just passwords.

One scenario is as follows: I run a server on the cloud for my main git software library. I have a lot of computers for public office. All of those computers need to be logged into the central server to push and get content. I set up git to use SSH. When Git uses ssh, the way git logs into the server is actually the same as starting the command line and using SSH commands to access the server. In order to configure everything, I created a configuration file in the. SSH directory that contains a host entry that provides the server name, host name, login user, and key file path. Then, I can test this configuration by simply typing the following command:

SSH Gitserver

Soon I saw the bash shell of the server. Now, I can configure git to use the same item and log in with the stored key. It's easy, except for one problem: I need a key file for each computer that is used to log into that server. This means that there will be more than one key file. I have several such keys on this computer, and there are several such keys on other computers. Just as the average user has countless passwords, it's easy for our IT staff to have countless key files. What's the best way to do that?

Clean up the mess.

Before you start using a software to help manage your keys, you need to do some basic work to figure out how to handle the keys and whether the questions we ask are reasonable. This first requires you to understand where your public key is placed, and where the private key is placed. Suppose you already know the following:

1. The difference between a public key and a private key

2. Why the private key cannot be generated with the public key, but the private key can be used to generate it.

3. The purpose of the Authorized_keys file and where it is placed.

4. How do you use the private key, log in to the server that has the corresponding public key in the Authorized_keys file.

Here's an example. When you create a cloud server on the Amazon Web Services (AWS) platform, you have to provide an SSH key to connect to your server. Each key has a public and private section. Because you want your server to stay secure, at first glance, you seem to put the private key on that server and take the public key with you. After all, you don't want that server to be publicly accessible, do you? But in fact it's the opposite.

Keep the private key, and put it on your side, rather than on a remote server.

You put the public key on the AWS server and secure the private key used to log into the server. You keep the private key and put it on your side, not on a remote server, as shown in.

The reasons are as follows: even if the public key is known, they cannot log into the server because they do not have a private key. Also, if someone did try to break into your server, they found just the public key. The private key cannot be generated with the public key. So, if you use the same key on other servers, they can't use that key to log on to other computers.

That's why you put the public key on your server and use SSH to log into the server. The private key is your personal. You don't allow those private keys to fall into the hands of others.

But there are still problems. Take my git server as an example. I'm going to make a few decisions. Sometimes I log in to a development server that is hosted elsewhere. On that development server, I need to connect to my git server. How can the development server connect to a git server? By using the private key. And there's a problem here. This scenario requires me to place the private key on a server hosted elsewhere, which can be dangerous.

Now look at the further scenario: what happens if I log in to multiple servers using a single key? If the intruder manages to get the private key, he can then access the entire server virtual network after he has the private key, ready to do some serious damage. That's not a good thing.

This, of course, raises another question: Should I use the same key for other servers? As I have just described, this can be dangerous.

Finally, it sounds a mess, but there are some simple solutions. You may wish to introduce them individually.

(Note: In addition to just logging into the server, there are a lot of places to use the key, but I introduced this scenario to show that you are dealing with the key problems.) )

Pay attention to the pass code

When you create the key, you have the option to add a passcode (passphrase), which requires a passcode when using the private key. With this passcode, the private key file itself is encrypted using the passcode. For example, if you store the public key on the server and log in to the server with the private key, you will see a prompt for the passcode. If there is no passcode, the key cannot be used. In addition, you can configure the private key without a passcode at first. That way, you only need to log into the key file to the server.

It is usually easier for users to use the passcode, but I strongly recommend using the passcode in many cases, one reason is that if the private key file is stolen, the person who stole the file will not be able to use it unless he can find the passcode. Theoretically, this can earn you time because you can protect the system by removing the public key from the server before the attacker discovers the passcode. There are other reasons to use the passcode, but the reason for the light is worth the use of it in many cases. (For example, I have VNC software on my Android tablet.) My private key is stored on my tablet computer. If the tablet is stolen, I can immediately revoke the public key from the tablet login server, making the private key useless and having no access code. In some cases, however, I don't use the passcode because the server I'm logged into may not have much valuable data on it. This depends on the specific situation.

Server infrastructure

How you design your server infrastructure will affect how you manage your keys. For example, if you have multiple users who want to log in, you need to determine whether each user gets a separate key. (Usually, they should get a separate key; you don't want the user to share the private key.) That way, if a user leaves the business or loses trust, you can revoke the user's key, and there is no need to generate a Xinmi key for each additional user. Similarly, if you share a key, they can log in as each other, which is also not good. But another question is, how do you assign servers. For example, do you use a tool (such as puppet) to allocate many servers? Do you create multiple servers based on your own image? If you copy the server, does each server need to have the same key? Different cloud Server software allows you to configure this aspect, depending on how you choose. You can have the server get the same key, or you can generate a new key for each server.

If you are dealing with a replicated server, users will be stunned if they need to log in with a different key to a different server similar to each other. On the other hand, there is a security risk of having several servers share the same key. Or on the other hand, if your password needs to be used for purposes other than logging in (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 a different server is not the decision I could make for you; there are some places you need to decide what is best for you.

Finally, you may have:

• Multiple servers that need to be logged into;

• Multiple users logging into different servers, each with their own keys;

• Each user has multiple keys in order to log on to different servers.

(If you use keys in other situations-you might, say, how to use a key, how many keys you need, whether you share a key, and how you handle the public and private parts of the key, the same basic concept will still apply.) )

Security methods

Once you know your infrastructure and unique circumstances, you need to develop a key management program that will help you guide how to distribute and store your keys. For example, as mentioned earlier, if my tablet is stolen, I hope that the tablet will be used to access the server before I can revoke the public key from the server. Because of this, I need to take into account the following situations in my master plan:

1. Private keys do not matter on mobile devices, but they must package the passcode.

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

In your case, you may decide that you do not want to use the passcode for a system that is frequently logged on, for example, the system may be a test machine that developers log in several times a day. That's fine, but then you need to tweak the rules a little bit. You may want to add a rule that does not log on from a mobile device into the machine. In other words, you need to make procedures according to your own circumstances, rather than assume that there is a readily available approach.

Software

Again, the software. Strangely, there are not many good and reliable software solutions for storing and managing your private key. Consider this: if there is a software for all your servers to store all the keys, the software is protected by a shortcut password, your key is really safe? Or, similarly, if your private key is placed on a hard drive for quick access by the SSH software, does the key management software provide any protection?

But there are some solutions to the entire infrastructure and the creation and management of public keys. I've already mentioned puppet. In the puppet world, you can create modules to manage servers in different ways. The idea is that servers are dynamic and not necessarily exact copies of each other. Here's an ingenious way: http://manuel.kiessling.net/2014/03/26/ building-manageable-server-infrastructures-with-puppet-part-4/, the same key is used on different servers, but different puppet modules are used for each user. This solution may or may not be suitable for you.

Alternatively, the alternative is to completely reverse the idea. In the Docker world, you can take a different approach to this blog post on SSH and Docker: http://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/.

But how about managing the private key? If you search for a few software scenarios, I mentioned the reasons above, and the private key on your hard drive, the management software may not provide too much extra security. But I do use this method to manage the keys:

First, I have multiple host entries in the. ssh/config file. I have an item for the host to log on to, but sometimes I have multiple items for a single host. This can happen if I want to log on more than once. I have two different mechanisms for logging into the server hosting the Git repositories, one for git and the other for general purpose bash access. The kind of login used for git greatly limits the permissions on that machine. Remember what I said earlier about the GIT key on the remote development machine? Although those keys can be used to log into one of my servers, the accounts used are severely restricted.

Second, most of these private keys include the passcode. (If you encounter a need to enter a passcode more than once, consider using Ssh-agent.) )

Thirdly, I do have some servers that want to be protected more seriously, and I don't have a corresponding entry in the host file. This is more of a social engineering dimension because the key file is still there, but it takes an intruder a bit longer to find the key file and figure out which machine to start with. In that case, I just need to manually enter the long SSH command (which is not so bad).

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

There is no such thing as

We occasionally receive questions from readers asking what good software is available for managing keys. But you might as well calm down and think about it. This problem actually needs to be expressed in different ways, because there is no solution at all. You should ask questions according to your own situation. Are you just trying to find a place to store your key files? Or are you looking for a way to manage multiple users, each with their own public key that needs to be plugged into the Authorized_keys file?

I've covered the basics in this article, and hopefully now you can see that only you ask the right questions to know how to manage keys and what software to look for (if you really need extra software).

English: How to the best Manage encryption Keys on Linux

How do I best manage encryption keys on Linux?