Or backing them up, or copying them to your new computer. You're just one spilled coffee cup away from losing the key.
I have been using YubiKeys for many years now, following this guide: https://github.com/drduh/YubiKey-Guide
This means I can have secure private keys for ssh and gpg (cue the crowd saying gpg is insecure without offering good modern alternatives), which I can also back up. And I can set up multiple YubiKeys, which I do.
An additional advantage of this solution is that you can set your YubiKey to require a touch confirmation before performing an operation. This makes it much harder for runaway AI agents to wreak havoc on your servers: there is a physical limitation, which I really like.
But I am not sure I will stick with gpg though.
Even with my system to extend their expiration or renew them. I have found handling them to be a pain.
I use them for 2 things: encrypt/decrypt gopass secrets and sign git commits.
Gopass now has more than decent age support. A yubikey can hold an age key.
Most git forges accept a ssh key to sign commits. A yubikey can hold a ssh key.
So, for my needs, I think I could leave the operational complexities (to me) of gpg and go for alternatives that are simpler.
Just a random site - https://opensource.com/article/19/4/gpg-subkeys-ssh
Are you supposed to have multiple YubiKeys (multiple private keys) and then ensure that all your systems accept the matching multiple pubkeys?
The guide's Backup section is... super vague. It says exporting keys, of which some are private keys, which I thought shouldn't be possible?? And then it goes off about partitioning and filesystems?
I really wouldn't rely on an SSH key as the sole way of accessing a machine.
It's quite opposite of what I'd want.
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.
But ledger is one I wouldn't recommend even without these issues, they've previously stockpiled customer data which leaked and lead sustained targeted attacks on their customers.
They've got some sort of method of getting the secret keys out of the secure elements - which makes you think what's the point at all? Oh so they can sell you a backup service subscription for your keys. Which were meant to never leave your device.
[0] https://www.coindesk.com/tech/2026/10/13/ledger-says-spy-chi...
With the obvious exception being, for whatever reason, AWS that only allows specifying ONE SINGLE KEYPAIR when creating new EC2 VMs. Whyyyyyyyyyyyyyy?!
> PasswordStore (`pass`) + GnuPG (`gpg`) + TouchID
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)
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.
This is the whole idea behind storing keys in the secure enclave. You can just as easily store the backup YubiKey in a safe as well.
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).
If it gets compromised, you need to revoke this one key only and still maintain access from, presumably, other systems of yours.
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.