Using two yubikeys not covered under guide

wsargent commented 8 years ago

So, this might require more feedback, as am currently flummoxed.

If you want to use a Yubikey for Windows / MacOS / Linux login as part of a multi-factor authentication, then Yubico advises having a second Yubikey as backup. This works fine, since I can use a Yubikey Nano for the Macbook Pro, and leave the desktop one plugged in.

However, if you try copying the GPG secret key and subkeys onto a second Yubikey, "keytocard" will not let you. You'll get "secret key already stored on a card" and other similar warnings. Is it not a good idea to use two Yubikeys?

wsargent commented 8 years ago

It seems like the best practice is "one GPG key per device". I don't know if they're allowed to be cross signed, but I presume so.

wsargent commented 8 years ago

Okay, I think this is slightly more complicated. There needs to be a single KEYID, but then there need to be different subkeys for each token. Then, if a token gets stolen, you can revoke the subkey and keep the root key safe.

So this means it's not sufficient to generate a revocation certificate for the root, as is done in

https://github.com/drduh/YubiKey-Guide#create-revocation-certificate

There ALSO needs to be a revocation certificate for each subkey set tied to each token.

wsargent commented 8 years ago

Except... apparently having two encryption subkeys is a good way to get GPG very, very confused. Oh dear.

wsargent commented 8 years ago

https://tinfoil.press/t/how-and-where-to-store-your-private-pgp-key/77/6

wsargent commented 8 years ago

One might be tempted to have one subkey per machine so that you only need to exchange the potentially compromised subkey of that machine. In case of a single subkey used on all machines, it needs to be exchanged on all machines in case of a compromising.

But this only works for signing subkeys. If you have multiple encryption subkeys, gpg is said to encrypt only for the most recent encryption subkey and not for all known and not revoked encryption subkeys.

https://wiki.debian.org/Subkeys

wsargent commented 8 years ago

https://security.stackexchange.com/questions/119259/pgp-gpg-do-i-need-more-encrypton-subkeys/119262#119262

wsargent commented 8 years ago

After you purposely delete the secret key stubs from your keyring (otherwise it will say the keys are already associated with another card), you can even put these same keys on a different smartcard by repeating part of the process above.

https://gist.github.com/ageis/5b095b50b9ae6b0aa9bf

wsargent commented 8 years ago

http://www.gossamer-threads.com/lists/gnupg/users/62550

wsargent commented 8 years ago

This seems to assume THREE smartcards...

https://github.com/flamsmark/documentation/blob/master/gpg/smartcard-keygen.md

wsargent commented 8 years ago

Consider purchasing a pair and programming both in case of loss or damage to one of them.

https://github.com/drduh/YubiKey-Guide#purchase-yubikey

wsargent commented 8 years ago

Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 3

gpg: WARNING: such a key has already been stored on the card!

Replace existing key? (y/N) y

gpg: secret key is already stored on a card

https://lists.gnupg.org/pipermail/gnupg-users/2010-October/039592.html

So the way I've worked around this is to just delete the entire .gnupg directory and reimport from master for each key, but this seems suboptimal.

wsargent commented 8 years ago

I assume, although keytocard is documented as moving the key to the card, it actually copies it.

It copies, but if you then save the changes to your local disk, the original copy on local disk is deleted - so calling it a "move" operation is correct. If you want to keep a backup copy on local disk, you need to quit without saving immediately after running 'keytocard'. This behaviour is a well-known gotcha.

http://www.gossamer-threads.com/lists/gnupg/users/76764#76764

wsargent commented 8 years ago

But because I've already sharded my key with a previous NEO (still in my possession, no need to generate new keys), I get this response when executing the gpg> keytocard command:

gpg: secret key already stored on a card.

So now what? Do I delete the secring.gpg file on my hard drive and re-import the keys? Do I do that every time I configure a new NEO with my PGP keys?

