3 ms·

If by "reuse" you mean having one key per client and using it with multiple servers, then yes, that is very common and being able to do that is arguably the ent

by agwa 4y ago

If by "reuse" you mean having one key per client and using it with multiple servers, then yes, that is very common and being able to do that is arguably the entire point of public key cryptography. If you use a distinct key for every client-server pair you give up a lot of convenience and it becomes very difficult to use hardware-backed keys.

andreareina 4y ago
There are many points to public key cryptography. The important ones enable new capabilities, e.g. communicating with a counterparty that I’ve never met. But it also comes with downsides as you’ve documented. Generating a new key pair is a moment of work and eliminates many of those problems.
enasterosophes 4y ago
Not disagreeing with you, but I can think of two reasons why you might use distinct keys from the one client (and use ssh config to enforce the separation) * You want to present different identities to the world and don't want them being conflated, eg separate your github hobby projects from your employer organization. * You are using ssh certificate authentication, which isn't supported by GitHub yet, but you might be using it for other things, and GitHub should hopefully support it in the future. Since this relies on the name of the cert file matching the private key filename (eg id_ed25519-cert.pub corresponding to id_ed25519), you can't afaik have different certs active for the one key. Personally, I deal with this by simply having different private keys for different purposes, to avoid cert collision.
- psanford 4y ago
  github does support ssh certs, but only for its enterprise offering.
  - enasterosophes 4y ago
    Interesting, thanks. I had a feeling the support was limited to host certs.
- chasil 4y ago
  In any case, "sed -i" can be used to add new keys, and remove old ones, from a set of ~/.ssh/authorized_keys files on a collection of hosts. It is good to be aware of the contents of these allowed credentials, and sweep unused entries. This article has a script that automates the procedure: https://www.linuxjournal.com/content/ssh-key-rotation-posix-shell-sunset-nears-elderly-keys https://www.linuxjournal.com/content/ssh-key-rotation-posix-...
tialaramex 4y ago
I'm guessing Andrew knows this, but for anybody else, in the particular case of Security Keys, they're specifically designed to create fresh public/private key pairs for each enrolment, exactly because of the privacy aspect. If you use your iPhone's fingerprint sensor to sign into both Facebook and GitHub not only do Meta and Microsoft not get the fingerprint, they don't even get a way to correlate these identities, they both just get the very minimum we could achieve, proof you are you still, whoever that is.

by agwa 4y ago

andreareina 4y ago

There are many points to public key cryptography. The important ones enable new capabilities, e.g. communicating with a counterparty that I’ve never met. But it also comes with downsides as you’ve documented. Generating a new key pair is a moment of work and eliminates many of those problems.

enasterosophes 4y ago

Not disagreeing with you, but I can think of two reasons why you might use distinct keys from the one client (and use ssh config to enforce the separation) * You want to present different identities to the world and don't want them being conflated, eg separate your github hobby projects from your employer organization. * You are using ssh certificate authentication, which isn't supported by GitHub yet, but you might be using it for other things, and GitHub should hopefully support it in the future. Since this relies on the name of the cert file matching the private key filename (eg id_ed25519-cert.pub corresponding to id_ed25519), you can't afaik have different certs active for the one key. Personally, I deal with this by simply having different private keys for different purposes, to avoid cert collision.

psanford 4y ago
github does support ssh certs, but only for its enterprise offering.
- enasterosophes 4y ago
  Interesting, thanks. I had a feeling the support was limited to host certs.
chasil 4y ago
In any case, "sed -i" can be used to add new keys, and remove old ones, from a set of ~/.ssh/authorized_keys files on a collection of hosts. It is good to be aware of the contents of these allowed credentials, and sweep unused entries. This article has a script that automates the procedure: https://www.linuxjournal.com/content/ssh-key-rotation-posix-shell-sunset-nears-elderly-keys https://www.linuxjournal.com/content/ssh-key-rotation-posix-...

tialaramex 4y ago

I'm guessing Andrew knows this, but for anybody else, in the particular case of Security Keys, they're specifically designed to create fresh public/private key pairs for each enrolment, exactly because of the privacy aspect. If you use your iPhone's fingerprint sensor to sign into both Facebook and GitHub not only do Meta and Microsoft not get the fingerprint, they don't even get a way to correlate these identities, they both just get the very minimum we could achieve, proof you are you still, whoever that is.