I was actually surprised to find out this doesn't already work...

I would like to be able to have two or more GnuPG cards inserted at the same
time, and have gnupg/gpg-agent/scdaemon notice all of them and use whichever one
was appropriate for the operation at hand, without my having to switch them in
and out.

My personal application for this is that I have a personal key and a work key,
and I want to be able to sign with either of them without having to swap
hardware around. It's pretty easy to set up all the other parts of this to be
seamless with Thunderbird/Enigmail/gnupg2... it works fine until you move the
keys to cards, at which point gnupg's inability to automatically choose the card
it needs really shows up.

In an ideal world, this would also work with gpg-agent as a backend for ssh.

Simple workaround is having multiple readers...

Most card readers only support a single card.
(This is the reason why it is not yet implemented.)
Could you please let us know the reader which supports multiple cards?

I do have multiple readers. If I insert one card in each of my two readers, GnuPG doesn't choose the one it needs for any given operation. It's been three years, so I don't remember exactly what DOES happen. I think it just acts as if one of the two cards were inserted, and totally ignores the existence of the other. What I want is for it to dynamically use keys from whatever cards happen to be inserted.

If this is "supposed to work", then I can try to further characterize how it fails. But I got the really strong impression that it was NOT supposed to work.

There are definitely no command line options to choose which card you want for things like "--card-status" or "--card-edit".

For your information.
Since 2.1.18, multiple readers are supported by internal CCID driver. PC/SC driver is not yet.
Since 2.1.20, gpg --card-status can have "all" or specific serialno of the card.
Perhaps, gpg --card-edit should support SERIALNO command as well.

Yes, if it supports --card-edit it would help a lot.

But I have gpg2 2.1.21 and

• the behavior you mentioned is not documented in man page
• --card-status does only view one card by default
• --card-status does not display any information when I pass a serial number:

$> gpg2 --version
gpg (GnuPG) 2.1.21
libgcrypt 1.7.6
[...]
$> gpg2 --card-status

Reader ...........: 20A0:4108:00003D590000000000000000:0
Application ID ...: D276000124010201000500003D590000
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 00003D59
[...]
$> gpg2 --card-status all

Reader ...........: 20A0:4108:000038EC0000000000000000:0
Application ID ...: D2760001240102010005000038EC0000
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 000038EC
[...]
Reader ...........: 20A0:4108:00003D590000000000000000:0
Application ID ...: D276000124010201000500003D590000
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 00003D59
[...]
$> gpg2 --card-status 00003D59
$>

I connected 2 Nitrokey Pro USB sticks, so I have multiple readers and one card in each reader...

BTW: this issue was not opened by me and I didn't wrote the first message. There was a bug in the old issue tracker...

I also struggled to get two cards running at the same time. Host system is Fedora 26 with gnupg 2.2.4.

After turning on the scdaemon debug log and comparing the "xyz reader detected" messages, I found the issue: The pcscd daemon was running by default and claiming the card readers. scdaemon will issue a harmless looking "ccid open error: skip" message in the logfile with gnupg 2.2.4. It then falls back to the pcsc driver.

Log messages when pcsc driver is active:
scdaemon[xx] detected reader 'SCM Microsystems Inc. SPR 532 [Vendor Interface] (xxxx) 00 00'
scdaemon[xx] detected reader 'REINER SCT cyberJack go (yyyy) 01 00'

-> if you see "detected reader", then it's not using the internal CCID driver.

The pcsc driver supports one card reader at a time only, though you can use the "reader NAME" config switch in scdaemon.conf to select the active one.

@gniibe: What do you think of adding a warning to scdaemon if all card readers were skipped by the internal CCID driver? Or an easy change like "detected reader" to "detected reader using pcsc: "?

tl;dr: Switch to the internal CCID driver (=in my case kill pcscd) and both cards appear with "gpg2 --card-status all".

Hi!

Could you tell what is the status of this ticket? Is it planned for the development?
For some users usage is problematic when there are other readers recognized, provided by the OS or hardware platform, and ordered before the target device which in turn blocks access to it.

I've recently acquired two Yubikeys: one Yubikey 5 NFC from my workplace, and shortly after, I bought a Yubikey 5C for my own personal keys… both security tokens have _different_ keys on them. (There are some questions being asked regarding the use of the same GnuPG key duplicated on separate smartcards; this is a different case).

I found if I have both plugged in, it sees the one it detected first, making the keys on the second inaccessible. I'm pretty new to CCID smartcard interfaces, having just relied on keeping the private key on my workstation's hard drive in the past.

Now, the question from my perspective… where would be the place to start looking for the code that controls this?

GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens. This won't be backported to the LTS versions (2.2), though. Better switch.

In T1621#149541, @werner wrote:

GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens. This won't be backported to the LTS versions (2.2), though. Better switch.

That sounds fantastic… is there a guide on how to migrate? I tried unmasking GnuPG 2.3.2 (Gentoo host) and building it… I found the number of cards I could talk to simultaneously dropped from 1 to 0:

RC=0 stuartl@rikishi ~ $ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device
RC=2 stuartl@rikishi ~ $ gpg --version
gpg (GnuPG) 2.3.2
libgcrypt 1.9.4-unknown
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/stuartl/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
AEAD: EAX, OCB
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

I checked the ./configure options, and it does appear that smartcard support is being enabled. I also verified permissions on the /dev/hidraw* devices; they were owned by the plugdev group and my user is a member of that group.

