Ask HN: How do you manage your SSH keys? Do you prefer tryping your passphrase every time you use them or you use an agent; if you use an agent, is it 'ssh-agent' or a frontend utility (e.g, Keychain)? If it is ssh-agent, how do you configure it? If it is a backend, what is it and why did you choose it? Please, tell us (me?) about your practices. |
[0]: https://github.com/stevenkaras/bashfiles/blob/master/.ssh/co...
[1]: https://github.com/stevenkaras/bashfiles/blob/master/.ssh/
The only threat a passphrase protects against that an encrypted home doesn't is someone walking up to my unlocked laptop (it locks automatically after 5 minutes, and I make a point of locking it when I'm leaving). If you run ssh-agent, you're exposed to this threat anyways.
EDIT: After some thought, passphrases can protect against a poorly executed attack, where just files are copied wholesale, or an accidental leak. So while theoretically you're not protected, it may be sufficient for some practical security. I'll be looking into using ssh-agent in the near future.
Use a yubikey or smart card to level up from these.
If a computer and/or key is compromised, well, I just nuke all the related keys.
I don't understand the desire to manage a large number of keys since the attack surface is pretty clear:
A) The machine is not compromised and the key is safe.
B) The machine is compromised and the key should be replaced ASAP.
C) As a byproduct this forces obsolescence of keys in the ~3-4 year timeframe and you really should be swapping out keys every so often anyway. This keeps you from ignoring this fact for a decade :p
The downsides (besides possible security implications of trusting someone else's code to manage your keys) is that tools like rsync and scp won't work straight out of the box. You have to either alias ssh to ssh-ident, or provide the path to ssh-ident yourself.
Thanks for asking the question.
I even leave the files encrypted during the build and deployment process and only decrypt them when they reach their final resting place. Using a combination of BASH and AWS's KMS (Kem Management Service) it wasn't too difficult and I feel much better about putting secret information in my source code. :)
(The actual secrets are then ridiculously insecurely transferred between colleagues via whatever communication medium the people involved think of first. Open to suggestions there :-) )
Or use a zerobin instance somewhere (encrypts things clientside with AES 256) and pass them a link. https://zb.a.im/
NOTE: If anyone needs an invite to Keybase.io, email me; I still have a couple left. :)
[1] http://ejohn.org/blog/keeping-passwords-in-source-control/
I prefer a single ssh key for almost everything. It's on only 1 laptop that I use daily. There is no protection on the key itself, but I always lock the laptop screen (password protected) when I leave the laptop alone.
I have other laptops/devices, usually with different keys. My "master" key is also on my 2nd laptop. Although I could have a passphrase there, I still prefer no protection except screen locking. This said, this 2nd laptop never leaves my home, where only trusted (and "innocuous") people can touch it.
Of course, in every security scenario the risks determine the level of security, but having a passphrase has no practical downsides.
I would add this. If someone malicious gets physical access to your laptop, you've got bigger problems to deal with. ;)
Now I just put an identity in ~/.ssh/id_rsa and use ssh-copy-id to copy it over. Dead simple and easy. One of these days I'm going to replace the key, a script to remove ~/.ssh/authorized_keys before re-running ssh-copy-id will do the trick.
Though, these days, I'm trying to move towards making servers cattle rather than pets. I don't want to ssh into a server at all, just use configuration management to interact with them.
If you don't have your Yubikey at your parents house, maybe you should just enjoy spending time with them, instead of working on things that need an SSH key?
Yubikeys are very durable and small; just put them on your (physical) key-chain.
To prevent losing access when you lose your key, ensure you have a backup yubikey, or backup the keys stored on the yubikey so you can create a new one. If you use a solution where the secret cannot leave the key (such as Fido U2F keys) than register your backup key with all the services you use as well, or generate recovery codes for each service. Needless to say, these should be stored in a very secure place.
If you don't do this, any root user on any machine you connect to can use your ssh-agent connection to auth to other machines.
PROS:
* When you update your trusted GPG certificates (adding new auth keys, revoking others) the authorized_keys files get updated at the first execution of monkeysphere on the server (you usually put that in cron together with gpg --refresh-keys). So you can rekey without having to change manually all the SSH accounts you have.
* You do not need to recompile or patch SSH and it is compatible with other keys not fed by Monkeysphere.
* The GPG PKI, although not perfect, has quite some features; in particular, it lets you somewhat easily manage different keys on different computers, generate and revoke subkeys independently. The web of trust also helps you when trusting keys from other people.
* Monkeysphere can also be used for SSL certificates, although that is more difficult and less supported (and also less useful, now that we have Let's Encrypt).
CONS:
* Monkeysphere's development appears to be a bit stalled; not the ideal situation for a security-related thing.
* Monkeysphere does a good job, but it should not be trusted blindly. There may be a number of situation where external conditions may break the game; e.g, if you do not realize there is a misconfiguration, a revoked key may remain in authorized_keys because Monkeysphere is failing at updating; if you trusted Monkeysphere to do everything correctly, you would be exposed without knowing it.
* The GPG PKI as well is not perfect; for example, key management is complicated with many subkeys (for instance, you cannot give meaningful names to them) and the web of trust mechanism does not support "scoped trust" (i.e., giving different trust levels for different things you want to do).
* Monkeysphere only works when the remote host is a Linux box where you can install Monkeysphere and have it update authorized_keys via cron. No hope to manage GitHub keys or things like that (unless they introduce support, which seems unlikely).
In an ideal world sensitive data never leaves the production environment or the machine of the developer or operator working on it, but sometimes things break down, and you need to share information to find out what went wrong, as soon as possible, with colleagues who are not necessarily physically nearby. It is best to have these tools set up and part of your work flow when you do need them.
I think the point is in relying on something that is fundamentally secure, not secure because it is obscure. If I print my private key on a piece of paper and pin it up by my desk that's something I shouldn't tell people, but if I have it locked in an unspecified safe deposit box, there isn't much harm in describing what the deposit box is made out of.
It does make you less secure, but a good security plan starts from assuming your adversary knew all that sort of thing in the first place.