In short, you don't need to delete whole keyring, just the key that is marked as exported to smartcard (Neo). You first need to delete the secret key from keyring with gpg --delete-secret-key. Then you import the full key (how it was before you moved it to smartcard).

Then you use the classic keytocard, etc.

http://forum.yubico.com/viewtopic.php?f=26&t=2095

jwr commented 6 years ago

This isn't a big problem: the way I do it is delete the secret keys completely, re-import them from my secure storage, and produce the second YubiKey by just following the instructions.

Ty-Stelow commented 6 years ago

I keep trying this process but it always asks for the last Yubikey I sent the keys to.

taigrr commented 6 years ago

I routinely swap between two YubiKeys, the Nano in my docking station and the Neo on my keychain.

I have the same encryption and authentication keys on both YubiKeys and distinct signing keys on each.

In order to swap between which YubiKey I want to use, I do the following:

killall gpg-agent
rm -r ~/.gnupg/private- keys-v1 .d/
Plug in the new YubiKey
gpg --card-edit (makes sure the card is visible, also notifies gpg which keys are available for current card)

Now the alternate card should be usable. If it's not, unplug the YubiKey and repeat steps 1-4 again, it should work the second time.

I've found the command gpg-connect-agent updatestartuptty /bye can also be helpful.

This process should help you when you are trying to create the YubiKeys as well.

Ty-Stelow commented 6 years ago

Thanks! I will give it a shot.

demonbane commented 6 years ago

If anyone is wanting to use @taigrr's approach above, be aware that this will delete all private keys you might have in your keychain. If you only have the one that's on your card, that's great, but if you have other private keys that are stored there, this will delete all of them.

If that's the case, you can just delete the individual stubs for your card by getting the keygrip for each of the subkeys on your card using gpg -K --with-keygrip, and then only deleting <yourkeygrip>.key for each subkey inside private-keys-v1.d. Or, in script form:

#!/usr/bin/env bash
keyid=YOUR_KEY_ID_GOES_HERE
gpgconf --kill gpg-agent
cd "$(gpgconf --list-dirs homedir)/private-keys-v1.d"
gpg -K --with-keygrip --with-colons "$keyid" | \
awk -F: '/^grp/ { print $10".key"; }' | \
xargs rm -vf

staticvoidmaine commented 5 years ago

I'm currently running into a problem with ssh authentication with multiple yubikeys. I have keytocard'ed the same encrypt, sign, and auth subkeys to 3 different yubikeys. I have also added each auth key to the ssh agent (gpg-driven of course).

The key here is that each ssh public key has a different cardno. To get started, I ssh'd into my raspberry pi via password and set all three keys in my authorized_keys file in hopes that it would just work for whichever key I had plugged in at the time.

Unfortunately, it's looking for the first public key I pasted into authorized_keys and wouldn't let me through until I connected the right key.

Does anyone have any tips or ideas on how to properly manage ssh identities so that all three keys are effectively "the same" for the purpose of being backups of eachother?

Should I be generating a different gpg key for each yubikey and just sharing all three public keys throughout my network of devices? Even if I did that, would that solve the problem of selecting the correct identity based on which yubikey is plugged in?

I'd love to hear any/all thoughts, opinions, or advice.

Thanks!

moonmeister commented 5 years ago

Yes, you should share a master key but creat unique sub keys to each yubikey.

jsatk commented 5 years ago

FWIW I'm using two YubiKeys. One is back up.

I created a two sets of three subkeys (one S, one E, one A) for each. 90% of the time when I need to use my yubikey (i.e. git commit) it prompts me for the one that's already plugged in and I enter my pin. Sometimes it, seemingly randomly, asks me for the other one. I click cancel and it fails. I try again and it goes to the one that's inserted.

I don't know how it chooses which subkeys to use. But it's been working fine for me.

moonmeister commented 5 years ago

I just only have the public key installed for the key I regularly use. I can always add the public key for my backup if needed.

drduh commented 5 years ago

The key here is that each ssh public key has a different cardno.

