Mailing List Archive: Yubikeys and GnuPG 2.2/2.3

Yubikeys and GnuPG 2.2/2.3

Jan 7, 2022, 7:23 AM

Post #1 of 6 (736 views)

Hi all,

I run GnuPG 2.2.27 on Windows 10 and gpg-agent + ssh-pageant (from Cygwin)
with Yubikey NEO for my SSH needs.

For some time now, gpg-agent has problems detecting my Yubikey. Windows
sometimes detects Yubikey as "Unknown Smart Card" and I used to resort to
manually updating the driver to get it recognised as "Identity Device (NIST SP
800-73 [PIV])" and then reinserting my Yubikey a few times until gpg
--card-status command recognised Yubikey. This used to "hold" between computer
reboots, but lately has been happening almost every time I reinsert Yubikey NEO.

To avoid furiously reinserting the key and risk breaking something, I wrote a
small PowerShell function that does this (kill scdaemon, restart Windows Smart
Card service and try reading card status):

do {
& gpgconf --kill scdaemon
Restart-Service SCardSvr
& gpg --card-status -vvv
} while ($LASTEXITCODE -ne 0)

This usually works after a few loops. I have both Yubikey NEO and Yubikey 5
and both have the same problem.

My scdaemon.conf has a single line:

card-timeout 1

I tried debugging scdaemon a bit, so I added these lines to scdaemon.conf:

log-file <path to log file>
debug-level basic
verbose

After killing scdaemon.exe and running gpg --card-status, I get:

2022-01-07 15:53:58 scdaemon[9960] listening on socket '<home
dir>\.gnupg\S.scdaemon'
2022-01-07 15:53:58 scdaemon[9960] handler for fd -1 started
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- GETINFO socket_name
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> D <home
dir>\.gnupg\S.scdaemon
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- OPTION
event-signal=0x00000284
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- GETINFO version
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> D 2.2.27
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- SERIALNO
2022-01-07 15:53:58 scdaemon[9960] detected reader 'Yubico Yubikey NEO
OTP+U2F+CCID 0'
2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected
2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation
(0x8010000b)
2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> ERR 100696144 No
such device <SCD>
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- RESTART
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK

When I run my "fixing" loop, I'll get a few of these blocks and then a success.

Recently, I tried upgrading to GnuPG 2.3.4 and my "fixing" loop does not work
at all. Debugging scdaemon with Yubikey NEO, I get something like this:

2022-01-07 15:48:05 scdaemon[24108] listening on socket '<home
dir>\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2022-01-07 15:48:05 scdaemon[24108] handler for fd -1 started
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- GETINFO socket_name
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> D <home
dir>\AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- OPTION
event-signal=290
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- GETINFO version
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> D 2.3.4
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- SERIALNO
2022-01-07 15:48:05 scdaemon[24108] detected reader 'Yubico Yubikey NEO
OTP+U2F+CCID 0'
2022-01-07 15:48:05 scdaemon[24108] reader slot 0: not connected
2022-01-07 15:48:05 scdaemon[24108] reader slot 0: active protocol: T1
2022-01-07 15:48:05 scdaemon[24108] slot 0:
ATR=3bfc1300008131fe15597562696b65794e454f7233e1
2022-01-07 15:48:05 scdaemon[24108] no supported card application found: Card
error
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> S PINCACHE_PUT 0//
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> ERR 100696144 No
such device <SCD>
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- RESTART
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK

With Yubikey 5, I get:

2022-01-07 15:48:46 scdaemon[15680] listening on socket '<home
dir>\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2022-01-07 15:48:46 scdaemon[15680] handler for fd -1 started
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- GETINFO socket_name
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> D <home
dir>\AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- OPTION
event-signal=290
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- GETINFO version
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> D 2.3.4
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- SERIALNO
2022-01-07 15:48:46 scdaemon[15680] detected reader 'Yubico YubiKey
OTP+FIDO+CCID 0'
2022-01-07 15:48:46 scdaemon[15680] reader slot 0: not connected
2022-01-07 15:48:46 scdaemon[15680] pcsc_connect failed: sharing violation
(0x8010000b)
2022-01-07 15:48:46 scdaemon[15680] reader slot 0: not connected
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> S PINCACHE_PUT 0//
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> ERR 100696144 No
such device <SCD>
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- RESTART
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK

If I add "psc-shared" option to scdaemon.conf and use Yubikey 5, gpg
--card-status works every time, but I still get "no supported card application
found: Card error" for Yubikey NEO.

Is there any way to get Yubikey NEO working with GnuPG 2.3?

Thank you,
--
Marko Božikovi?

