[ybroze]

Use unique SSH keys for each service (sharing a SSH key on your GitHub/Gitlab account, network router and AWS/Azure instance is a very stupid idea)

I don't see how this makes sense. Assuming your private keys all live on the same machine (presumably with 0600 in /.ssh), then if your machine is stolen and your user password compromised, access to one private key is the same as access to all of them.

[Tepix]

It only protects you against SSH fingerprinting done by hostile servers.

[ybroze]

I suppose, then, it's for those who don't want to be tracked, and not a "very stupid idea" per se.

But then again, if you don't trust the remote to know who you are, then why do you have an identity with them? I mean, the remote service is SUPPOSED to know who you are. That's kinda the point.

[jjnoakes]

I don't think so.

GitHub should know I'm the user who has access to push to repos a, b, and c.

AWS should know I'm the user who has access to update code or data at places d, e, and f.

But neither needs to know my full identity, or about each other, at all.

[rad_gruchalski]

Right. What about paid service. Shall I pay with someone else's CC or ask the bank for another one just because I don't want to be tracked.

[pavel_lishin]

Many banks and credit card companies offer a service that lets you generate a one-time-use credit card number.

[gruez]

But your billing address will still be the same

[acqq]

> I don't see how this makes sense.

Just imagine that somebody can request from you the ssh key to just one of the services you access. Then he gets the access to all of them.

[mirashii]

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...

[acqq]

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.

[vitalysh]

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.

[acqq]

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.

[steventhedev]

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.