Ask HN: How do you manage your private keys? | Hacker News Reader

Ask HN: How do you manage your private keys?

44 pointsbobsoap17 comments

I'm sure many here need to juggle different servers or services between jobs, clients, playgrounds, and projects.

1. How do you organize your private key(s)? One for all, one per client, one per project, one per client/project/machine?

2. How do you move your keys between devices/machines? USB copy? File in password manager? Something like Keybase? This point is obviously moot if you have different keys per device.

Personally, I'm trying to segment my projects logically and share keys as little as possible, but not to the point of obnoxiousness. I certainly try to keep devices separated in case one gets compromised.

As for key management, I've been simply keeping them in directories, but I've been looking into Keybase's git integration lately for that, hence the question.

View on HN

I always generated new keys on new devices. I never moved a private key off the device where it was generated. It just felt like doing so creates all sorts of opportunities for mistakes and loss. While it's more work to add or rotate public keys than it is to move private keys, IMO it's also safer.

When I had to manage keys for a bunch of servers and services, at first I segmented them by scope of potential compromise. For example, I had one key pair for my hosting environment, and a separate one for Github, since I had access to more repos than just the apps I was hosting.

But eventually I stopped doing that because the weak point was the device; if my device was stolen, so were all the private keys, no matter how many there were. So, might as well just have one key per device.

I always set passwords on my private keys, and stored the password in an encrypted file: either KeePass, or Keychain on my Mac.

I managed all my SSH hosts a .ssh/config file, so I could connect on the command line with just a nickname.

Edit: this was all to manage an infrastructure for developing and hosting a few dozen websites.

There is no good answer if you can’t set up a system that can manage temporary access for your disparate employees. You can escrow the keys you need off a master and set up hardware devices like yubikeys with word-based passwords unless you want to teach people how to use gpg (you don’t). Then you can put them in tamper evident bags and mail them. You can send unlock passwords once receipt has been confirmed.

Order a laptop with enough USB port types for the systems being used by remote employees in addition to an aegis secure thumb drive. Pull the hard drive and wireless card from the laptop and boot from a Linux live CD for all of the escrow. You can make a local git repo on the thumb drive for version control and store the master as well as stubs, pubs, and private keys. Hell, put the key card passwords in a file on there. Wgaf- that aegis device is going to self-encrypt and format itself if you get the password wrong enough times.

This is all fun and good, but it doesn’t scale. What do you do when you have 20,30,40 employees? What happens when you hire Frank, the non-techie? That’s the guy that needs this the most.

I guess a middle ground is to email out instructions for people to generate key pairs with passwords, have them send in their public keys, and start using something like sssd for ldap based auth where you can store their public keys in their user attributes.

Anyway, it’s still a problem we’re all interested in a push-button answer to.

Thanks for bringing up the non-techie example. Another bummer with the user generating keys, you can't validate a passphrase was used (or that a good one was used) when you just get a public key.

I segment my private keys into two broad groups -- ones I use for certs and long-term crypto, and ones I use for encrypted communications. The cert/long-terms keys are kept on a flash drive (plus a backup drive kept elsewhere) that is under physical lock and key when not actively needed.

The comms crypto keys are kept on a different flash drive that I'm less rigorous about, as I need to have it handy in order engage in the communications. I mitigate this loss of rigor by replacing them reasonably frequently.

All the flash drives involved are encrypted themselves, as well.

I generally have one per user per server if its a Production machine, this is where ssh/.config really helps to keep things organised. This private key never leaves this device.

If it is my own stuff I tend to just have one across most things for ease of use.

I might start looking into some services to manage them but its just easy to be paranoid about moving them off the devices - opens up opportunities!

I try to minimize complexity and ideally use a single key for all clients, projects etc. This works well for SSH and reasonable well for PGP. I store my key on a Nitrokey Pro secure USB key so that I can carry it with me and safely use it in any environment. This way I don't have to use separate keys even from the security perspective.

One key, on a Nitrokey. Use pgp auth for ssh, sign all of commits

What happens if you lose or damage your key? Is there some sort of backup/recovery or fallback scheme?

I can neither confirm nor deny the existence of another copy

Don't copy your keys. Don't manage or "organize" your keys. Don't share your keys.

The leaky abstractions around what you're doing with keys is a security illusion, and you need to stop.

This is a pretty good example of a useless comment. Telling the person to simply stop doing what they are currently doing is not a solution. Perhaps, instead, you could offer a different way to handle the situation outlined by the question.

Sorry.

Generate new keys for each service, device, client, and server. Don't share them. Don't copy them.

This still isn't very useful. Suppose you have a database, and an elastic number of workers that need to connect.

Still good advice. Generate a keypair on each new machine and only ever move around public keys.

If you are copying over private keys to connect, or reusing private keys, you are doing something wrong.

The most common weak security point in any system is people. If you are sharing keys and you ever need to revoke a shared key, you're in for a bad time

Does anyone have any actual useful/helpful comments?

what is your name, email, date of birth, social security number and credit card number please

Reply on news.ycombinator.com