This shouldn't be relevant to SSH - or are you literally using cardno:12345 as the user to SSH as? If so, don't do that and pick a single username which will have multiple public keys authorized.

I use many keys and these two commands let me switch between them with ease:

$ pkill gpg-agent ssh-agent pinentry ; eval $(gpg-agent --daemon --enable-ssh-support)
$ gpg-connect-agent updatestartuptty /bye

I don't know about this business removing ~/.gnupg/private-keys-v1 as they're not even used for SSH. Perhaps I've misunderstood the intention, but I routinely switch between keys (each with a unique identity and SC) and have no trouble encrypting, signing and authenticating with SSH. Each of these keys also has a duplicate backup which I swap for every several weeks without fail.

jsatk commented 5 years ago

Thanks @drduh.

Would you open to adding or accepting a pull request detailing how to support two-or-more YubiKeys?

drduh commented 5 years ago

Yes, of course - PRs are welcome!

staticvoidmaine commented 5 years ago

@drduh

This shouldn't be relevant to SSH - or are you literally using cardno:12345 as the user to SSH as? If so, don't do that and pick a single username which will have multiple public keys authorized.

You're totally right - I didn't realize that the tail end of a key in the authorized_keys file is just a comment (for an embarrassingly long time) . What I was referring to is the fact that I copied the same key over to the authorized_keys file 3 times (thinking the comment at the end mattered and made the key unique) and made the mistake of thinking that was causing the gtk dialog that popped up asking to "please insert cardno xxxxxxx and try again" upon attempting to ssh into the raspi.

I use many keys and these two commands let me switch between them with ease:
$ pkill gpg-agent ssh-agent pinentry ; eval $(gpg-agent --daemon --enable-ssh-support)
$ gpg-connect-agent updatestartuptty /bye

Can you explain what the above commands do and why they are responsible for allowing you to use multiple keys? I'm new to yubikeys/pgp/gpg and have a goal that I'm not sure is correct: to have a shared master key and to have redundant yubikeys with the same subkeys on them for interchangeability. I have accomplished the keytocard end of this, technically speaking.

Are the stubs potentially the source of my problems? Are the stubs pointing to a specific cardno? I left one set of stubs thinking that all gpg-agent would need is to know that the keys reside on a smart card in general, not considering whether or not it pointed to a specific smartcard/key

I don't know about this business removing ~/.gnupg/private-keys-v1 as they're not even used for SSH. Perhaps I've misunderstood the intention, but I routinely switch between keys (each with a unique identity and SC) and have no trouble encrypting, signing and authenticating with SSH. Each of these keys also has a duplicate backup which I swap for every several weeks without fail.

What is involved in making unique keys work? I feel like I'm misunderstanding something because I'm reading about your setup and thinking that something you encrypt with key A will not be able to be decrypted by key B. Is that correct?

I want key A, B, and C to be able to all encrypt/decrypt data interchangeably. Maybe this goal doesn't make sense?

Would you be willing to take a look at these questions and help point me in the right direction to achieve my goal, or maybe redirect me to a better strategy with some context as to why?

Thank you in advance!

staticvoidmaine commented 5 years ago

I think this part of your guide solves my problem:

https://github.com/drduh/YubiKey-Guide#optional-save-public-key-for-identity-file-configuration

Killer job with the guide btw. Yubikeys would have been totally inaccessible to me without it. Cheers.

drduh commented 5 years ago

Thanks! I'll describe the use of multiple keys, multiple identities and the recovery/revocation process I use soon. The documentation for this is incomplete at the moment.

Whompithian commented 5 years ago

@rylancates

What is involved in making unique keys work? I feel like I'm misunderstanding something because I'm reading about your setup and thinking that something you encrypt with key A will not be able to be decrypted by key B. Is that correct?

I want key A, B, and C to be able to all encrypt/decrypt data interchangeably. Maybe this goal doesn't make sense?

Encryption/decryption for yourself with multiple keys is easy because you only need the public key to encrypt and gpg allows you to specify multiple target identities for a single encryption operation:

