There is no caching for smardcard PINs. Once a key (or group of keys) on a hard has been used (i.e. PIN entered). that key can be used as long as the card has not been reset or powered-down. No rule without exception: Some cards may require that a PIN entry is required for each crypto operation. For example the OpenPGP card (which is implemented on a Yubikey) does this for the signing key but not for the authentication (ssh) key. To disable this for the signing key you use the "forcesig" command of gpg --card-edit.

The behaviour you experience might also be due to a bug for example a crash of scdaemon. To check for this please add

log-file /somewhere/scd.log
verbose
debug ipc,reader,app

to ~/.gnupg/scdaemon.conf and check the log file whether scdaemon has been restarted (different PID logged).

In T5167#139880, @gniibe wrote:

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

$ gpg2 --card-status
Reader ...........: 1050:0116:X:0
Application ID ...: D2760001240102000006052447750000
Application type .: OpenPGP
Version ..........: 2.0
Manufacturer .....: Yubico
Serial number ....: 05244775
Name of cardholder: Gustavo Schenkel
Language prefs ...: en
Salutation .......: Mr.
URL of public key : https://keybase.io/gbschenkel/pgp_keys.asc
Login data .......: gbschenkel
Signature PIN ....: not forced
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 617
Signature key ....: F3CA D085 19AD 8710 2EC0  AF5B 774C BAE8 32D4 46D8
      created ....: 2019-03-22 15:09:11
Encryption key....: 9019 6F72 C4D8 EF78 7286  63BE 1C37 7535 594F 1EE5
      created ....: 2019-03-22 15:10:39
Authentication key: DDF8 9CED 784D 9A27 9349  681A 265C FBF8 58E6 7E02
      created ....: 2019-03-22 15:10:54
General key info..: sub  rsa2048/0x774CBAE832D446D8 2019-03-22 Gustavo Brondani Schenkel <gustavo.schenkel@gmail.com>
sec#  rsa4096/0x4EEB0BCD843194ED  created: 2019-03-22  expires: never     
ssb>  rsa2048/0x774CBAE832D446D8  created: 2019-03-22  expires: 2021-03-27
                                  card-no: 0006 05244775
ssb>  rsa2048/0x1C377535594F1EE5  created: 2019-03-22  expires: 2021-03-27
                                  card-no: 0006 05244775
ssb>  rsa2048/0x265CFBF858E67E02  created: 2019-03-22  expires: 2021-03-27
                                  card-no: 0006 05244775

With 2.2.23 I can do:
$ git fetch
$ git pull
and it don't ask me the PIN twice.

With 2.2.25, if I do:
$ git fetch
$ git fetch (this is purposeful)
it request the PIN twice, also in the second time, it request to insert the Yubikey, which is already plugged in.

Thank you for the information.
In the log, the driver detects removal of card wrongly.
That's the cause of this problem.

Could you please change your PIN to 123456 beforehand, and try again to get more debug log?

Before your experiment (after changing PIN), please add three lines of

debug-ccid-driver
debug-ccid-driver
debug-ccid-driver

in ~/.gnupg/scdaemon.conf, and run gpgconf --kill scdaemon. This can record more detail.

Changing PIN is important, because your PIN information will be recorded in the debug log.

Hi, I changed the PIN, killed the gpg-agent and scdaemon, edited the scdaemon.conf to include your instruction, after, I run the following commands:

$ gpg2 --card-status
$ git fetch
$ git fetch

Thanks a lot.
Let me explain the situation.

The internal CCID driver submits USB interrupt transfer to receive notification from device (card removal).
For some reason (by the change in 2.2.25), it detects an error in intr_cb callback:

DBG: ccid-driver: CCID: interrupt callback 1 (0)

Here, "1" means LIBUSB_TRANSFER_ERROR, which means serious error. So, the driver gave up to handle the error as device removal.

I don't know the exact reason, but it seems that the addition in ccid_setup_intr:

libusb_clear_halt (handle->idev, handle->ep_intr);

causes this trouble for Yubikey NEO. I did introduce this addition to make sure the initialization (like after resume from suspend), but I need to evaluate this again.

Following device (a bit older than yours, I guess) works well:

DBG: ccid-driver: idVendor: 1050  idProduct: 0112  bcdDevice: 0334

When I configure it to OTP+FIDO+CCID, it also works for me, it is:

DBG: ccid-driver: idVendor: 1050  idProduct: 0116  bcdDevice: 0334

I wonder use of FIDO feature would interfere, when your OpenSSH supports FIDO device.
If possible, could you please try using the device as CCID-only, by configuring it with ykman mode CCID?

Changing modes will I lose/change my OTP and FIDO codes?

In T5167#139964, @gbschenkel wrote:

Changing modes will I lose/change my OTP and FIDO codes?

Possibly (I don't know. I haven't used those features at all. When I test OpenPGP feature, it remains private keys between enable/disable/enable, though).

If you are using OTP and FIDO, please don't change the mode.

Please check if your OpenSSH supports FIDO device.

I have another yubikey neo but its clean. Can it help it?

In T5167#139966, @gbschenkel wrote:

I have another yubikey neo but its clean. Can it help it?

Yes, thanks a lot. Please test with the device if/how your original problem can reproducible.
I'd like to identify the cause of the trouble, so that I can find&put some workaround for GnuPG.
I'm currently investigating how OpenSSH uses FIDO device.

I checked the development log for the addition of:

libusb_clear_halt (handle->idev, handle->ep_intr);

It was introduced for fixing failure of SPR532 reader, but applied to all readers.
I'm going to revert this addition and do different approach for SPR532.

With my Yubikey NEO, when I use OTP (touching the button to generate OTP output as key input), I observed "card eject" event:

2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: interrupt callback 0 (2)
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: NotifySlotChange: 02
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: card removed
2020-12-10 11:23:05 scdaemon[7254] DBG: enter: apdu_get_status: slot=0 hang=0
2020-12-10 11:23:05 scdaemon[7254] DBG: leave: apdu_get_status => sw=0x1000c status=0
2020-12-10 11:23:05 scdaemon[7254] DBG: Removal of a card: 0

Nice, I gonna apply the patch and see if resolves for me!

In T5167#140229, @gbschenkel wrote:

Nice, I gonna apply the patch and see if resolves for me!

Thank you. Since it is not reproducible with my Yubikey NEO, your help is indeed helpful.

Hi, I have applied both patch and appears Yubikey is now working correct. I have uploaded the log here.

$ git fetch
$ git fetch
$ git pull

Thank you for your testing.
May I ask more test, please?

In the first log of yours, it failed at the open time, and it was the error recovery which had an issue (of calling libusb_clear_halt).
In the last log of yours, because it goes well everything, the error recovery mode had not been tested.

Please do following:
(1) Enable your debug log. Insert your Yubikey NEO.
(2) Do gpg --card-status
(3) Do gpgconf --kill scdaemon (keep your Yubikey NEO in the USB port)
(4) Test if your signing works or not

That is, before actual testing, let it have a session to open/close the device.
In the second session, while the device keeps an internal SEQUENCE NUMBER != 0, but the scdaemon driver tries with SEQNO=0, then it goes to the error recovery mode.
This error recovery mode didn't work well in 2.2.25.

Procedures:

$ gpg --card-status
$ gpgconf --kill scdaemon
$ git fetch << (Used my PIN, I have reverted to my previous code other day, is not anymore 123456)

Good. The error recovery worked well.

I think that your problem is now fixed in 2.2.26.

Already have set another, thanks gnibe! See ya!