9 ms·

Using private keys the way they are supposed to be used is a deal-breaker? You're supposed to have (at least) one keypair per device, so if you lose the device,

Using private keys the way they are supposed to be used is a deal-breaker? You're supposed to have (at least) one keypair per device, so if you lose the device, you can restrict access by revoking the keypair belonging to the lost one. Are you currently sharing one keypair for all your devices?

fbdab103 3y ago
It is about being prepared for disaster. If I use ten services registered with my private key, and the single authenticated hardware device goes poof (dies/lost/stolen) -is there an out of band mechanism for me to regain access on a new device? Maybe for some, but possibly not all. An offsite backup means that if everything goes down Monday, I can be back in business on Tuesday without fear. You could replicate some of this assurance with redundant hardware devices, but that requires perfect diligence in ensuring you have multiple devices approved to each service. AWS only just recently allowed multiple hardware tokens.
- judofyr 3y ago
  Generate a separate SSH key which is only stored in your offsite backup (and then also encrypted with a password), and not on any of your physical machines.
  - fbdab103 3y ago
    I must be missing something. If this novel key only exists inside my backups, it is not registered with any external services, and it cannot be used in the event the primary key is lost. For me to register the backup-only key with other services, it would have to live on my machine, and be simultaneously registered in addition to the primary key. I am not sure what I am gaining vs having a backup of the primary key other than increased operational burden.
    - vladvasiliu 3y ago
      You can keep just the public part of the backup key on your current device and always enroll the two keys at a time. But yeah, if the main device is stolen, it can be a pain to go update all the services with the new device’s key. I personally use the gpg app on my youbikey for this, and the secret key comes from a backup I install on a livecd.
      - fbdab103 3y ago
        Ah duh, keep the public part on the device. However, that very quickly gets into the problem of untested backups. I am then relying completely upon a private key which has never been validated to work.

fbdab103 3y ago

It is about being prepared for disaster. If I use ten services registered with my private key, and the single authenticated hardware device goes poof (dies/lost/stolen) -is there an out of band mechanism for me to regain access on a new device? Maybe for some, but possibly not all. An offsite backup means that if everything goes down Monday, I can be back in business on Tuesday without fear. You could replicate some of this assurance with redundant hardware devices, but that requires perfect diligence in ensuring you have multiple devices approved to each service. AWS only just recently allowed multiple hardware tokens.

judofyr 3y ago
Generate a separate SSH key which is only stored in your offsite backup (and then also encrypted with a password), and not on any of your physical machines.
- fbdab103 3y ago
  I must be missing something. If this novel key only exists inside my backups, it is not registered with any external services, and it cannot be used in the event the primary key is lost. For me to register the backup-only key with other services, it would have to live on my machine, and be simultaneously registered in addition to the primary key. I am not sure what I am gaining vs having a backup of the primary key other than increased operational burden.
  - vladvasiliu 3y ago
    You can keep just the public part of the backup key on your current device and always enroll the two keys at a time. But yeah, if the main device is stolen, it can be a pain to go update all the services with the new device’s key. I personally use the gpg app on my youbikey for this, and the secret key comes from a backup I install on a livecd.
    - fbdab103 3y ago
      Ah duh, keep the public part on the device. However, that very quickly gets into the problem of untested backups. I am then relying completely upon a private key which has never been validated to work.