Re: scdaemon lockup with Yubikey NEO
On 2015-12-03 03:54, NIIBE Yutaka wrote: On 12/02/2015 11:35 PM, the...@otpme.org wrote: No problem. I'm glad to help out and probably get a fix for this annoying issue. :) Thanks for your patience. Anyway, when Scdaemon detects card/token removal, it could finish existing connection(s). I'll consider fixing this. Sounds good. Should i open a bug report for this? Not needed. It's fixed in master. I'm going to backport this to 2.0. The commit is: f42c50dbf00c2e6298ca6830cbe6d36805fa54a3 Is there any workaround we can apply to fix this issue? Currently i am using a self compiled ssh client binary of openssh 6.7p1 as workaround. Well, I found another bug with PC/SC. Because of this bug, it is sometimes (not always) possible for gpg not to raise the error of "Conflicting usage". So, it would be a workaround to disable internal ccid driver of GnuPG and to use PC/SC. (I don't recommend, though.) Here is a backport patch which I'm considering to apply to 2.0. Thank you again for your cooperation fixing this long standing bug. Thank your for fixing it. :) Currently i will use the udev rule workaround from Lance. Is there any automatism that informs e.g. debian/ubuntu folks about such a backported fix? Does it make sense to open a debian/ubuntu bug report for this with reference to this thread? = diff --git a/scd/apdu.c b/scd/apdu.c index f9a1a2d..acca799 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -3136,7 +3136,13 @@ apdu_close_reader (int slot) return SW_HOST_NO_DRIVER; sw = apdu_disconnect (slot); if (sw) -return sw; +{ + /* + * When the reader/token was removed it might come here. + * It should go through to call CLOSE_READER even if we got an error. + */ + log_debug ("apdu_close_reader => 0x%x (apdu_disconnect)\n", sw); +} if (reader_table[slot].close_reader) return reader_table[slot].close_reader (slot); return SW_HOST_NOT_SUPPORTED; diff --git a/scd/app-common.h b/scd/app-common.h index e48db3c..ac2c2e9 100644 --- a/scd/app-common.h +++ b/scd/app-common.h @@ -44,11 +44,6 @@ struct app_ctx_s { operations the particular function pointer is set to NULL */ unsigned int ref_count; - /* Flag indicating that a reset has been done for that application - and that this context is merely lingering and just should not be - reused. */ - int no_reuse; - /* Used reader slot. */ int slot; diff --git a/scd/app.c b/scd/app.c index 742f937..380a347 100644 --- a/scd/app.c +++ b/scd/app.c @@ -190,9 +190,12 @@ application_notify_card_reset (int slot) /* FIXME: We are ignoring any error value here. */ lock_reader (slot, NULL); - /* Mark application as non-reusable. */ + /* Release the APP, as it's not reusable any more. */ if (lock_table[slot].app) -lock_table[slot].app->no_reuse = 1; +{ + deallocate_app (lock_table[slot].app); + lock_table[slot].app = NULL; +} /* Deallocate a saved application for that slot, so that we won't try to reuse it. If there is no saved application, set a flag so @@ -265,16 +268,6 @@ select_application (ctrl_t ctrl, int slot, const char *name, app_t *r_app) return gpg_error (GPG_ERR_CONFLICT); } - /* Don't use a non-reusable marked application. */ - if (app && app->no_reuse) -{ - unlock_reader (slot); - log_info ("lingering application `%s' in use by reader %d" -" - can't switch\n", -app->apptype? app->apptype:"?", slot); - return gpg_error (GPG_ERR_CONFLICT); -} - /* If we don't have an app, check whether we have a saved application for that slot. This is useful so that a card does not get reset even if only one session is using the card - this @@ -506,15 +499,7 @@ release_application (app_t app) if (lock_table[slot].last_app) deallocate_app (lock_table[slot].last_app); - if (app->no_reuse) -{ - /* If we shall not re-use the application we can't save it for - later use. */ - deallocate_app (app); - lock_table[slot].last_app = NULL; -} - else -lock_table[slot].last_app = lock_table[slot].app; + lock_table[slot].last_app = lock_table[slot].app; lock_table[slot].app = NULL; unlock_reader (slot); } ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scdaemon lockup with Yubikey NEO
On 2015-12-02 14:26, NIIBE Yutaka wrote: On 2015-12-02 at 12:36 +0100, the...@otpme.org wrote: here is the output for a failed session and a working one (with openssh 6.7p1). Both times i started two ssh sessions, keeping the first one open. Thank you very much. No problem. I'm glad to help out and probably get a fix for this annoying issue. :) Failed gpg-agent.log - http://paste.ubuntu.com/13620856/ There are three connections from SSH: (1) handler 0x557c807ec310 for fd 8 (2) handler 0x557c807eebb0 for fd 10 (3) handler 0x557c807eeb80 for fd 10 (fd 10 re-used) token removed | v (1) --> (2)--> (3)--> ** conflicting use scd.log - http://paste.ubuntu.com/13620863/ There are two connections from gpg-agent: (a) chan_7 from (1) (b) chan_9 from (3) token removed | v (a) --> (b)--> ** conflicting use The connection from SSH remains in gpg-agent by some reason. This is the reason why the connection from gpg-agent remains in Scdaemon, which results conflicting use. Anyway, when Scdaemon detects card/token removal, it could finish existing connection(s). I'll consider fixing this. Sounds good. Should i open a bug report for this? I don't know the exact reason why connection from SSH remains, though. I am unsure if it is yubikey specific but as it is working with older openssh versions i guess its some bug thats related to any openssh changes. From the logs, I don't think it's yubikey specific. If you say that this is not a gnupg issue i'll ask the yubico folks. But it would be really great to get any hint what could be the problem from someone who is familiar with the technical details. :) This is GnuPG issue, specifically, Scdaemon issue. Is there any workaround we can apply to fix this issue? Currently i am using a self compiled ssh client binary of openssh 6.7p1 as workaround. Thanks a lot for your help. Regards the2nd ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scdaemon lockup with Yubikey NEO
On 12/02/2015 11:35 PM, the...@otpme.org wrote: > No problem. I'm glad to help out and probably get a fix for this annoying > issue. :) Thanks for your patience. >> Anyway, when Scdaemon detects card/token removal, it could finish >> existing connection(s). I'll consider fixing this. > > Sounds good. Should i open a bug report for this? Not needed. It's fixed in master. I'm going to backport this to 2.0. The commit is: f42c50dbf00c2e6298ca6830cbe6d36805fa54a3 > Is there any workaround we can apply to fix this issue? Currently i > am using a self compiled ssh client binary of openssh 6.7p1 as > workaround. Well, I found another bug with PC/SC. Because of this bug, it is sometimes (not always) possible for gpg not to raise the error of "Conflicting usage". So, it would be a workaround to disable internal ccid driver of GnuPG and to use PC/SC. (I don't recommend, though.) Here is a backport patch which I'm considering to apply to 2.0. Thank you again for your cooperation fixing this long standing bug. = diff --git a/scd/apdu.c b/scd/apdu.c index f9a1a2d..acca799 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -3136,7 +3136,13 @@ apdu_close_reader (int slot) return SW_HOST_NO_DRIVER; sw = apdu_disconnect (slot); if (sw) -return sw; +{ + /* + * When the reader/token was removed it might come here. + * It should go through to call CLOSE_READER even if we got an error. + */ + log_debug ("apdu_close_reader => 0x%x (apdu_disconnect)\n", sw); +} if (reader_table[slot].close_reader) return reader_table[slot].close_reader (slot); return SW_HOST_NOT_SUPPORTED; diff --git a/scd/app-common.h b/scd/app-common.h index e48db3c..ac2c2e9 100644 --- a/scd/app-common.h +++ b/scd/app-common.h @@ -44,11 +44,6 @@ struct app_ctx_s { operations the particular function pointer is set to NULL */ unsigned int ref_count; - /* Flag indicating that a reset has been done for that application - and that this context is merely lingering and just should not be - reused. */ - int no_reuse; - /* Used reader slot. */ int slot; diff --git a/scd/app.c b/scd/app.c index 742f937..380a347 100644 --- a/scd/app.c +++ b/scd/app.c @@ -190,9 +190,12 @@ application_notify_card_reset (int slot) /* FIXME: We are ignoring any error value here. */ lock_reader (slot, NULL); - /* Mark application as non-reusable. */ + /* Release the APP, as it's not reusable any more. */ if (lock_table[slot].app) -lock_table[slot].app->no_reuse = 1; +{ + deallocate_app (lock_table[slot].app); + lock_table[slot].app = NULL; +} /* Deallocate a saved application for that slot, so that we won't try to reuse it. If there is no saved application, set a flag so @@ -265,16 +268,6 @@ select_application (ctrl_t ctrl, int slot, const char *name, app_t *r_app) return gpg_error (GPG_ERR_CONFLICT); } - /* Don't use a non-reusable marked application. */ - if (app && app->no_reuse) -{ - unlock_reader (slot); - log_info ("lingering application `%s' in use by reader %d" -" - can't switch\n", -app->apptype? app->apptype:"?", slot); - return gpg_error (GPG_ERR_CONFLICT); -} - /* If we don't have an app, check whether we have a saved application for that slot. This is useful so that a card does not get reset even if only one session is using the card - this @@ -506,15 +499,7 @@ release_application (app_t app) if (lock_table[slot].last_app) deallocate_app (lock_table[slot].last_app); - if (app->no_reuse) -{ - /* If we shall not re-use the application we can't save it for - later use. */ - deallocate_app (app); - lock_table[slot].last_app = NULL; -} - else -lock_table[slot].last_app = lock_table[slot].app; + lock_table[slot].last_app = lock_table[slot].app; lock_table[slot].app = NULL; unlock_reader (slot); } -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scdaemon lockup with Yubikey NEO
I came up with the following udev rule which, while heavy handed, solves these issues for me: https://gist.github.com/lrvick/d1a5a8e6cf0eefda69d7 On Wed, Dec 2, 2015 at 6:54 PM, NIIBE Yutakawrote: > On 12/02/2015 11:35 PM, the...@otpme.org wrote: > > No problem. I'm glad to help out and probably get a fix for this > annoying issue. :) > > Thanks for your patience. > > >> Anyway, when Scdaemon detects card/token removal, it could finish > >> existing connection(s). I'll consider fixing this. > > > > Sounds good. Should i open a bug report for this? > > Not needed. It's fixed in master. I'm going to backport this to 2.0. > > The commit is: f42c50dbf00c2e6298ca6830cbe6d36805fa54a3 > > > Is there any workaround we can apply to fix this issue? Currently i > > am using a self compiled ssh client binary of openssh 6.7p1 as > > workaround. > > Well, I found another bug with PC/SC. Because of this bug, it is > sometimes (not always) possible for gpg not to raise the error of > "Conflicting usage". So, it would be a workaround to disable internal > ccid driver of GnuPG and to use PC/SC. (I don't recommend, though.) > > Here is a backport patch which I'm considering to apply to 2.0. > > Thank you again for your cooperation fixing this long standing bug. > > = > diff --git a/scd/apdu.c b/scd/apdu.c > index f9a1a2d..acca799 100644 > --- a/scd/apdu.c > +++ b/scd/apdu.c > @@ -3136,7 +3136,13 @@ apdu_close_reader (int slot) > return SW_HOST_NO_DRIVER; >sw = apdu_disconnect (slot); >if (sw) > -return sw; > +{ > + /* > + * When the reader/token was removed it might come here. > + * It should go through to call CLOSE_READER even if we got an > error. > + */ > + log_debug ("apdu_close_reader => 0x%x (apdu_disconnect)\n", sw); > +} >if (reader_table[slot].close_reader) > return reader_table[slot].close_reader (slot); >return SW_HOST_NOT_SUPPORTED; > diff --git a/scd/app-common.h b/scd/app-common.h > index e48db3c..ac2c2e9 100644 > --- a/scd/app-common.h > +++ b/scd/app-common.h > @@ -44,11 +44,6 @@ struct app_ctx_s { > operations the particular function pointer is set to NULL */ >unsigned int ref_count; > > - /* Flag indicating that a reset has been done for that application > - and that this context is merely lingering and just should not be > - reused. */ > - int no_reuse; > - >/* Used reader slot. */ >int slot; > > diff --git a/scd/app.c b/scd/app.c > index 742f937..380a347 100644 > --- a/scd/app.c > +++ b/scd/app.c > @@ -190,9 +190,12 @@ application_notify_card_reset (int slot) >/* FIXME: We are ignoring any error value here. */ >lock_reader (slot, NULL); > > - /* Mark application as non-reusable. */ > + /* Release the APP, as it's not reusable any more. */ >if (lock_table[slot].app) > -lock_table[slot].app->no_reuse = 1; > +{ > + deallocate_app (lock_table[slot].app); > + lock_table[slot].app = NULL; > +} > >/* Deallocate a saved application for that slot, so that we won't > try to reuse it. If there is no saved application, set a flag so > @@ -265,16 +268,6 @@ select_application (ctrl_t ctrl, int slot, const char > *name, app_t *r_app) > return gpg_error (GPG_ERR_CONFLICT); >} > > - /* Don't use a non-reusable marked application. */ > - if (app && app->no_reuse) > -{ > - unlock_reader (slot); > - log_info ("lingering application `%s' in use by reader %d" > -" - can't switch\n", > -app->apptype? app->apptype:"?", slot); > - return gpg_error (GPG_ERR_CONFLICT); > -} > - >/* If we don't have an app, check whether we have a saved > application for that slot. This is useful so that a card does > not get reset even if only one session is using the card - this > @@ -506,15 +499,7 @@ release_application (app_t app) > >if (lock_table[slot].last_app) > deallocate_app (lock_table[slot].last_app); > - if (app->no_reuse) > -{ > - /* If we shall not re-use the application we can't save it for > - later use. */ > - deallocate_app (app); > - lock_table[slot].last_app = NULL; > -} > - else > -lock_table[slot].last_app = lock_table[slot].app; > + lock_table[slot].last_app = lock_table[slot].app; >lock_table[slot].app = NULL; >unlock_reader (slot); > } > -- > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Lance R. Vick __ Cell - 407.283.7596 Gtalk - la...@lrvick.net Website - http://lrvick.net PGP Key - http://lrvick.net/0x36C8AAA9.asc keyserver - subkeys.pgp.net __ ___ Gnupg-users mailing list Gnupg-users@gnupg.org
Re: scdaemon lockup with Yubikey NEO
Hi, here is the output for a failed session and a working one (with openssh 6.7p1). Both times i started two ssh sessions, keeping the first one open. Failed gpg-agent.log - http://paste.ubuntu.com/13620856/ scd.log - http://paste.ubuntu.com/13620863/ OK gpg-agent.log - http://paste.ubuntu.com/13621007/ scd.log - http://paste.ubuntu.com/13621013/ I am unsure if it is yubikey specific but as it is working with older openssh versions i guess its some bug thats related to any openssh changes. The log always shows "error getting default authentication keyID of card: Conflicting use" when the problem occurs. If you say that this is not a gnupg issue i'll ask the yubico folks. But it would be really great to get any hint what could be the problem from someone who is familiar with the technical details. :) regards the2nd On 2015-12-02 08:16, NIIBE Yutaka wrote: On 2015-12-01 at 11:55 +0100, the...@otpme.org wrote: There is just one gpg-agent + scdaemon. OK. Do you keep the first SSH session open when re-plugging the yubikey? I don't use Yubikey. I use OpenPGPcard with card reader and Gnuk Token. If you think your problem is Yubikey specific, it would be good to ask Yubikey community. I keep the SSH session when I remove my token, re-insert it and. I also tried with the setting of 'ForwardAgent yes' in .ssh/config and used SSH to another remote host. But I can't reproduce. To debug your situation, please add 'verbose' in your .gnupg/gpg-agent.conf and create a file .gnupg/scdaemon.conf with: = debug-level guru debug-all log-file/tmp/scd.log = Before your experiment, please set your PIN by default one, because the scd.log file will include your PIN information. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scdaemon lockup with Yubikey NEO
On 2015-12-02 at 12:36 +0100, the...@otpme.org wrote: > here is the output for a failed session and a working one (with > openssh > 6.7p1). > Both times i started two ssh sessions, keeping the first one open. Thank you very much. > Failed > gpg-agent.log - http://paste.ubuntu.com/13620856/ There are three connections from SSH: (1) handler 0x557c807ec310 for fd 8 (2) handler 0x557c807eebb0 for fd 10 (3) handler 0x557c807eeb80 for fd 10 (fd 10 re-used) token removed | v (1) --> (2)--> (3)--> ** conflicting use > scd.log - http://paste.ubuntu.com/13620863/ There are two connections from gpg-agent: (a) chan_7 from (1) (b) chan_9 from (3) token removed | v (a) --> (b)--> ** conflicting use The connection from SSH remains in gpg-agent by some reason. This is the reason why the connection from gpg-agent remains in Scdaemon, which results conflicting use. Anyway, when Scdaemon detects card/token removal, it could finish existing connection(s). I'll consider fixing this. I don't know the exact reason why connection from SSH remains, though. > I am unsure if it is yubikey specific but as it is working with older > openssh versions i guess its some bug thats related to any openssh > changes. From the logs, I don't think it's yubikey specific. > If you say that this is not a gnupg issue i'll ask the yubico folks. > But it would be really great to get any hint what could be the > problem > from someone who is familiar with the technical details. :) This is GnuPG issue, specifically, Scdaemon issue. -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scdaemon lockup with Yubikey NEO
There is just one gpg-agent + scdaemon. Do you keep the first SSH session open when re-plugging the yubikey? If i close the first session do problem does not occur. On 2015-12-01 05:16, NIIBE Yutaka wrote: On 12/01/2015 08:19 AM, the...@otpme.org wrote: So are any devs reading on this list? The problem is reproducible and i am willing to help debugging and whatever is needed to fix the issue. :) Yes. It is not reproducible for me. I'm using OpenSSH 6.9p1. i've done some more testing and found out that the problem starts to exist with openssh version 6.8p1. With 6.7p1 everything works perfect. I downloaded the openssh tarballs one by one, compiled with ./configure;make and just copied the "ssh" binary. I was able to reproduce the problem with the following steps: 1. Start gpg-agent: eval $(gpg-agent --daemon --enable-ssh-support --log-file ~/.gnupg/gpg-agent.log) 2. Login to any host with your SSH key and keep the session open: ssh -l root localhost 3. Plug your yubikey out/in 4. Try to login with your SSH key to any other host Do you have multiple gpg-agent when you encounter failure? Or multiple scdaemon? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scdaemon lockup with Yubikey NEO
On 12/01/2015 08:19 AM, the...@otpme.org wrote: > So are any devs reading on this list? The problem is reproducible > and i am willing to help debugging and whatever is needed to fix the > issue. :) Yes. It is not reproducible for me. I'm using OpenSSH 6.9p1. >> i've done some more testing and found out that the problem starts to >> exist with openssh version 6.8p1. With 6.7p1 everything works perfect. >> I downloaded the openssh tarballs one by one, compiled with >> ./configure;make and just copied the "ssh" binary. >> >> I was able to reproduce the problem with the following steps: >> >> 1. Start gpg-agent: eval $(gpg-agent --daemon --enable-ssh-support >> --log-file ~/.gnupg/gpg-agent.log) >> 2. Login to any host with your SSH key and keep the session open: ssh >> -l root localhost >> 3. Plug your yubikey out/in >> 4. Try to login with your SSH key to any other host Do you have multiple gpg-agent when you encounter failure? Or multiple scdaemon? -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scdaemon lockup with Yubikey NEO
Hi, i've done some more testing and found out that the problem starts to exist with openssh version 6.8p1. With 6.7p1 everything works perfect. I downloaded the openssh tarballs one by one, compiled with ./configure;make and just copied the "ssh" binary. I was able to reproduce the problem with the following steps: 1. Start gpg-agent: eval $(gpg-agent --daemon --enable-ssh-support --log-file ~/.gnupg/gpg-agent.log) 2. Login to any host with your SSH key and keep the session open: ssh -l root localhost 3. Plug your yubikey out/in 4. Try to login with your SSH key to any other host With openssh 6.8p1 this fails reproducable. With version 6.7p1 or earlier it works. As a workaround i replaced my ssh client binary with the old version. It would be great to get a real fix for this. But i am unsure where the realm problem lies, gpg or openssh. Maybe we should ask this on the openssh list? regards the2nd On 2015-11-22 03:06, Lance R. Vick wrote: This happens to me constantly as well. I my case I frequently need to kill and restart gpg-agent to get things working again on both Arch Linux and Gentoo. On Sat, Nov 21, 2015 at 4:41 AM, the2ndwrote: Hi Ben, We have a similar Problem since we've upgraded from Ubuntu 15.04 to 15.10. When starting gpg-agent with --log-file the log show the following: 2015-05-30 13:49:36 gpg-agent[3600] error accessing card: Conflicting use 2015-05-30 13:49:36 gpg-agent[3600] smartcard signing failed: Conflicting use 2015-05-30 13:49:38 gpg-agent[3600] error getting default authentication keyID of card: Conflicting use I've asked the list serval times about this issue but got now answer yet. So i dont have a solution but it may be interesting if your problem is the same... Regards The2nd Ursprüngliche Nachricht Von: Ben Warren Datum:11.20.2015 16:26 (GMT+01:00) An: gnupg-users@gnupg.org Betreff: scdaemon lockup with Yubikey NEO Hi, I’ve noticed several other problem reports that seem similar, hopefully they’re all related and there’s a simple fix. The problem: After an indeterminate amount of time (sometimes minutes, sometimes hours), any GPG operation that uses my Yubikey NEO device hangs. The two most common operations are SSH authentication and git signing. The following sequence gets things going again: $ killall -SIGKILL scdaemon $ gpg2 —card-status System particulars: * Host OS is OS-X Yosemite, although it is also present on Mavericks (haven’t tried El Capitan yet) * GPG 2.1.5 * Using the Yubikey’s authentication subkey to login to remote Linux hosts * Using the Yubikey’s signing subkey for git signing operations, both local and remote * Using gpg-agent for forwarding both GPG and SSH (great features, BTW!) GPG configuration file: $ cat ~/.gnupg/gpg-agent.conf default-cache-ttl 1 ignore-cache-for-signing no-allow-external-cache max-cache-ttl 1 extra-socket ${HOME}/.gnupg/S.gpg-extra-agent debug-all log-file ${HOME}/.gnupg/mygpglogfile.log enable-ssh-support I’ll be happy to help debug this, but need some guidance. thanks, Ben ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users [1] -- Lance R. Vick __ Cell - 407.283.7596 Gtalk - la...@lrvick.net Website - http://lrvick.net [2] PGP Key - http://lrvick.net/0x36C8AAA9.asc [3] keyserver - subkeys.pgp.net [4] __ Links: -- [1] http://lists.gnupg.org/mailman/listinfo/gnupg-users [2] http://lrvick.net [3] http://lrvick.net/0x36C8AAA9.asc [4] http://subkeys.pgp.net ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: scdaemon lockup with Yubikey NEO
This happens to me constantly as well. I my case I frequently need to kill and restart gpg-agent to get things working again on both Arch Linux and Gentoo. On Sat, Nov 21, 2015 at 4:41 AM, the2ndwrote: > Hi Ben, > > We have a similar Problem since we've upgraded from Ubuntu 15.04 to > 15.10. When starting gpg-agent with --log-file the log show the following: > > 2015-05-30 13:49:36 gpg-agent[3600] error accessing card: Conflicting use > 2015-05-30 13:49:36 gpg-agent[3600] smartcard signing failed: > Conflicting use > 2015-05-30 13:49:38 gpg-agent[3600] error getting default authentication > keyID of card: Conflicting use > > I've asked the list serval times about this issue but got now answer yet. > So i dont have a solution but it may be interesting if your problem is the > same... > > Regards > The2nd > > > Ursprüngliche Nachricht > Von: Ben Warren > Datum:11.20.2015 16:26 (GMT+01:00) > An: gnupg-users@gnupg.org > Betreff: scdaemon lockup with Yubikey NEO > > Hi, > > I’ve noticed several other problem reports that seem similar, hopefully > they’re all related and there’s a simple fix. > > The problem: > > After an indeterminate amount of time (sometimes minutes, sometimes > hours), any GPG operation that uses my Yubikey NEO device hangs. The two > most common operations are SSH authentication and git signing. The > following sequence gets things going again: > > $ killall -SIGKILL scdaemon > > $ gpg2 —card-status > > System particulars: > > >- Host OS is OS-X Yosemite, although it is also present on Mavericks >(haven’t tried El Capitan yet) >- GPG 2.1.5 >- Using the Yubikey’s authentication subkey to login to remote Linux >hosts >- Using the Yubikey’s signing subkey for git signing operations, both >local and remote >- Using gpg-agent for forwarding both GPG and SSH (great features, >BTW!) > > > GPG configuration file: > > $ cat ~/.gnupg/gpg-agent.conf > > default-cache-ttl 1 > > ignore-cache-for-signing > > no-allow-external-cache > > max-cache-ttl 1 > > extra-socket ${HOME}/.gnupg/S.gpg-extra-agent > > debug-all > > log-file ${HOME}/.gnupg/mygpglogfile.log > > enable-ssh-support > > > I’ll be happy to help debug this, but need some guidance. > > > thanks, > > Ben > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- Lance R. Vick __ Cell - 407.283.7596 Gtalk - la...@lrvick.net Website - http://lrvick.net PGP Key - http://lrvick.net/0x36C8AAA9.asc keyserver - subkeys.pgp.net __ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users