A minimax SSH key regime

Recently it occurred to me that I had been using the same main SSH key for almost 15 years. I had minted a second one for GitHub when I signed up there, but that was it. Worse, both of them were only 1024 bit strong! That may have been fine 15 years ago when I minted the first one, but it certainly isn’t now. They were also both DSA keys, which turns out to have a systematic weakness. (Plus, old versions of the FIPS standard only permitted 1024-bit DSA keys.)

This had to be fixed. And I wanted an actual regime for my keys, so I wouldn’t repeat this.

Naturally, my new keys are all RSA and 8192 bit strong. Yes, 8192 – why not? I worried about that slowing down my SSH connections, but I knew adding key length only increases the cost of the handshake phase, and if my SSH connections are taking any longer to set up now, I haven’t noticed. Even if I did notice, SSH now supports connection sharing (which I have enabled), so that only the initial connection to a host would even experience a meaningful delay. And since I combine that with autossh to set up backgrounded master connections to the hosts I shell into frequently, most of my connections are nearly instant, and always will be, irrespective of key strength.

So how many keys does it make sense to have?

My first impulse was to mint one key pair for each server I would be shelling into. But as I’ll explain, that isn’t what I ended up doing.

I spent a while reading and thinking.

In terms of private key security, my situation is that on every machine on which I work at a physical console, I run a SSH agent with most or all of my private keys loaded. I also have a few passphrase-less keys on other machines, for use by various scripts. (Logins using such keys are restricted to specific commands.) In all cases, an attacker who gained access to any one of these keys would almost certainly have access to all the other keys on the same machine. So there is no security to be gained from using different SSH keys for different servers from the same client. But it does make sense for each client to have its own private keys.

A simple way to encapsulate this as a rule is: never copy a private key to another machine.

In the trivial case, this means one private key for each client machine, with the public key copied to every server to be accessed from that machine. There is, however, a potential privacy concern with this: someone who can compare public keys between several systems can correlate accounts on these systems to each other. Because of this, I share public keys only between servers where I wouldn’t mind if they could be thus correlated.

The upshot is that I have one main key pair for use on my home network and on several other machines under my direct control; plus a few more key pairs (e.g. my new GitHub key) used for maybe 3 shell accounts each. (It so happens that I only have a single machine on which I run a SSH agent – my laptop –, but not long ago, there were 3.) Lastly, I have deleted all copies of any private keys I had distributed among my machines.

Update: see also Improving the security of your SSH private key files by Martin Kleppmann.