This isn't how keys in SSH works. It's not like a password being transmitted to a server.

http://www.theatlantic.com/magazine/archive/2002/09/a-primer...

And this is not what I'm saying: I say imagine somebody can force you to give him your private key for one asset. He will get a key for all of them, unless you've already maintained separate keys.

I was actually almost involved in one of such cases, I haven't invented it out of the thin air. If you can't imagine such a scenario happening to you, you're of course lucky and you'd like to use one private key for everything. But the scenario is real.

I can't imagine situation where I would be forced to give up private key. And if I'm forced to give up one, I guess they can force me to give up rest of them.

The scenario is simply: you perform some action on one service and then some entity has the right (or might) to demand from you the private key with which that action was performed, but not "give us everything you have."

The equivalent when the scenario is an attack, and not a legal game: some entity manages to hack your computer with which you access the service A and on which you have only the private key for A, but not your another computer with which you access the service B, with the another key.

Separate keys: just your access to the service A is compromised, one key: all accesses are compromised at once.

It's not about leaking your private keys (although courts very much do work like that....think of it as keeping separate keys to each room in your house, as opposed to a single master key).

The real goal is privacy, given that your public key is available on github and sent via plaintext when authenticating.

There are some added benefits to managing separate ssh keys for each server: it forces you to use tools to manage your keys, which make it easier to mitigate disaster when the time comes to rotate your keys due to compromise.