--
Marko Božikovi?

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Yubikeys and GnuPG 2.2/2.3 [ In reply to ]

gnupg-users at gnupg

Jan 7, 2022, 7:12 AM

Post #2 of 6 (736 views)

Permalink

Hi all,

I run GnuPG 2.2.27 on Windows 10 and gpg-agent + ssh-pageant (from Cygwin)
with Yubikey NEO for my SSH needs.

For some time now, gpg-agent has problems detecting my Yubikey. Windows
sometimes detects Yubikey as "Unknown Smart Card" and I used to resort to
manually updating the driver to get it recognised as "Identity Device (NIST SP
800-73 [PIV])" and then reinserting my Yubikey a few times until gpg
--card-status command recognised Yubikey. This used to "hold" between computer
reboots, but lately has been happening almost every time I reinsert Yubikey NEO.

To avoid furiously reinserting the key and risk breaking something, I wrote a
small PowerShell function that does this (kill scdaemon, restart Windows Smart
Card service and try reading card status):

do {
& gpgconf --kill scdaemon
Restart-Service SCardSvr
& gpg --card-status -vvv
} while ($LASTEXITCODE -ne 0)

This usually works after a few loops. I have both Yubikey NEO and Yubikey 5
and both have the same problem.

My scdaemon.conf has a single line:

card-timeout 1

I tried debugging scdaemon a bit, so I added these lines to scdaemon.conf:

log-file <path to log file>
debug-level basic
verbose

After killing scdaemon.exe and running gpg --card-status, I get:

2022-01-07 15:53:58 scdaemon[9960] listening on socket '<home
dir>\.gnupg\S.scdaemon'
2022-01-07 15:53:58 scdaemon[9960] handler for fd -1 started
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- GETINFO socket_name
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> D <home
dir>\.gnupg\S.scdaemon
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- OPTION
event-signal=0x00000284
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- GETINFO version
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> D 2.2.27
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- SERIALNO
2022-01-07 15:53:58 scdaemon[9960] detected reader 'Yubico Yubikey NEO
OTP+U2F+CCID 0'
2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected
2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation
(0x8010000b)
2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> ERR 100696144 No
such device <SCD>
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 <- RESTART
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x00000288 -> OK

When I run my "fixing" loop, I'll get a few of these blocks and then a success.

Recently, I tried upgrading to GnuPG 2.3.4 and my "fixing" loop does not work
at all. Debugging scdaemon with Yubikey NEO, I get something like this:

2022-01-07 15:48:05 scdaemon[24108] listening on socket '<home
dir>\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2022-01-07 15:48:05 scdaemon[24108] handler for fd -1 started
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- GETINFO socket_name
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> D <home
dir>\AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- OPTION
event-signal=290
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- GETINFO version
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> D 2.3.4
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- SERIALNO
2022-01-07 15:48:05 scdaemon[24108] detected reader 'Yubico Yubikey NEO
OTP+U2F+CCID 0'
2022-01-07 15:48:05 scdaemon[24108] reader slot 0: not connected
2022-01-07 15:48:05 scdaemon[24108] reader slot 0: active protocol: T1
2022-01-07 15:48:05 scdaemon[24108] slot 0:
ATR=3bfc1300008131fe15597562696b65794e454f7233e1
2022-01-07 15:48:05 scdaemon[24108] no supported card application found: Card
error
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> S PINCACHE_PUT 0//
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> ERR 100696144 No
such device <SCD>
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 <- RESTART
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x000002d4 -> OK

With Yubikey 5, I get:

2022-01-07 15:48:46 scdaemon[15680] listening on socket '<home
dir>\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2022-01-07 15:48:46 scdaemon[15680] handler for fd -1 started
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- GETINFO socket_name
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> D <home
dir>\AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- OPTION
event-signal=290
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- GETINFO version
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> D 2.3.4
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- SERIALNO
2022-01-07 15:48:46 scdaemon[15680] detected reader 'Yubico YubiKey
OTP+FIDO+CCID 0'
2022-01-07 15:48:46 scdaemon[15680] reader slot 0: not connected
2022-01-07 15:48:46 scdaemon[15680] pcsc_connect failed: sharing violation
(0x8010000b)
2022-01-07 15:48:46 scdaemon[15680] reader slot 0: not connected
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> S PINCACHE_PUT 0//
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> ERR 100696144 No
such device <SCD>
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 <- RESTART
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x00000308 -> OK

If I add "psc-shared" option to scdaemon.conf and use Yubikey 5, gpg
--card-status works every time, but I still get "no supported card application
found: Card error" for Yubikey NEO.