$ gpg --output file.gpg --encrypt --recipient <fingerprint1> --recipient <fingerprint2> --recipient <fingerprint3> ... --recipient <fingerprintN> file.ext

GnuPG generates a symmetric key and uses that key to encrypt the file. It then encrypts only the symmetric key using the public key of each recipient you provide and attaches the (asymmetrically-)encrypted keys to the (symmetrically-)encrypted file. Finally, it discards the unencrypted instance of the symmetric key.

When you attempt to decrypt the file, gpg will try to access the corresponding private keys in the order in which recipients were specified during encryption. So, when using Yubikeys, make sure the most convenient key is the first recipient. If not, you will simply be prompted to insert the smart card for the first key. You can do so, or you can cancel the request until the inserted Yubikey is found and you are prompted for its PIN. After successful decryption, no further keys are attempted:

$ gpg --decrypt file.gpg
<pinentry prompts to insert card, hit 'Cancel'>
<pinentry prompts for PIN of inserted card, enter correct PIN>
gpg: encrypted with 2048-bit RSA key, ID <fingerprint1>, created 2017-01-01
      "John Doe (1st Yubikey) <jdoe@example.com>"
gpg: public key decryption failed: Operation cancelled
gpg: encrypted with 2048-bit RSA key, ID <fingerprint2>, created 2018-01-01
      "John Doe (2nd Yubikey) <jdoe@example.com>"
gpg: encrypted with 2048-bit RSA key, ID <fingerprint3>, created 2019-01-01
      "John Doe (3rd Yubikey) <jdoe@example.com>"
...
gpg: encrypted with 2048-bit RSA key, ID <fingerprintN>, created 20XX-01-01
      "John Doe (Nth Yubikey) <jdoe@example.com>"
Plain text from a file. No, really, this is the message.

Similarly for authentication, you need only provide all public keys to all hosts to which you wish to authenticate. Essentially, just treat the collection of public keys as though it is a single, large public key.

It is trickier to deal with other people when using multiple keys because you have to convince them to trust signatures from all of your signing keys and get them to encrypt to all of your encryption keys.

ghost commented 5 years ago

I have created two sets of subkeys (6 subkeys) transferred 3 keys on each of the yubikeys. I am trying to use the gpg --encrypt --armor --recipient $KEYID and gpg --decrypt --armor examples. It works with the second key I have setuped, when using the first key it's asking me to insert the second key.

jsatk commented 5 years ago

This is the exact issue I've ran into using to using two YubiKeys. I'm sure there's a way to tell it which YubiKey to prompt me for but no idea how.

On 01/23, Steffel wrote:

I have created two sets of subkeys (6 subkeys) transferred 3 keys on each of the yubikeys. I am trying to use the gpg --encrypt --armor --recipient $KEYID and gpg --decrypt --armor examples. It works with the second key I have setuped, when using the first key it's asking me to insert the second key.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/drduh/YubiKey-Guide/issues/19#issuecomment-456856028

ginkel commented 5 years ago

https://forum.yubico.com/viewtopic38a1.html?f=35&t=2400#p10091 has a workaround when using multiple Yubikeys with the same subkeys on them:

gpg-connect-agent "scd serialno" "learn --force" /bye

This worked for me.

apiraino commented 5 years ago

@ginkel the workaround works but I'm still perplexed.

If the intended behaviour is not to have two keys completely interchangeable (for security reasons, as the forum post explains), then what is the correct usage for "backup" Yubikeys?

Should there be a second set of three subkeys deployed on each Yubikey, then every signing/encryption should happen with all of them (as @Whompithian writes?).

I think a clear example of usage of a "backup" Yubikey (which is recommended by Yubico) could help clarify this.

Other than that, this guide is pure gold - thanks @drduh for taking the time to do this.

staticvoidmaine commented 5 years ago

@apiraino I'm wondering the same thing. I would love an example of the "right" way to use backup keys. Currently, it feels as though I don't actually have a backup key since they aren't truly interchangeable.

