How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
I very much prefer to have one key per device! That allows for fine grained access control. In general I wouldn’t export private keys unless really necessary.
Per-device keys is how we did it in 2005 too. Then a laptop got stolen and you grepped authorized_keys across 60 boxes. Look at SSH certificates with short TTLs instead. OpenSSH has had them since 5.4 (2010). Almost nobody bothers until they get burned.
If you use a trezor hardware wallet (and probably other hardware wallets) you can deterministically regenerate -sk keys.
I use trezors various agents for AGE, FIDO2/passkey, ssh[0].
But you still need the backup some bits of material like stubs for some FIDO keys (not secret material) that need importing into fresh trezor devices.
It's approaching the never lose a key again levels.
Of course, I won't pretend there isn't an obvious issue. What if you lose the seed words or someone gains access. What if the software becomes incompatible, or trezor devices become expensive/change etc.
I disagree that you want the key backed up. Non-exportable is the whole point, and a copyable key is one more thing to leak. Losing an SSH key costs five minutes if a second key is already enrolled on your servers. Why does it need to survive?
You could generate an additional backup key pair, add to authorized_keys on remote hosts in additional to the stored in enclave key, test then backup and wipe from your macbook (to reduce compromise risk).
I've been using Secretive for years because I didn't bother looking it up how to do it without. I think this is worth doing without an additional third party, especially since it's only a few commands.
If you do this, have at least one backup key (if need be on paper) or a guaranteed alternate path into the hosts you depend on this key to access. Because if the secure enclave is as good as we're told, if you lose access to ->THIS<- secure enclave, its game over for the keys.
Secure enclave protecting Keychain, the keychain is backed up. Not the contents of the enclave.
Too many failed access attempts? poof the key is gone. Could be as low as 10.
(happy to be corrected. This is what I gather from a quick read-around. I was a bit surprised the site didn't seem to discuss this)
Your backup key should also be in a secure enclave, just in a different secure enclave. Both keys should be accepted by the system.
The truly paranoid can multiple types of secure enclaves - TouchID for primary, a YubiKey for backup.
> If need be on paper
Your security is only as strong as its weakest link. Paper has a way of getting photographed, and the privacy of your key depends on your OCR software, unless you really want to painstakingly copy it in by hand, and even then, it turns into a file-based key on the filesystem, with all its attendant risks.
Just in case it helps someone, a while ago I wrote a blog post with exact CLI invocations to set up a local-password-store protected by TouchID. If you wish, the encrypted password-store can be backed up and tracked with a Git.
Crazy that this particular feature we’ve all been waiting for hasn’t received first-party support by any DevEx company.
You know, the companies that say security is their number one priority, or companies that scream “developers, developers, developers”. How Google and Apple didn’t come up with something together eludes me, but then again, we have entire ecosystems and categories deployed in the areas they don’t service (auth, application control, etc).
As cool as this is, this does limit the functionality of your keys, because not everything can access the secure enclave in the way it wants to - and as others point out, this is a one-way street and locks your mac hardware into the flow.
I went with this system for some months but it ultimately broke my workflow. I switched to a system of my own devising, in which my local security key decrypts the SSH keys I require.
You can also use a password manager like 1Password [1] to store your private keys, and use a local socket for your SSH agent to automatically unlock using TouchID.
If I knew it's relatively easy I would have saved $$ on yubikey - for personal projects security requirements are not high but it's good to have something better than a file which could be stolen by malware. Kudos to author for the how-to.
The version of OpenSSH included with macOS does not support FIDO-related features and instead uses the relevant parameters to access the macOS Keychain, so I always have to install OpenSSH from nixpkgs myself.
We hit this on a four-person team. Homebrew's openssh gets you there too, but the annoying part was getting everyone's shell and ssh-agent pointing at the same binary. Half our "it doesn't work" tickets were someone still hitting /usr/bin/ssh. Nix probably avoids that drift.
We rolled this out on a few laptops. Gotcha: the key is bound to that machine's Secure Enclave, so we just register one per laptop on GitHub and our servers and treat them as disposable. New laptop, new key, remove the old one. Way easier than migrating anything.
Or backing them up, or copying them to your new computer. You're just one spilled coffee cup away from losing the key.