Re: scdaemon lockup with Yubikey NEO

2015-12-03 Thread the2nd 



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

2015-12-02 Thread the2nd 



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

2015-12-02 Thread NIIBE Yutaka 
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

2015-12-02 Thread Lance R. Vick 
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 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.
>
> =
> 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

2015-12-02 Thread the2nd 

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

2015-12-02 Thread NIIBE Yutaka 
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

2015-12-01 Thread the2nd 
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

2015-11-30 Thread NIIBE Yutaka 
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

2015-11-23 Thread the2nd 

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, the2nd  wrote:


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

2015-11-21 Thread Lance R. Vick 
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, the2nd  wrote:

> 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