For sites that use u2f like github etc., I've added all three keys and that seems to work fine. It's really just the gpg stuff that I'm tripped up on.

bdimcheff commented 5 years ago

I've been using 3 yubikeys successfully for ~9mo now.

I still have an SD card with my full key, it's in a very safe place somewhat far away. I only use this to provision new yubikeys.

The first yubikey has my full key on it (the one also backed up to the sd card). I keep this yubikey in a safe place at home, and only pull it out when I need to update expiry, or when I need to sign someone else's key (you need certification capabilities for that). As far as I know, I can't create a new yubikey with this one, but I could be wrong. Perhaps I can create new subkeys in a pinch, but presumably I can't extract the existing subkeys on this and add them to another key.

The second and third yubikey I carry around with me - one is usbc, one is usba/nfc. Most of the time, I use the same yubikey for each computer, so I don't run into the switching issue. When I do, I just delete the stuff in .gnupg/private-keys-v1.d and do gpg --card-edit again, after killing gpg-agent.

matrixes commented 5 years ago

Having read and searched on multiple places all over the internet, I have come to the conclusion that I am in the one or all of the following states:

Befuddled by multiple Yubikeys
Confused about the terminology, such as "backup"
Lost on whether two Yubikeys can be clones of each other
Not groking how to recreate a Yubikey that's lost or otherwise inaccessible

I'm slowly getting to a point where I think it's just not "the right way of approaching Yubikeys" when I want to create a carbon copy of a Yubikey. As in; I should be considering every Yubikey unique, and not assume that there can be N number of Yubikeys holding the same PGP encryption/decryption keys.

It looks like one of the most common questions are something akin to what I myself am asking;

Can I have N number Yubikeys that are carbon copies of each other?
Can I recreate a lost Yubikey and effectively regain access to all the services, hosts, accounts, etc, that got lost with the previous Yubikey?

At this point, I'm not geling well with the fact that I have two keys (having followed the instructions twice), that both need to be added to every service I want to securely have a backup method for gaining access to. Enabling SMS or email reset procedures, I find inferior to having clones of Yubikeys that I can get to if I need them.

I'm also very unsure about the terminology used. Backup, clone, copy, etc. I can't tell if Yubico are just not considering this, or if they are very determined to use the terms they do. It's confusing nevertheless.

The guide you provide here so far, @drduh is great. It's concise, has a good flow and structure and, as far as I can tell, provide a setup that a lot of people want and find useful.

What I'm missing, that I would appreciate even more, would be a section that answers the questions I asked in the bullets above. Even if the answers to both of them are; "No, you can't. If that was possible, the whole idea behind Yubikeys would be thrown out the window." and what the alternatives would be, if there are any, and the procedure of accomplishing that.

demonbane commented 5 years ago

Can I have N number Yubikeys that are carbon copies of each other?

It is possible to make multiple Yubikeys with the same encryption keys on them, but it's kind of a pain to do, and an even bigger pain to actually use that way. GPG associates keys with the device that they're on, so even though you might have the correct encryption keys, GPG will keep asking for the card it thinks has them because the ID is different. It's possible to work around it (this is what I do), but it's definitely not a great configuration from a usability perspective.

Can I recreate a lost Yubikey and effectively regain access to all the services, hosts, accounts, etc, that got lost with the previous Yubikey?

Yes, but you have to jump through some extra hoops when you first create your key and any time you ever need to switch to a new device. The problems involved are the same ones as having multiple copies of the same key, it's just that at least this way you only have to do it when you switch devices, not every single time you plug in a different device.

matrixes commented 5 years ago

Can I have N number Yubikeys that are carbon copies of each other?

It is possible to make multiple Yubikeys with the same encryption keys on them, but it's kind of a pain to do, and an even bigger pain to actually use that way. GPG associates keys with the device that they're on, so even though you might have the correct encryption keys, GPG will keep asking for the card it thinks has them because the ID is different. It's possible to work around it (this is what I do), but it's definitely not a great configuration from a usability perspective.

