
Ask HN: How do you manage your private keys? - bobsoap
I&#x27;m sure many here need to juggle different servers or services between jobs, clients, playgrounds, and projects.<p>1. How do you organize your private key(s)? One for all, one per client, one per project, one per client&#x2F;project&#x2F;machine?<p>2. How do you move your keys between devices&#x2F;machines? USB copy? File in password manager? Something like Keybase? This point is obviously moot if you have different keys per device.<p>Personally, I&#x27;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.<p>As for key management, I&#x27;ve been simply keeping them in directories, but I&#x27;ve been looking into Keybase&#x27;s git integration lately for that, hence the question.
======
snowwrestler
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.

------
corrigatt
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.

~~~
pfranz
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.

------
JohnFen
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.

------
xs83
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!

------
jans23
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.

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

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

~~~
exabrial
I can neither confirm nor deny the existence of another copy

------
spartas
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.

~~~
kickopotomus
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.

~~~
spartas
Sorry.

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

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

~~~
nabdab
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.

------
ngenstyle
Does anyone have any actual useful/helpful comments?

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

