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.
I've configured ssh to use a different key for each server [0]. I don't bother with passphrases on each key, instead relying on a encrypted home folder. Also, I have a script [1] for rotating keys, so rotating all my credentials is a single command.<p>[0]: <a href="https://github.com/stevenkaras/bashfiles/blob/master/.ssh/config" rel="nofollow">https://github.com/stevenkaras/bashfiles/blob/master/.ssh/co...</a><p>[1]: <a href="https://github.com/stevenkaras/bashfiles/blob/master/.ssh/" rel="nofollow">https://github.com/stevenkaras/bashfiles/blob/master/.ssh/</a>
My ssh keypair is derived from my GPG keys. They have been generated on my yubikey neo-3. The private key has never been in any computers memory (generated on the smart card). Public keys for ssh and gpg can be downloaded at my blog.
I use ssh-agent and 1 key per computer.<p>If a computer and/or key is compromised, well, I just nuke all the related keys.<p>I don't understand the desire to manage a large number of keys since the attack surface is pretty clear:<p>A) The machine is not compromised and the key is safe.<p>B) The machine is compromised and the key should be replaced ASAP.<p>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
I use <i>ssh-ident. It creates a separate ssh agent for each identity you use and you can setup a different identity for each host or ssh argument. And if worse comes to worse, it will prevent someone running off with all the keys you are currently using because instead they only have access to that one agent, not all your agents.<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.<p></i> <a href="https://github.com/ccontavalli/ssh-ident" rel="nofollow">https://github.com/ccontavalli/ssh-ident</a>
Keep it simple. I use ssh-agent .. just ~/.ssh/ - keep keys here. Backup the actual private keys and stick those on a drive you keep in a safe. Make sure your machine's HD is encrypted and you should be fine.
Is it even safe to discuss where you store your keys and how you protect them? That's halfway into a social engineering step, and sure, that's a bit of 'security by obscurity' but if I asked you where do you keep the spare keys to your house would you be comfortable answering that if you were identifiable?
I think the most important thing is key rotation, and generally I do it every year or so.<p>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.<p>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.
I used to use an agent, the problem with an agent is that it will only try like 5 keys before failing. This makes it impractical to use a different key for each server.<p>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.<p>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 use an agent, just make sure you enable the option for it to prompt you upon use. This shouldn't require you to reenter your passphrase, so it's still unlocked in memory.<p>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.
Any recommendations for backing up (private) keys? Like pgp keys for example? I consider printing them on paper, as text or QR code. Anything better than that?
I use Monkeysphere (<a href="http://web.monkeysphere.info/" rel="nofollow">http://web.monkeysphere.info/</a>), which aims to use OpenPGP as a PKI for SSH keys. It basically provides scripts to generate the authorized_keys file from a list of a OpenPGP key IDs (on the server side) and feed the GPG private key material to ssh-agent (on the client side). I think the client step can also be used directly by gpg-agent (which can play the part of the ssh-agent as well), but I am not using it. I am overall quite satisfied, but see below.<p>PROS:<p>* 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.<p>* You do not need to recompile or patch SSH and it is compatible with other keys not fed by Monkeysphere.<p>* 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.<p>* 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).<p>CONS:<p>* Monkeysphere's development appears to be a bit stalled; not the ideal situation for a security-related thing.<p>* 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.<p>* 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).<p>* 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).