Can I recreate a lost Yubikey and effectively regain access to all the services, hosts, accounts, etc, that got lost with the previous Yubikey?

Yes, but you have to jump through some extra hoops when you first create your key and any time you ever need to switch to a new device. The problems involved are the same ones as having multiple copies of the same key, it's just that at least this way you only have to do it when you switch devices, not every single time you plug in a different device.

Right. So with all of these options at hand, I'd really appreciate getting the instructions for those different alternate setups, because I'd rather have a cloned key that I can whip out when my primary one goes bust, and gain the same access and capabilities with my second clone, without having to do practically anything.

The whole reason I'm asking for this is that I want to lock my second (or third) key into a safe, from the exact time I set them all up, then use my primary every-day key, adding the public key credentials in whatever place I'd like, but not having to be forced to add two or even three credentials on every service. And that's not even mentioning the hassle of having to add U2F-keys manually and individually to ensure I can gain access to the accounts when the first one goes bust.

I mean, setting up Yubikeys isn't a walk in the park the first time, especially if you want to verify you've done it right and not messed some small detail up that isn't evident when you go about signing, authenticating, etc. After a couple of tries programming keys, you learn a few new things, and if you're willing to stick around for 3, 4 rounds of setting up your Yubikey(s), I'm pretty sure those extra "hoop" steps still falls into the category of people that can live with the usability issues.

I know I'd be a happier camper with these alternative setups explained as well, so I can choose whether or not I'd like to pursue them.

apiraino commented 5 years ago

Ok folks,

I've contacted Yubico and asked them about this scenario we are discussing, trying to get an official word and because their Knowledge Base is not rich in details on this.

As you are aware our guide on setting up openPGP with YubiKeys also will use the keytocard command to move the key to the YubiKey. However, the keytocard command will not allow you to re-copy the same private key if you were to re-import them to your machine.

so far, so good.

Unfortunately due to the nature of the PGP standard and the set of commands that comes with PGP it is not possible to have two YubiKeys for openPGP. Articles on stackexchange also notes that " When using OpenPGP smart cards, a secret key dummy is stored in your keyring, holding a reference to the smart card it is stored on. " .

Nothing new here, too: we all have noticed that GPG keys require that very key to provide the de/encryption service.

I would recommend following the GnuPG bug report on the improvement of this behavior.

And here's the missing piece that (at least for me) helps understand: this is a bug, not a feature. Therefore the workaround detailed in this guide and the subsequent workaround mentioned earlier in this thread all make sense to make the scenario work, due to a GPG bug.

So, if I understand correctly, in order to clone Yubikeys, keep them in a safe and only use them when you loose the "master" one, the procedure is detailed already in this repo.

Finally, creating multiple (Signing, Encrypt, Decrypt) subkeys packs to be spread on all the Yubikeys to avoid the above-mentioned behaviour is (imho) a less appealing workaround.

hth

matrixes commented 5 years ago

Ok folks,

I've contacted Yubico and asked them about this scenario we are discussing, trying to get an official word and because their Knowledge Base is not rich in details on this.

As you are aware our guide on setting up openPGP with YubiKeys also will use the keytocard command to move the key to the YubiKey. However, the keytocard command will not allow you to re-copy the same private key if you were to re-import them to your machine.

so far, so good.

Unfortunately due to the nature of the PGP standard and the set of commands that comes with PGP it is not possible to have two YubiKeys for openPGP. Articles on stackexchange also notes that " When using OpenPGP smart cards, a secret key dummy is stored in your keyring, holding a reference to the smart card it is stored on. " .

Nothing new here, too: we all have noticed that GPG keys require that very key to provide the de/encryption service.

I would recommend following the GnuPG bug report on the improvement of this behavior.

