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!

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.

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.

Backup and availability is where all of these systems fail. Even the new passkey sync thing is pure vendor lock-in.

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.

the main problem is the lack of support of rsa keys.

Do you actually have something that can't even do NIST curves? Genuinely curious.

Azure DevOps.