Some GitHub users have asked in the issues why can't I use two Yubikeys (one as a backup). It's a question often asked
The usual answer given across the web is that you can't as GPG replaces the key with key stubs when you quit and save (if you don't save then the Yubikey appears useless as GPG doesn't delete the keys and carries on using them off the keyring.
If once you have run keytocard to transfer your keys to the Yubikey#1 you QUIT WITHOUT SAVING then you can repeat the whole process again and put in your Yubikey#2 and keytocard again. this time QUIT AND SAVE.
GPG will now replace the keys with a key stub pointing to the Yubikey with the card serial number (see Yubikey serial on back of key) when you try to decrypt/sign/authenticate. The first Yubikey will be ignored despite the fact it has a copy of the Yubikey.
However you can use gpg-connect-agent to force read the Yubikey and repoint the key stubs to the keys on the Yubikey inserted.
Just run the script and insert whichever key you have to have (primary or backup) when prompted
NB once this script has been run GPG will be pointing the stubs at the recently used Yubikey ... to go back to your first Yubikey again switch Yubikeys and re-run script
Simples :)
When using a previously provisioned YubiKey on a new computer,
I was met with an "Unusable public key" error when trying to insert
a new password, despite being able to decrypt pass entries.
I tried setting the trust on the key via `gpg --edit-key`, but was
then met with "Need secret key to do this."
I found that the solution is apparently to use the `trust-key`
directive in `~/.gnupg/gpg.conf`, which is not mentioned in the README
at the moment.
GPG Agent forwarding has a broader usage, not only
limited to ssh-agent forwarding.
In this commit gpg-agent forwarding is raised as a
separate section as it can not be contained by #SSH
any longer.
More details are added for gpg-agent forwarding, including
some important notes taken from practice and analysis.
For ssh-agent forward, older method are contained, and new
method will be included as framework has been structured.
if not done, in the next step you get error:
gpg: keyblock resource '/home/..../gnupg-workspace/pubring.kbx': No such file or directory
gpg: no writable keyring found: Not found
As mentioned in #197, the previous behaviour would require users to
touch their key any time an authentication, signing, or encryption
operation was performed. In some situations, this behaviour would be
undesirable and the only way to revert it would be fully resetting the
key and starting from scratch. Rather than using `fixed`, this commit
simply turns the feature `on` so the user can change it later if they
wish.
Additionally, a note about the other policies was included so users can
decide for themselves which fits their situation better.
