Is it a better idea to share private keys? In case of server breach, you will have a much harder time, won't you?

> Is it a better idea to share private keys

It is not, amd I can't see how my earlier comment can be read as recommending that. This is a solved problem for private keys (using load balancers, for example) , so public keys are lower-hanging fruit than that.

Edit: upon rereading, I cam see how the word "share" would be ambiguous in the context of if a private key. I meant "jointly make use of", rather than "distribute copies throughout the fleet". I have exited my root comment to make my meaning clearer.

A better idea would be the terminal trusting one or two core certificate authorities and then those authorities creating time limited certificates when needed.

So the terminal accepts "sshauthority1"

Then the 41 remote sites contact sshauthority1 to get a 1 hour (10 minutes, 10 days, whatever) long certificate for "site18"

If a remote site is compromised sshauthority1 no longer issues certificates, and within an hour (10 minutes, 10 days, etc) the remote site can no longer reach the terminals.

Revoking a key from that many terminals (many of which will be offline) if one of the 41 keys is exposed is not trivial.

Now if sshauthority1 is compromised then you've got the same issue with rotation (although can CRL it), but it's easier to secure one or two authorities than 41 keys.

I would argue reusing private keys worldwide is slapdash engineering. You generally want to minimize exposure in the event of a breach, not maximize it.

I wonder what the reasonable balance between reuse and over exposure is; I'd think you would want less keys per device, and have less key overlap (ie more keys overall.) But forty two sounds high, and isn't it now just 42x more at risk?

> I would argue reusing private keys worldwide is slapdash engineering

I wasn't suggesting it, and frankly can't see how that could be a solution in this instance. I was making a comparison against current practices on a harder problem to solve , i.e. safely scaling a single private key in an SSL certificate across many servers is solved today without a 1:1 server to certification ratio

You're asking for something that is supported in X.509 but OpenSSH wrote their own certificate exchange standard that does not have support for those features.

HTTPS uses X.509. OpenSSH has no interest in supporting X.509 or, AFAIK, for changing their version to support anything but "self-signed" keys.

> You're asking for something that is supported in X.509

There's more than 1 way to skin this cat, and no, I'm not asking for the a specific solution you suggested.

SpaceX can implement any internal auth-scheme they choose to connect to a handful (not 41) of SSH intermediate instances, which then connect to the terminals