Using two yubikeys not covered under guide #19
Comments
|
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. |
|
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. |
|
Except... apparently having two encryption subkeys is a good way to get GPG very, very confused. Oh dear. |
|
|
|
This seems to assume THREE smartcards... https://github.com/flamsmark/documentation/blob/master/gpg/smartcard-keygen.md |
|
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. |
http://www.gossamer-threads.com/lists/gnupg/users/76764#76764 |
|
* Adding part descriping how to use multiple Yubikey with same keyset. * Changed from `ykpers` to `ykman` as it is more feature complete. * Added `pinentry-mac` which is preferable as it works with GUI.
* Adding part descriping how to use multiple Yubikey with same keyset. * Changed from `ykpers` to `ykman` as it is more feature complete. * Added `pinentry-mac` which is preferable as it works with GUI.
|
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. |
|
I keep trying this process but it always asks for the last Yubikey I sent the keys to. |
|
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:
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 This process should help you when you are trying to create the YubiKeys as well. |
|
Thanks! I will give it a shot. |
|
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 |
|
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 Unfortunately, it's looking for the first public key I pasted into 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! |
|
Yes, you should share a master key but creat unique sub keys to each yubikey. |
|
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. I don't know how it chooses which subkeys to use. But it's been working fine for me. |
|
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. |
This shouldn't be relevant to SSH - or are you literally using I use many keys and these two commands let me switch between them with ease: I don't know about this business removing |
|
Thanks @drduh. Would you open to adding or accepting a pull request detailing how to support two-or-more YubiKeys? |
|
Yes, of course - PRs are welcome! |
You're totally right - I didn't realize that the tail end of a key in the
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 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
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! |
|
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. |
|
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. |
|
I use two Yubikeys for my GPG needs.
This will leave you with two Yubikeys with identical subkeys. However, GPG will have deleted the actual keys in step 4 above and replaced them with key stubs pointing to Yubikey2 To use Yubikey1 you need to force GPG to repoint the stubs to the new card... Fortunately, I have a script to do that see here ` To make a duplicate Yubikey for GPG keys1. Insert Yubikey12. Create keys/subkeys3. Run keytocard to transfer keys to Yubikey14. QUIT WITHOUT SAVING!!!!!This will leave the keys on the Yubikey but NOT change theGPG keyring to point to the Yubikey1 with a stub5. Insert Yubikey26. Run keytocard to transfer keys to Yubikey27. QUIT and SAVE to make GPG point it's stubs to Yubikey2Running any decrypt, auth or sign will now ask you to insert Yubikey2To switch to Yubikey1 at any time run this script to force GPGto repoint the key stubs to the inserted Yubikeyread -p "Insert the Yubikey you want to use .... " ignore gpg-connect-agent "scd serialno" "learn --force" /bye You can use this script to switch back and forth between the two Yubikeys. |
|
This might not fit everyone's use case, but I eventually realized that I mostly use my YubiKeys for authentication (SSH and FIDO2/Webauthn) and encrypting/decrypting data (such as backups). Which means that they don't need to be identical. So I generated two sets of keys and have two distinct YubiKeys storing them. My data is simply encrypted for two recipients, and I add two SSH or FIDO/Webauthn keys to all systems. Just wanted to put it out there, because for many people this might be enough, and this approach requires zero fiddling with GPG and stubs. |
|
It won't help if you are using yubikey 2FA. |
|
I think you misunderstood
I’m talking about Yubikey resident GPG keys and nothing to do with Fido(U2F)/Fido2
When you create a GPG key on the Yubikey or transfer a GPG key to a Yubikey, GPG leaves a stub (or pointer) to the Yubikey including the serial no
When you try to use the private key, GPG looks at the stub and sees it points to a Yubikey with a particular serial number. GPG then prompts for you to insert the Yubikey within a specified serial number in order to process the on board GPG key
If you follow anybody’s instructions in creating a second Yubikey with the same private key, GPG will still only point to the Yubikey that was setup LAST - you will not be able to use the key in the second Yubikey without forcing GPG to rescan the Yubikey (something that is not really documented anywhere on the web - I’ve spent many hours searching and eventually found a single reference)
The command you need to run is the last line of my shell script (the other lines are just fluff to make it feel more friendly)
… On 16 May 2021, at 08:17, piotrekwitkowski ***@***.***> wrote:
There's no way to clone the U2F/Webauthn key, afaik. That's the point - hardware-based, unique and stored during production. That's why in the U2F use case registering the second key (or multiple keys) is so important.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I just setup two Yubikeys with the same gpg keys:
I use this script to switch gpg between Yubikeys: |
|
@Neopallium your process seems needlessly risky, at least for anyone using After that, the private soft key can be removed from each new |
Thanks for that command.
I prefer to switch Good idea to grab the serial number. |
An alternative to the |
|
Is there a definitive solution to this? I think I just ran across the same thing and while I'm able to get the same keys added to two yubikeys, only one of them seems to be recognized as being linked to from gpg: Therefore, whenever I try to use the other for signing, it prompts for the other card. To clarify, is it actually possible for that subkey to point to more than one card at a time interchangeable? or do you have to use one as the primary and then do something to forcibly update that reference? I have a similar question for SSH keys. |
|
It would require tagging a single key with multiple cards, which I do not know if gnupg supports - or if it is even on their radar. The command I (re) posted above to switch works with minimal frustration until they do get such a feature. |
|
Thanks @holderl5. Believe you're referring to this comment: #19 (comment). Does anyone know if such a thing is possible with SSH |
It does and it doesn't Technically having a key on a Yubikey results in having a pointer to the Yubikey serial no in your key ring. So when GPG is asked to use that key it looks up in your key ring and finds it doesn't have the key but a stub pointing to a Yubikey with a specific key ring. Assuming the operating system has smart card software installed (see the guide) the GPG makes a call to the smart card software supplying the Yubikey serial num. The smart card daemon then prompts the user for a specific Yubikey (the one with the specific serial no in the stub). HOWEVER ... If you follow the instructions in this guide you can place the same key on any number of Yubikeys Each time you copy the key to the card the stub will be recreated to point to that Yubikey. If you last installed the GPG key on card B then your key ring Stub points to Yubikey B. If you place your Yubikey A into the USB port you need to force GPG to rescan the USB ports and recreate the stub to point at Yubikey A. This can be done by issuing the command : gpg-connect-agent "scd serialno" "learn --force" /bye Then the GPG key ring stub points to Yubikey A I have added a script into the repository so you don't need to remember the long command line |
First an ssh key is a different storage format (even when they use the same encryption for the key) You can create a x509 key using OpenSSL, export the auth key and then import that into the Yubikey This process is a little messy and it is easier to just create a different ssh key on the Yubikey and tweak your ssh config on your client (just ssh-keygen using a “-sk” suffixed key type. But there is a different issue here With GPG keys lost duplicates are a lot less work to revoke of compromised as they can be revoked but just applying a revocation certificate and pushing to a public server. With ssh keys revoking would require you to remove the key’s is from every server where it is used. For each server you would have to create an entry for the replacement key. This is better done upfront rather than while your mind is worrying about stolen/lost keys. It is better to have a different ssh key on each Yubikey. And copy both public keys to each server you log into. Revoking the exposed key would still involve deleting a line from each server but this is less work than adding a new key and removing the old key whilst under stress. Different ssh keys just need a ssh config tweak (comment out or change) ... but you can setup both in advance with separate hosts clauses eg hostname-k1 and hostname-k2 clauses) PS don’t forget the new Yubikey blue security keys now support resident ssh keys (as well as Yubikey 5, 4 and neo keys) |
Yes See section on multiple keys to import a key into different keys Basically you can only use one at a time on a single machine but you can issue a command to switch keys (see my script in the repo) |
For creating the duplicate key all you need to do is quit rather than save after issuing keytocard. In use switching Yubikeys is easy ... Switching GPG fits like this means that you would have to maintain two independent GPG key rings It is much easier to insert the other Yubikey and run gpg-connect-agent "scd serialno" "learn --force" /bye I have a script in the rep to save you having to remember the command |
|
Thanks @iandstanley
Good point. I'll stick to having multiple SSH keys.
Can you clarify what you mean here? I'm currently using these two guides to generate an SSH key on my yubikey. Are you saying there is a way to easily switch between them as a default? I'm aware of using
I'm using a 5c and 5ci. Are you saying they support something other than what I mentioned above from the Github key:
Section of what? The documentation or this thread? The one thing I've been confused about is when exactly to swap cards and CTRL-C to quit without saving. I was doing:
Is that the correct sequence to get it loaded on both?
Going to try this to swap what's attached to the machine's local keys. |
|
On 30 Sep 2021, at 02:33, Bradley Wagner ***@***.***> wrote:
With ssh keys revoking would require you to remove the key’s is from every server where it is used.
For each server you would have to create an entry for the replacement key. This is better done upfront rather than while your mind is worrying about stolen/lost keys.
It is better to have a different ssh key on each Yubikey. And copy both public keys to each server you log into. Revoking the exposed key would still involve deleting a line from each server but this is less work than adding a new key and removing the old key whilst under stress.
Good point. I'll stick to having multiple SSH keys.
Different ssh keys just need a ssh config tweak (comment out or change) ... but you can setup both in advance with separate hosts clauses eg hostname-k1 and hostname-k2 clauses)
Can you clarify what you mean here? I'm currently using these two guides to generate an SSH key on my yubikey. Are you saying there is a way to easily switch between them?
In .ssh/config you can define blocks of config like
Host anynameulike
Hostname www.myserver.com
User me
IdentityFile ~/.ssh/blue.key
ForwardAgent yes
Here I am configuring a label anynameulike to be an alias for logging in with “ssh -i ~/.ssh/blue.key ***@***.***
Where blue.key is a ssh key stub created when you create an ssh key in the Yubikey itself (choose an encryption format with the suffix -sk)
There is nothing stopping you create multiple stanzas were the only thing changes is Host and IdentityFile
So you can have a second Host (or second label) pointing to the same ***@***.*** ( User , Hostname) but using a different ssh key stub (IdentityFile)
For you purposes I would have two stanzas one with Host host-k1 and another with Host host-k2 (changing “host” to something meaningful) and having the appropriate IdentityFile pointing to the right key stub
Then you can
Insert key 1
$ ssh host-k1
$ exit
Remove key 1
Insert key 2
$ ssh host-key2
Without having to change the config file to point to a different identity file (or use the -I flag)
PS don’t forget the new Yubikey blue security keys now support resident ssh keys (as well as Yubikey 5, 4 and neo keys)
By that I meant the 5 and 4 series whatever the connector
And the blue security key has to be the 5 series blue key with nfc to support ssh (as it requires firmware >= 5.2.3 which had the updated Fido2 firmware supporting a openssh key)
I'm using a 5c and 5ci. Are you saying they support something other than what I mentioned above from the Github key:
ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
Yes
This is a standard ssh key created on the Yubikey itself (the normal way of doing things)
You can also create a set of x509 credentials as an alternative. The benefit of these is that you can extract an RSA key from an x509 key and then import that into a PIV authentication slot and use that for ssh
That’s messier and I would only recommend it if you *need* one of the following scenarios
1. Gov dept requires you
2. You absolutely need the identical ssh key on two Yubikeys
3. You want to configure the system to automatically expire cached authentications on removal of a Yubikey (you can do this with a regular ssh key but you have to mess around with usb removal scripts)
4. If you are using ssh certificates as well as Yubikey (an advanced topic) then you are forced down the PIV/x509 route
Normally I would not recommend a x509 key (PIV key) for use unless the situation dictates
In your situation it is easier to setup two regular ssh keys on two Yubikeys and just setup your ssh config with two easy shortcuts as described above
See section on multiple keys to import a key into different keys
Section of what? The documentation on this thread?
The main documentation of the repo’s readme.md
The one thing I've been confused about is when exactly to swap cards and CTRL-C to quit without saving. I was doing:
generate a PGP key
insert card
edit-key
keytocard process to add to 1
ctrl-C to quit without saving
swap cards
edit-key
keytocard on the other yubikey
save this time to allow it to remove local credentials
Is that the correct sequence to get it loaded on both?
Yes. I would add a “gpg —card-status” after the insert to make sure GPG realises there is a new card in there
I prefer to type quit instead of ctrl-c as I’m not sure what GPG does when you issue quit (has it done everything I need it to or would a ctrl-c stop it finishing
It is much easier to insert the other Yubikey and run
gpg-connect-agent "scd serialno" "learn --force" /bye
I have a script in the rep to save you having to remember the command
Going to try this to swap what's attached to the machine's local keys.
Can’t remember if I mentioned you can use GPG keys for ssh keys using the GPG agent rather than the ssh agent
Ps there is a great lecture by Michael W Lucas on SSH which is a must see
He has also written a book “SSH Mastery” which is considered the definitive book on all things ssh. It is available in hardback, paperback, kindle from Amazon and also in pdf/mobi/ePub from his website
If googling for him don’t forget to use his middle initial as there is a. “Michael Lucas” (no W. For Warren) who apparently is a famous gay porn star
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
intriguing! any docs to share on this? I'd be interested in having few keys to manage. |
|
I found that gpg always ignored the signing key ID specified in my git config, and instead always asked for the most-recently written Yubikey. StackOverflow had this solution:
I can now plug in either of my Yubikeys, each with a distinct signing subkey, and configure git using With this in place, it looks like there's no need to duplicate the same signing key to each Yubikey, and no need to run that |
|
So the idea here is that you need to manually update your git config to switch between the keys? Or is there a more seamless less manual process for it? |
|
You're right, it's a manual process. I couldn't find a way to make gpg select a signing subkey based on whichever Yubikey is plugged in, but since I struggled to configure which key was used at all, I wanted to note the requirement to add an exclamation point. |
This is a function of the |
Indeed, it would not claim a signing key was available until the correct key was plugged in. This was my setup:
I configured git to use subkey 1 on Yubikey 1. However, gpg ignored that configuration and always asked me to plug in Yubikey 2 with subkey 2. I confirmed the command line that git was running ( Adding the exclamation mark was what finally got gpg to respect the requested key ID (the command line was Until I added an exclamation mark to the end of the key ID in my git config, gpg utterly ignored my configuration and always asked for the wrong subkey. It would be nice if I could configure git (and subsequently gpg) to use the subkey on whichever Yubikey is already plugged in. Unfortunately, everything I've tried results in gpg demanding I plug in Yubikey 2 with signing subkey 2, so I'm noting here that the exclamation mark is necessary. |
|
Right, but that is the bug. Do you see the same problem if you specify the master KEYID in |
|
If I specify the master KEYID (I've only imported the public key and given it ultimate trust; the private key is locked away), then gpg on Linux doesn't prompt me for either Yubikey but instead exits with the message The only solution I've found is to specify the signing subkey ID explicitly, and it has to have a trailing exclamation mark for gpg to respect the configuration. To be clear: I'm not requesting support. I'm noting how I overcame an issue that seems similar to what @jsatk reported, above. It's been three years since that comment, so I wanted to note how I solved it. |
|
Have you tried the shell script I wrote
https://github.com/drduh/YubiKey-Guide/blob/master/switch-to-backup-yubikey
It’s not exactly the same scenario. I used to use 2 Yubikeys with the same keys on them - but when you keytocard your second Yubikey GPG will ask for that every time you want to use your keys even if the 1st key is in the usb port.
The script forces the GPG-connect-agent to re-examine the USB ports to see which Yubikey is plugged in and then GPG will use the plugged in Yubikey rather than ask for another Yubikey by serial number
See if running that script fixes your issues
The script is in the root of the repo
… On 2 Jun 2022, at 16:30, Kurt McKee ***@***.***> wrote:
If I specify the master KEYID (I've only imported the public key and given it ultimate trust; the private key is locked away), then gpg on Linux doesn't prompt me for either Yubikey but instead exits with the message error: gpg failed to sign the data, and then git reports fatal: failed to write commit object.
The only solution I've found is to specify the signing subkey ID explicitly, and it has to have a trailing exclamation mark for gpg to respect the configuration.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
|
Thanks @iandstanley! I'm aware of the |
|
https://www.gnupg.org/documentation/manuals/gnupg/Agent-HAVEKEY.html This command is what |
|
Ah! I see. Here's the output I'm seeing with Yubikey 1 and signing subkey 1 plugged in -- AND with it unplugged (it's the same output whether the Yubikey is plugged in or not): At this point, this has turned into more of a forum thread instead of a GitHub issue so I'm going to stop posting. I have a manual fix for integrating git with gpg with two Yubikeys with unique signing subkeys, and I've posted it here for others since this issue is a top search result. Thank you all for your support and suggestions, and to drduh for a tremendously helpful guide! |
and others
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?
The text was updated successfully, but these errors were encountered: