SSH hangs when using GPG2 + Yubikey on OS-X

[Ben Warren]

Hi,
> On Jul 18, 2016, at 7:18 PM, NIIBE Yutaka <gniibe at fsij.org> wrote:
> 
> On 07/18/2016 07:44 AM, Ben Warren wrote:
>> I’m using a Yubikey 4 hardware token on OS-X “Yosemite”.  I’m connecting
>> to a remote Linux VM and am using GPG agent-forwarding in order to sign
>> git commits using the Yubikey.  I also forward SSH through GPG, but find
>> that with one or two SSH sessions open, they hang after a couple of
>> hours. This time frame is sometimes shorter, but rarely longer.  In
>> order to recover, I need to kill scdaemon on the Mac using SIGKILL.
>> I’ve tried SIGHUP, but that doesn’t help.
>> 
>> I’m able to tolerate this, but colleagues who have more open SSH
>> connections open see it hang much more often to the point where this is
>> unusable.
> 
> I'm not sure the symptom; which is the result and which is the cause?
> I mean, scdaemon hangs because of SSH hung sessions?
> 
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.
> Well, SIGHUP doesn't work for scdaemon.  scdaemon can be killed by:
> 
>    $ gpgconf --reload scdaemon
> 
Thanks for the tip!
>> gpg (GnuPG) 2.1.12
>> libgcrypt 1.7.0
> 
> OK.
> 
>> ========
>> Timeline:
>> 2016-07-13 16:20:58 : started SSH connection
>> 2016-07-13 16:30      : I noticed the SSH connection was hung and killed
>> scdaemon
>> 
>> Here’s an interesting snippet from the log file:
>> 
>> 2016-07-13 16:28:00 scdaemon[32523] DBG: leave: apdu_get_status =>
>> sw=0x0 status=7 changecnt=3
>> 2016-07-13 16:28:01 scdaemon[32523] DBG: enter: apdu_get_status: slot=0
>> hang=0
>> 2016-07-13 16:28:01 scdaemon[32523] DBG: leave: apdu_get_status =>
>> sw=0x0 status=7 changecnt=3
>> 2016-07-13 16:28:01 scdaemon[32523] DBG: chan_6 <- RESTART
>> 2016-07-13 16:28:01 scdaemon[32523] Ohhhh jeeee: trying to release an
>> already released context
> 
> This is a bug of scdaemon.  I just fixed this.  This is due to the
> race conditions where release_application could be called multiple
> times.
> 
> 	commit: 0c1fd4e9884ed7c1edd1819762b9e8a77f606ed3
> 
Thanks, I’ll try this out, but will have to figure out how to build for OS-X (I’ve been using binaries from Patrick Brunschwig)
> But, I think that this "Ohhh jeeee" results the process of scdaemon
> (PID=32523) aborted.  Do you mean, you needed to kill the another
> scdaemon of PID=32745 in this case or the one of PID=32523?
> -- 

That’s a good question.  I’ve been using ‘killall’ so haven’t been tracking PIDs.

regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3583 bytes
Desc: not available
URL: </pipermail/attachments/20160718/d097a244/attachment.bin>