4 ms·

At the time when I wrote this, I had three separate machines that I used regularly: personal laptop, work laptop, work desktop.

by jperras 14y ago

aeontech 14y ago
But three keypairs (one for each machine) is still not "quite a few"... And if you had more than one per machine, can you clarify why?
harshreality 14y ago
The arguments you've presented so far in favor of multiple keypairs on one computer (different keypairs for different remote services) make no sense. Typical ssh usage is one keypair per account per machine (or one keypair per type, e.g. I have an rsa keypair and ecdsa keypaor). It doesn't matter if you use the same keypair for github and ec2 instances [1]. The only way for the key to be compromised is if your local machine is compromised. If the local machine is compromised, you can't trust any keys stored on it unless you know when it was compromised and you know you haven't entered the passphrase for some of the private keys since the compromise. More than likely, you won't know that, so you will have to treat all keys on the compromised machine as compromised. You'll have to regenerate and redistribute N keys instead of 1. In your parent post, you identified physical theft as your main concern. Assuming you have a good passphrase, physical theft is a non-issue. Border crossing seizures and court proceedings are different; in some cases they can demand that you enter your passphrase(s), but multiple keypairs will not help you there. [1] caveat: of course if you use unprompted authentication forwarding, this becomes an issue... a compromise at github for instance could allow the github hacker to ssh into your EC2 instances using forwarded credentials, but that's a time-limited attack and only works while you're connected to github. Private keys never leave the machine(s) they're hosted on.
- jperras 14y ago
  You make some good points that are making me rethink my key-per-service approach. Though, other than the need to replace N keys when my machine(s) is compromised, there's not that much key management overhead.

At the time when I wrote this, I had three separate machines that I used regularly: personal laptop, work laptop, work desktop.

by jperras 14y ago

At the time when I wrote this, I had three separate machines that I used regularly: personal laptop, work laptop, work desktop.

aeontech 14y ago

But three keypairs (one for each machine) is still not "quite a few"... And if you had more than one per machine, can you clarify why?

harshreality 14y ago

The arguments you've presented so far in favor of multiple keypairs on one computer (different keypairs for different remote services) make no sense. Typical ssh usage is one keypair per account per machine (or one keypair per type, e.g. I have an rsa keypair and ecdsa keypaor). It doesn't matter if you use the same keypair for github and ec2 instances [1]. The only way for the key to be compromised is if your local machine is compromised. If the local machine is compromised, you can't trust any keys stored on it unless you know when it was compromised and you know you haven't entered the passphrase for some of the private keys since the compromise. More than likely, you won't know that, so you will have to treat all keys on the compromised machine as compromised. You'll have to regenerate and redistribute N keys instead of 1. In your parent post, you identified physical theft as your main concern. Assuming you have a good passphrase, physical theft is a non-issue. Border crossing seizures and court proceedings are different; in some cases they can demand that you enter your passphrase(s), but multiple keypairs will not help you there. [1] caveat: of course if you use unprompted authentication forwarding, this becomes an issue... a compromise at github for instance could allow the github hacker to ssh into your EC2 instances using forwarded credentials, but that's a time-limited attack and only works while you're connected to github. Private keys never leave the machine(s) they're hosted on.

jperras 14y ago
You make some good points that are making me rethink my key-per-service approach. Though, other than the need to replace N keys when my machine(s) is compromised, there's not that much key management overhead.