And here's the missing piece that (at least for me) helps understand: this is a bug, not a feature. Therefore the workaround detailed in this guide and the subsequent workaround mentioned earlier in this thread all make sense to make the scenario work, due to a GPG bug.

So, if I understand correctly, in order to clone Yubikeys, keep them in a safe and only use them when you loose the "master" one, the procedure is detailed already in this repo.

Finally, creating multiple (Signing, Encrypt, Decrypt) subkeys packs to be spread on all the Yubikeys to avoid the above-mentioned behaviour is (imho) a less appealing workaround.

hth

Ok, this sounds promising. So, what I'm missing at this point, would be the instruction for taking said backup and creating that clone. I have tried this once, but could never really grok what the procedure would look like (barring getting the USB stick out of the safe and plugging it into the computer), pretending to have lost the original Yubikey, and going through the steps of recreating it with the saved, encrypted backup GPG-keys on a USB stick.

In this guide by @drduh I see the steps for saving backups. I do not, however, see the steps for using them again at a later point, to fetch the backups in order to recreate the lost key.

I'm probably missing something that's blatantly obvious, and I'd just like to figure out what that missing piece is, when looking at the instructions.

apiraino commented 5 years ago

I think (though not 100% sure, because I did not test it) the procedure to clone and create a new Yubikey can be:

During the very first Yubikey setup, you copy on a backup device (ex. a LUKS encrypted USB key) your $GNUPGHOME, see the end of this section: sudo cp -avi $GNUPGHOME /mnt/encrypted-usb
So you retrieve that backup directory and copy back on your PC (extra-paranoia points for using a live Linux distro)
Now you have your original GPG keyring and you can proceed with the Yubikey setup, as per this guide
If you want to setup more Yubikeys, copy $GNUPGHOME on your PC for as many times as Yubikeys you want to setup: the keytocard command is a destructive operation.

Makes sense?

baetheus commented 5 years ago

To create a clone I followed this same guide, but instead of doing the Creating Keys step I do the following:

Create a temporary directory:

$ export GNUPGHOME=$(mktemp -d) ; echo $GNUPGHOME
/tmp/tmp.aaiTTovYgo

Create a hardened configuration for GPG with the following options or by downloading drduh/config/gpg.conf:

$ curl -o $GNUPGHOME/gpg.conf https://raw.githubusercontent.com/drduh/config/master/gpg.conf

Copy the armored mastersub.key to the temp directory:

$ cp /Volumes/gpg-backup0/mastersub.key $GNUPGHOME/

Import the key:

$ gpg --import $GNUPGHOME/mastersub.key

At this point you will be prompted for your key passphrase.

You can then set the $KEYID variable with the master key id. You get this with:

$ gpg --list-secret-keys
/tmp.FLZC0xcM/pubring.kbx
-------------------------------------------------------------------------
sec   rsa4096/0xFF3E7D88647EBCDB 2017-10-09 [C]
      Key fingerprint = 011C E16B D45B 27A5 5BA8  776D FF3E 7D88 647E BCDB
uid                            Dr Duh <doc@duh.to>
ssb   rsa4096/0xBECFA3C1AE191D15 2017-10-09 [S] [expires: 2018-10-09]
ssb   rsa4096/0x5912A795E90DD2CF 2017-10-09 [E] [expires: 2018-10-09]
ssb   rsa4096/0x3F29127E79649A3D 2017-10-09 [A] [expires: 2018-10-09]

And set it:

$ export KEYID=0xFF3E7D88647EBCDB

You can now continue setting up a "clone" of your yubikey following the guide from here.

Using the cloned key with gpg-agent will fail at this point because the agent keeps track of the yubikey card id. So, as @ginkel posted, you can tell gpg-agent to relearn the serialno on the smartcard with:

gpg-connect-agent "scd serialno" "learn --force" /bye

Hope this helps!

CHANGELOG

20210929

Updated "from here" link to follow to the correct section in the guide.
Fixed spelling mistakes

matrixes commented 5 years ago

