... | ... | @@ -687,46 +687,6 @@ operation (sign, authenticate, decrypt) will hang without warning |
|
|
until the button is touched. The only indication is the blinking LED,
|
|
|
there's no other warning from the user interface.
|
|
|
|
|
|
#### Troubleshooting
|
|
|
|
|
|
if this fails, check if GnuPG can see the card with:
|
|
|
|
|
|
gpg --card-status
|
|
|
|
|
|
You can also try this incantation, which should output the key's
|
|
|
firmware version:
|
|
|
|
|
|
gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
|
|
|
|
|
|
For example, this is the output when successfully connecting to an old
|
|
|
Yubikey NEO running the 1.10 firmware:
|
|
|
|
|
|
gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
|
|
|
D[0000] 01 00 10 90 00 .....
|
|
|
OK
|
|
|
|
|
|
The `OK` means it can talk to the key correctly. Here's an example
|
|
|
with a Yubikey 5 (TODO: confirm output):
|
|
|
|
|
|
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
|
|
|
D[0000] 05 04 03 90 00 .....
|
|
|
OK
|
|
|
|
|
|
A possible error is:
|
|
|
|
|
|
ERR 100663404 Card error <SCD>
|
|
|
|
|
|
That could be because of a permission error. Normally, `udev` rules
|
|
|
are in place to keep this from happening.
|
|
|
|
|
|
If everything goes south and you locked yourself out of your key, you
|
|
|
can completely wipe the OpenPGP applet with:
|
|
|
|
|
|
ykman openpgp reset
|
|
|
|
|
|
WARNING: that will WIPE all the keys on the device, make sure you have
|
|
|
a backup or that the keys are revoked!
|
|
|
|
|
|
### Making a second YubiKey copy
|
|
|
|
|
|
At this point, we have a backup of the keyring that is encrypted with
|
... | ... | @@ -871,8 +831,6 @@ At this point, SSH should be able to see the key: |
|
|
|
|
|
If not, make sure `SSH_AUTH_SOCK` is pointing at the GnuPG agent.
|
|
|
|
|
|
TODO: https://github.com/drduh/YubiKey-Guide#troubleshooting
|
|
|
|
|
|
### exporting SSH public key from GnuPG
|
|
|
|
|
|
Newer GnuPG has this:
|
... | ... | @@ -915,6 +873,48 @@ gpg: encrypted with 255-bit ECDH key, ID 9456BA69685EAFFB, created 2023-05-30 |
|
|
That is, 120ms vs 30ms, the YubiKey is 4 times slower than the normal
|
|
|
configuration. An acceptable compromise, perhaps.
|
|
|
|
|
|
### Troubleshooting
|
|
|
|
|
|
If an opreation fails, check if GnuPG can see the card with:
|
|
|
|
|
|
gpg --card-status
|
|
|
|
|
|
You can also try this incantation, which should output the key's
|
|
|
firmware version:
|
|
|
|
|
|
gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
|
|
|
|
|
|
For example, this is the output when successfully connecting to an old
|
|
|
Yubikey NEO running the 1.10 firmware:
|
|
|
|
|
|
gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
|
|
|
D[0000] 01 00 10 90 00 .....
|
|
|
OK
|
|
|
|
|
|
The `OK` means it can talk to the key correctly. Here's an example
|
|
|
with a Yubikey 5 (TODO: confirm output):
|
|
|
|
|
|
$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
|
|
|
D[0000] 05 04 03 90 00 .....
|
|
|
OK
|
|
|
|
|
|
A possible error is:
|
|
|
|
|
|
ERR 100663404 Card error <SCD>
|
|
|
|
|
|
That could be because of a permission error. Normally, `udev` rules
|
|
|
are in place to keep this from happening.
|
|
|
|
|
|
If everything goes south and you locked yourself out of your key, you
|
|
|
can completely wipe the OpenPGP applet with:
|
|
|
|
|
|
ykman openpgp reset
|
|
|
|
|
|
WARNING: that will WIPE all the keys on the device, make sure you have
|
|
|
a backup or that the keys are revoked!
|
|
|
|
|
|
See also [drduh's troubleshooting guide](https://github.com/drduh/YubiKey-Guide#troubleshooting).
|
|
|
|
|
|
## FAQ
|
|
|
|
|
|
### I don't have usb-c in my laptop, would i need an adaptor then?
|
... | ... | |