new | show | ask | jobs Github

johnisgood an hour ago

Yeah, that is why you should not 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.

▲

eptcyka 6 minutes ago | parent | next [-]

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

▲

epistasis an hour ago | parent | prev [-]

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.

	▲	johnisgood 34 minutes ago \| parent [-]
		Well, OpenSSH has a built-in key revocation mechanism (KRL which is just SSH revocation), and there are SSH certificates (with a CA) and certificate revocation, and there is ad-hoc "revocation" by removing keys from the "authorized_keys" file. If you use your GPG key for SSH, the servers that have your public key do not automatically know that your GPG key was revoked, and SSH authentication will proceed unless you remove the public key from the server OR the server uses an SSH CA/KRL model. All in all, SSH supports real revocation, but it must be enforced by the server. It is different from GPG where revocation follows the key, not the server. I have not used KRL myself, but I sort of know how it works. You can generate a new empty KRL, then add keys to revoke, and then to distribute the KRL to servers by configuring OpenSSH to use the KRL file, by adding "RevokedKeys /etc/ssh/revoked_keys.krl" to "/etc/ssh/sshd_config". The pros of KRL is that they scale better than manual removal for multiple servers, and you can revoke entire CA ranges instead of individual keys if using SSH certificates which is recommended for large setups. I hope I could clear some things up. Let me know if you have any questions though!