Is there any way to get Yubikey NEO working with GnuPG 2.3?

Thank you,
--
Marko Božikovi?

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Yubikeys and GnuPG 2.2/2.3 [ In reply to ]

gnupg-users at gnupg

Jan 10, 2022, 5:05 AM

Post #3 of 6 (734 views)

Permalink

On Fri, 7 Jan 2022 16:23, Marko Božikovi? said:

> My scdaemon.conf has a single line:
>
> card-timeout 1

Please remove this at least for testing.

> log-file <path to log file>
> debug-level basic
> verbose

Please change the

debug-level ...

to

debug ipc,app,cardio

Actually you should have seen a debug line "Yubikey: config=" due to the
verbose option. The "cardio" above returns all commands (so-called
APDUs) send to the card. This should help to reveal the problem.

> 2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation
> (0x8010000b)

Some other process is accessing the Yubikey. But as you already know

pcsc-shared

is a good workaround here which usually works fine. You may send me the
log by PM if it is too large

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Re: Yubikeys and GnuPG 2.2/2.3 [ In reply to ]

gnupg-users at gnupg

Jan 10, 2022, 11:50 PM

Post #4 of 6 (734 views)

Permalink

On 10/01/2022 14:05, Werner Koch wrote:
> On Fri, 7 Jan 2022 16:23, Marko Božikovi? said:
>
>> My scdaemon.conf has a single line:
>>
>> card-timeout 1
>
> Please remove this at least for testing.
>
>> log-file <path to log file>
>> debug-level basic
>> verbose
>
> Please change the
>
> debug-level ...
>
> to
>
> debug ipc,app,cardio
>
> Actually you should have seen a debug line "Yubikey: config=" due to the
> verbose option. The "cardio" above returns all commands (so-called
> APDUs) send to the card. This should help to reveal the problem.

Just to confirm, my scdaemon.conf file should look like this:

debug-level ipc,app,cardio
verbose
log-file <path to log file>

>> 2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation
>> (0x8010000b)
>
> Some other process is accessing the Yubikey. But as you already know
>
> pcsc-shared

Yeah, but that one is available in 2.3. The card-timeout was suggested some
time ago on Yubikey forums as a workaround for exclusive card access - and it
worked for a while. If I 'primed' the card and got GnuPG to recognise it, it
would work until the next machine reboot; it would still work even after
sleep. Unfortunately, the probability of that working changed with each major
Windows update :-)

Is there a way in Windows to find which process is locking the card? I tried
using Sysinternals Process Explorer to examine handles opened by scdaemon.exe
while it does have access to Yubikey, but I couldn't find anything that would
stand out...

Thank you,

--
Marko Božikovi?

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Yubikeys and GnuPG 2.2/2.3 [ In reply to ]

gnupg-users at gnupg

Jan 11, 2022, 10:25 AM

Post #5 of 6 (734 views)

Permalink

> Just to confirm, my scdaemon.conf file should look like this:
>
> debug-level ipc,app,cardio

Replace that by

debug ipc,app,cardio

and remove debug-level lines. (The debug-leve thing is IMHO not very
useful since we got those dedicated selectors. We should eventually
remove the debug level thing and provide a GUI to select them.)

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Re: Yubikeys and GnuPG 2.2/2.3 [ In reply to ]

gnupg-users at gnupg

Feb 10, 2023, 2:03 AM

Post #6 of 6 (428 views)

Permalink

On 11/01/2022 19:25, Werner Koch wrote:
>
>> Just to confirm, my scdaemon.conf file should look like this:
>>
>> debug-level ipc,app,cardio
>
> Replace that by
>
> debug ipc,app,cardio
>
> and remove debug-level lines. (The debug-leve thing is IMHO not very
> useful since we got those dedicated selectors. We should eventually
> remove the debug level thing and provide a GUI to select them.)

Hi Werner,

I've tested this again with GnuPG 2.4.0 (Windows build) and still get the same
error with Yubikey NEO (scdaemon reports "no supported card application found:
Card error") when running 'gpg --card-status'.

Yubikey 5 works fine.

Both Yubikey NEO and 5 work with GnuPG 2.2.27.

It looks like this (https://dev.gnupg.org/T5487) bug report mentions the
same/similar problem, but that bug was supposedly fixed in 2.2.29.

I see that gniibe mentions that Yubikey NEO returns 6A86 on the first
response, but my 2.4 log shows only 6D00 responses (as did 2.3 logs).

Kind regards,
--
Marko Božikovi?

Mailing List Archive

Attached Files:

Attached Files:

Attached Files: