4 ms·

Note that there are some pretty significant caveats to Secretive: - You cannot import your existing SSH keys - You cannot transfer SSH keys if you get a new m

• adastra22 4y ago
  That’s the whole point, no? Tie identity to the machine itself, not a piece of data that can be stolen. BTW, if you have a key that you copy around to multiple machines, you’re doing it wrong!
  • rgoulter 4y ago
    It's not sufficient to be the whole point. With some security mechanism, I'd consider: 1. prevent other people from being able to use it. 2. recover from it in case it gets lost. If your perspective is "if I lose this laptop, I have some other way to access the systems", then it's good to never access the SSH key secret. If your perspective is that you want your secret key to be the only way to access some system, you'll want to have some way to recover the secret. I think in any case, it's understood that having an unrecoverable secret being the only way to access some system is a bad idea.
• epistasis 4y ago
  Exactly, these are precisely the features I'm looking for. They are not caveats, they are the way I want my keys to behave. If there is some sort of use case where I want to be able to backup a key, or share it with someone else I can always fall back to SSH keys on a hard disk. But those are usually anti-patterns.
• howinteresting 4y ago
  Backup and availability is where all of these systems fail. Even the new passkey sync thing is pure vendor lock-in.
  • epistasis 4y ago
    I'd prefer for a backup to be a second key on a different hardware device, personally. I might also be ok if somebody like Apple had engineered a cloud solution for securely keeping backups, but only maybe.
• licebmi__at__ 4y ago
  the main problem is the lack of support of rsa keys.
  • Avamander 4y ago
    Do you actually have something that can't even do NIST curves? Genuinely curious.
    • arthurmorgan 4y ago
      Azure DevOps.