Hacker News Reader

Comment by maratc | Hacker News Reader

> No key files (like ~/.ssh/id_ed25519.pub and friends) littering the file system; and there’s no risk of mistakenly deleting them either.

Or backing them up, or copying them to your new computer. You're just one spilled coffee cup away from losing the key.

View on HN

That was my first thought, too — this might work as one of additional methods of logging in, but not as the only one.

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.

I too use (multiple) yubikey to hold my private gpg keys.

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.

I don't get it even after reading the guide. How do you deal with backups when using YubiKeys? The private key is stored on the YubiKey with no ability to export it, ok... then what do you do when you lose the YubiKey?

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?

Yes, you have multiple Yubikey's and store them independently.

> How do you deal with backups when using YubiKeys

You generate your gpg key on a computer, back it up securely, then store it in the YubiKey and delete the unprotected version on the computer.

This allows you to have multiple YubiKeys with the same private key.

However, nothing prevents you from generating private keys on the YubiKey and using multiple Yubikeys. Or doing a combination of the two approaches.

You don't even need a YubiKey to have an authentication subkey.

Just a random site - https://opensource.com/article/19/4/gpg-subkeys-ssh

You should never have a single ssh key as mean to login anyway. My keys never leave device that created them, but every device has its own pair, plus yubikey-like key.

You aren't supposed to be moving SSH keys. They should stay on the machine they were generated on. The less accessible they are the better.

I really wouldn't rely on an SSH key as the sole way of accessing a machine.

This works for some scenarios but not other ones. I, for one, deal with ephemeral VMs.

Why not use agent forwarding?

Where possible I do, of course, but some compute resources either don't allow to ssh in (e.g. k8s) or are configured to refuse ssh from anyone but root. I can become root on a jump box and ssh from there, but I lose agent forwarding in the process.

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.

Yes I don't see how that's helpful.

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.

[0] https://github.com/romanz/trezor-agent

cough ledger, cough coldcard cough, supply chain attacks cough cough

This attack on ledger was particularly impressive, with LTE modules and eSIMs used to exfiltrate secret material[0].

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...

Yes, this only works if you can register more than 1 ssh keys on the services you want.

Which you can do pretty much anywhere already? I'm at least not aware of any major service not allowing you to register multiple SSH public keys.

With the obvious exception being, for whatever reason, AWS that only allows specifying ONE SINGLE KEYPAIR when creating new EC2 VMs. Whyyyyyyyyyyyyyy?!

When I was checking out their git hosting service (AWS CodeCommit), they only allowed for rsa keys (and not ed25519, for example.)

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).

Reply on news.ycombinator.com