Hi, Sorry it took so long to get back to you on this. Today I installed gpg 2.1.15, which contains your fix. I haven’t seen SSH connections hang yet, but haven’t been using it long.
I did, however, see failure to use the card. I initiated an SSH session, and it immediately prompted for the remote user password, indicating that the Yubikey was not authenticating. I see this in the scdaemon log: 2016-08-24 16:29:29 scdaemon[67288] updating reader 0 (0) status: 0x0007->0x0000 (1->2) 2016-08-24 16:29:29 scdaemon[67288] DBG: Removal of a card: 0 2016-08-24 16:29:29 scdaemon[67288] DBG: application has been released 2016-08-24 16:29:29 scdaemon[67288] sending signal 31 to client 67281 2016-08-24 17:23:23 scdaemon[67288] handler for fd 9 started 2016-08-24 17:23:23 scdaemon[67288] DBG: enter: apdu_open_reader: portstr=(null) 2016-08-24 17:23:23 scdaemon[67288] detected reader 'Yubico Yubikey 4 OTP+U2F+CCID' 2016-08-24 17:23:23 scdaemon[67288] reader slot 1: not connected 2016-08-24 17:23:23 scdaemon[67288] DBG: leave: apdu_open_reader => slot=1 [pc/sc] 2016-08-24 17:23:23 scdaemon[67288] DBG: chan_9 -> OK GNU Privacy Guard's Smartcard server ready 2016-08-24 17:23:23 scdaemon[67288] DBG: chan_9 <- GETATTR $AUTHKEYID 2016-08-24 17:23:23 scdaemon[67288] DBG: enter: apdu_connect: slot=1 2016-08-24 17:23:23 scdaemon[67288] pcsc_connect failed: sharing violation (0x8010000b) 2016-08-24 17:23:23 scdaemon[67288] reader slot 1: not connected 2016-08-24 17:23:23 scdaemon[67288] DBG: leave: apdu_connect => sw=0x10006 2016-08-24 17:23:23 scdaemon[67288] DBG: Removal of a card: 0 2016-08-24 17:23:23 scdaemon[67288] DBG: chan_9 -> ERR 100696144 Operation not supported by device <SCD> 2016-08-24 17:23:26 scdaemon[67288] DBG: chan_9 <- BYE 2016-08-24 17:23:26 scdaemon[67288] DBG: chan_9 -> OK closing connection 2016-08-24 17:23:26 scdaemon[67288] handler for fd 9 terminated Does the ‘pcsc_connect_failed’ message indicate that scdaemon is butting up against another smartcard handler running in OS-X? regards, Ben > On Jul 19, 2016, at 7:57 PM, NIIBE Yutaka <[email protected]> wrote: > > On 07/19/2016 05:54 PM, NIIBE Yutaka wrote: >> On 07/19/2016 02:22 PM, Ben Warren wrote: >>> We don’t see this issue when using a file-based key for SSH, >>> although in that case we’re using ssh-agent, not gpg-agent. I’ll >>> try using a file-based GPG key, which will be closer to the failing >>> configuration. >> >> Are you using some other tools for Yubikey? >> >> People sometimes do or write a script with >> >> gpg-connect-agent "SCD RESET" /bye >> >> (to reset PIN auth state) but this only works well if we have a single >> connection from gpg-agent to scdaemon. Having ssh-sessions (with >> forwarding), we have multiple connections from gpg-agent to scdaemon. >> This could be a cause of troubles. > > I think that the problem occurs when we do "SCD RESET" above or > removal/insertion of token during the use of SSH. > > It seems for me that OpenSSH client (7.2p2, in my case) keeps the > connection to ssh-agent even if it doesn't use forwarding. So, it is > likely that we encounter this problem. > > Today, I fixed this issue by: > > commit 1598a4476466822e7e9c757ac471089d3db4b545 > > Please try it out. > -- > > _______________________________________________ > Gnupg-users mailing list > [email protected] > http://lists.gnupg.org/mailman/listinfo/gnupg-users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
