[comprev]

Inability to export the private key is no different from using an YubiKey? You can't "backup" the private key they generate either.

[johnisgood]

Yeah, that is why you should not [always (depends on your use case)] generate it on a YubiKey.

You need to have:

- an offline master private key backup (air-gapped)

- primary YubiKey (daily use)

- backup YubiKey (locked away)

- revocation certificate (separate storage) (it is your kill-switch)

Having a second YubiKey enrolled is the standard practice.

What people do wrong is:

- They generate directly on YubiKey

- They only use one device

- They do not create a revocation certificate

- They have no offline backups

You generate your GPG keys on a secured system, load the subkeys (not the master because it is not used for daily cryptography) into the YubiKeys, and then remove the secret keys from this system where you generated the keys.

[traceroute66]

> Yeah, that is why you should not generate it on a YubiKey

No. You should ALWAYS generate on the Yubikey. That's the whole point.

Your backup is one (or more) other keys.

[epistasis]

I can understand revocation for GPG, but is revocation ever used for SSH? I could understand it if SSH certificates are used, but honestly I've never encountered an org using SSH's cert system.

[lxgr]

Does OpenSSH's `sshd` even support GPG key revocation? (Assuming you're talking about using the GnuPG card application of Yubikeys, since the newer "native" FIDO security key implementation of OpenSSH does not support importing existing keys to my knowledge.)

[wink]

I faintly remember some service that would only let me add one YubiKey, taking the 2 in 2FA very literal.

[doublepg23]

Do you have a good guide/video/write up on this?

I’ve been putting off remaking my GPG and SSH keys using a Yubikey.

[eptcyka]

You are talking about GPG keys. The featured article only refers to SSH keys. Know the difference.

[nothrabannosir]

Which makes yubikey impossible to use with geographically distributed backups. You need the backup available at all times for when you want to register with any new service.

This is why you should use a device which allows exporting the seed, like e.g. multi purpose hardware crypto wallets.

[Nextgrid]

This is true for passkeys/webauthn/u2f, which is why it’s trash and a completely flawed and not fit for purpose standard (of course the primary purpose is vendor lock-in, not reliable and disaster-proof authentication).

But SSH allows you to export the public key and then you can enroll it on as many hosts as you want without needing access to the private key, so the backup key can remain in a safe, ideally forever as you should never need it.

[jwr]

Not true. If you use YubiKeys to store your GPG key, it's not a problem. You can have multiple YubiKeys with the same private key, or you can encrypt to multiple recipients.

[epistasis]

Are you talking about SSH or a different setting?

With SSH, you can always share the primary and backup pub keys, even if you don't have the backup key handy.

[lxgr]

> You need the backup available at all times for when you want to register with any new service.

Not for SSH (at least using the OpenSSH sk implementation).

[traceroute66]

> Which makes yubikey impossible to use with geographically distributed backups.

Huh ?

You do know you can wrap a symmetric key with multiple asymmetric keys, right ?