To create a clone I followed this same guide, but instead of doing the Creating Keys step I do the following: ... Hope this helps!

I just tried this and I have mixed success. It seems like two commands are important when switching Yubikeys:

gpg-connect-agent "scd serialno" "learn --force" /bye echo UPDATESTARTUPTTY | gpg-connect-agent

It seems that gpg is getting confused as to which Yubikey is connected, and those two in conjunction clears that confusion up..?

Having followed the instructions I can:

See that the credentials between the Yubikeys now are the same in terms of master and subkeys.
Access and manipulate my password-store
Access my SSH hosts
Push to my Git repos

I can't:

Access services where I set up U2F Authentication

It's super close to become a full fledged clone, but I am curious about the U2F authentication. Is that also possible to clone, because that's one of the more difficult pieces to the puzzle to reset, should you ever lose your primary key, if one is relying on the Yubikeys being the only 2FA method.

Edit

Looks like it's probably paper backup keys that will have to suffice for this specific case of U2F. as far as I can tell. It's a bit of a bummer.

JessicaMulein commented 5 years ago

I have created two sets of subkeys (6 subkeys) transferred 3 keys on each of the yubikeys. I am trying to use the gpg --encrypt --armor --recipient $KEYID and gpg --decrypt --armor examples. It works with the second key I have setuped, when using the first key it's asking me to insert the second key.

Could you tell me how you did this?

Ty-Stelow commented 5 years ago

Sorry for taking so long to reply, it's been a busy weekend!

So I use multiple Yubikeys depending on what I am trying to do. The fastest way I have found to swap keys on the same computer is to run the command, "gpg --card-status" with the key you want to use inserted. You can also run, "gpg-connect-agent "scd serialno" "learn --force" /bye"

If you need any more information hit me up.

Ty

On Sat, Oct 19, 2019 at 11:21 AM Jessica Mulein notifications@github.com wrote:

I have created two sets of subkeys (6 subkeys) transferred 3 keys on each of the yubikeys. I am trying to use the gpg --encrypt --armor --recipient $KEYID and gpg --decrypt --armor examples. It works with the second key I have setuped, when using the first key it's asking me to insert the second key.

Could you tell me how you did this?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/drduh/YubiKey-Guide/issues/19?email_source=notifications&email_token=AKHO7YM2R5HGDGQEY4EKV5LQPNFZLA5CNFSM4CQNEWK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXZL6Q#issuecomment-544183802, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKHO7YJZ7JI5NCD3AWQR7YTQPNFZLANCNFSM4CQNEWKQ .

timgilbert commented 5 years ago

One thing worth noting is that if you generated your master key passphrase randomly, as suggested in the guide, and you're setting up a "cloned" backup key from cold storage following @baetheus's method above, you'll want to ensure that your randomly-generated passphrase is stored in your cold storage somewhere. In order to copy the private key to your second Yubikey, you will need to use the passphrase you initially typed in when generating the key in the first place.

I forgot to record this value and now I'm going through the whole sequence again from scratch.

aleprovencio commented 4 years ago

I could successfully create and use the yubikey "clone" using @baetheus's method (thank you!). However, I still wonder how it works since the servers I ssh into have 'cardno' included on the key string on the authorized_keys, I mean, shoudn't the servers deny the connection when 'cardno' changes?

AlexanderBartash commented 4 years ago

@aleprovencio 'cardno' appears at the end of the string and is not being used in cryptography. In that part of the public key you can often see an email or you can write whatever because it is purpose is just to let people know who owns the key.

aleprovencio commented 4 years ago

Got it, thanks @AlexanderBartash

Danrancan commented 4 years ago

I keep trying this process but it always asks for the last Yubikey I sent the keys to.

I'm having the same issue on a Mac. I used Debian 10 to create a key pair, then duplicate the key to another Yubikey. However, when using the 2nd (backup) Yubikey on my Mac, it just keeps asking for the original Yubikey to decrypt a message. Have you figured this out at all?

drduh / YubiKey-Guide