Even running gpg as root didn't help, it would not see the smartcard. I couldn't see anything obviously wrong, scdaemon was running (and it was the correct version; even tried rebooting the machine to make sure of that), but it would not see even one YubiKey plugged in.

As soon as I rolled back to GnuPG 2.2.29 and restarted gpg-agent, everything worked (albeit one device at a time):

RC=0 stuartl@rikishi ~ $ gpg --card-status
Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00
Application ID ...: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: Yubico
Serial number ....: xxxxxxxx
Name of cardholder: Stuart Longland
Language prefs ...: [not set]
Salutation .......: 
URL of public key : https://keys.openpgp.org/vks/v1/by-fingerprint/C15009E00C022A203202AAB641E5203734FC4F96

So, I have something working… in the apparent absence of any sort of clear documentation that I could find. I had some time on my hands this afternoon, so had another look.

• under GnuPG 2.2, to be able to use the PIV component of the YubiKey, some guides (notably https://www.scrygroup.com/tutorial/2018-09-13/switching-between-piv-pgp-yubikey-macos/#installation) suggest putting shared-access into scdaemon.conf, under GnuPG 2.3, scdaemon will flatly and silently refuse to start when you do this.
• Reading the scdaemon man page, it seems pcsc-shared is the new replacement for the shared-access flag, but this isn't clear
• I had pcscd configured to start at boot as it seemed to be needed under GnuPG 2.2, it seems this does more harm than good with GnuPG 2.3
• Having gotten GnuPG 2.3 working, it seems opensc-pcks11 no longer works, it cannot see either YubiKey, one of which has PIV keys loaded. Sadly, while in the short-term I can do away with PIV support, I will need it soon as my workplace will be using PKCS#11 mode on the YubiKey for HTTPS authentication while OpenPGP is used for git code signing and email confidentiality/integrity.

Tehre has never been an option "shared-access" in GnuPG. At least not in upstream. In general we suggest the use of the interal ccid driver, but if you want PC/SC you need to use disable-ccid-driver. This is because 2.3 does not feature an automatic fallback to PC/SC anymore. Using pcsc-shared with OpenPGP cards can lead to surprising effects. You may want to try Scute as PCKSC#11 access module.

I am on Windows 10 21H1 and I using gnupg-w32-2.3.3_20211012 from here [1]
Together with win-gpg-agent, which extends gnupg to play nicely with Windows sockets. [2]

I have two smartcard readers:

1. 1 TPM backed Microsoft Virtual Smartcard reader that is not related to SSH at all and is used for OpenVPN.
2. And a ReinerSCT smartcard reader with an OpenPGP V3.4 card.

I am using the OpenPGP card to authenticate with my SSH server. If I use them in isolation everything works great. But if I have both of those smart card readers connected then the agent only finds the VPN key, which is refused by the SSH server.

Only if I manually through the device manager temporarily disable the Virtual Smartcard, which as far as I can tell is a whole virtual reader, then the agent finds 2 keys, and one of them is accepted from the SSH server. See screenshots in this downstream bug report: [3]

I am confused why this is since @werner writes:

GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens.

And I am using version 2.3.3, so it should work?

I would ask that the gpg-agent can be configured as to which reader/smart card it should use.
Ideally it should completely ignore the reader with the OpenVPN key.

And if that is not possible, it should query all readers/smart cards for valid keys and present all of them to the SSH server in expectation that one of them is authorized to authenticate.

[1] https://www.gnupg.org/ftp/gcrypt/binary/
[2] https://github.com/rupor-github/win-gpg-agent
[3] https://github.com/rupor-github/win-gpg-agent/issues/17

Some more info: OpenVPN does not care about the second reader only gnupg agent is sensitive to what is present when it is started. So a workaround that I just found is to disable the Virtual Smartcard reader first so that only the ReinerSCT smartcard reader with an OpenPGP V3.4 card is present. Make sure to open an SSH connection. Then reconnect the second reader. And reconnect to VPN. After the PIN for the OpenPGP V3.4 card is already cached and a connection to the card established I can also open more SSH connections with the second reader attached and disconnect and reconnect the VPN as I want.
Even removing the smartcard from the ReinerSCT reader and plugging it back in works and I can still authenticate with new SSH tunnels and both readers present. So it seems it is actually only important which readers are present when the agent connects for the first time.
So this is a practical woraround. Although disabling the TPM backed reader temporarily needs Admin rights and is really janky.

Do not user Reiner SCT those readers are all buggy and work only on Windows - if at all. Stay away from them and get a real reader and not the incompatible broken stuff from that company. I spent way too much time trying to get those readers working. That time is better invested in support for hardware which is standard compatible or are helpful to get stuff running.

@werner That is not helpful. I tried 4 or 5 different readers. And the Reiner SCT cyberjack is the one that works best out of all of them on both Windows and Linux.

Not only does it work mostly, it is also compact enough to carry with my laptop, and still has an external pinpad.

The other ones don't even work with the TPM smartcard not present. The Omnikey 3621 works if I install the driver from the vendor but not with the built-in keypad. Same with the ACS ACR83, which also works but the built-in keypad doesn't.

The SCM SPR532 works on my desktop computer, but fails after inputting the PIN on my laptop with Pageant failed to provide a signature. And yes I have tried installing drivers from vendor page, updating OpenSC, and updating pgp-agent and the win-gpg-agent wrapper. The readers are recognized and work with other software but not with gpg-agent.

If you can recommend me a working reader with similar compact size then please do. Otherwise I am assuming it's the software after trying 5 different readers.

How can I debug this to narrow down the problem?