Mmhmhm. No.

Can you give me the exact steps what you are doing?
"Generation of an OTP" is strange to me. I have an FST-1 hardware token that runs the same software as a yubikey (GNUK) but I'm not so well versed in all the windows use cases. But I am interested to fix them.

In T4225#119482, @aheinecke wrote:

Can you give me the exact steps what you are doing?
"Generation of an OTP" is strange to me. I have an FST-1 hardware token that runs the same software as a yubikey (GNUK) but I'm not so well versed in all the windows use cases. But I am interested to fix them.

• Boot Windows 10 PC with Yubikey connected.
• Start GPG-agent.
• SSH authentication: works fine. As many times as I want (after initial PIN entry).
• Generate OTP by touching / tapping the 'button' on the Yubikey.
• SSH authentication: fails. gpg --card-status return "No such device". Windows tells me that "Yubikey NEO OTP+CCID" is connected. Also works fine to e.g. generate additional OTPs.

Sorry, there is no good way, but only workaround in this case, because it is complicated and it is basically wrong thing to do it by composite device (in my opinion). I'll describe detail in this comment.
I'm not Windows user, so, I don't have an idea how to recover from such a situation.

On GNU/Linux, gpgconf --reload scdaemon stops scdaemon and it may recover from this situation, with no OS reboot.

Well, here is the story.

Yubikey device supports multiple protocols by offering multiple interfaces in a single device. It is called "composite" device.
By configuring the device it can support OTP (one-time-password), U2F (authentication by public-key crypto), and CCID (smartcard).
It sounds great, but in fact, since it shares a control pipe (of number 0) among interfaces, interfaces cannot be 100% independent.

• GnuPG scdaemon only cares about CCID protocol
• I think that OTP (and U2F) is handled by system driver, as a device like keyboard (it's HID interface).

More specifically, there are two fundamental problems when a device offers multiple interfaces in this way:

• some protocol, including CCID protocol, defines it's own use of control pipe, which relates to packets sent to an interface specific endpoints.
  • Shared control pipe among interfaces can interfere and interference may result undefined behavior.
• an interface can be handled by a driver, and another interface can be handled by another driver. One can be system one, another can be user-space one. Permission to allow access to the device is difficult thing.
  • this can be only solved serving by a single driver for multiple interfaces (in my opinion)

So, by its (wrong) design, users have to use the device only in a way something like interchangeably (sorry, my English is not good, far from perfect).
I mean, you should switch between OTP use and CCID use alternatively, and you should be aware of which interface you are using. Don't mix your usage between one and another.