from:"the2nd"

Re: Yubikey, GnuPG 2.1 Modern, and SSH on OS X

2016-01-15 Thread the2nd

You might hit this bug: 
http://lists.gnupg.org/pipermail/gnupg-users/2015-December/054756.html


On 2016-01-15 01:08, Glenn Rempe wrote:

I recently setup my own Mac w/ gnupg 2.1.10, and I am using a Yubikey
to manage my gpg private keys and I am using that key for SSH auth. 
I have it all up and running but I ran into some issues as well so I
wrote up a blog post.  I'd appreciate any suggestions for improvement
and especially for any ideas for a better fix for the workaround I had
to do that I documented at the end of the post.  Maybe this will be
of some use to those wanting to use the latest gpg for SSH auth on a
Mac with a Yubikey.

https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/ [1]

Here is a discussion thread that describes *exactly* the issue I am
still having (if I don't use my workaround to kill and restart
gpg-agent on every yubikey insertion and deletion):

https://lists.gnupg.org/pipermail/gnupg-users/2015-June/053796.html
[2]

Glenn



Links:
--
[1] https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/
[2] https://lists.gnupg.org/pipermail/gnupg-users/2015-June/053796.html

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Yubikey, GnuPG 2.1 Modern, and SSH on OS X

2016-01-15 Thread the2nd

I just want to point out that one may want to add the keygrip to the 
sshcontrol file along with the "confirm" option to get asked by pinentry 
each time ssh requests gpg-agent to sign an ssh challenge (e.g. a ssh 
login). This is at least a useful option if you login to a remote host 
with agent forwarding enabled. I know that there are more secure 
alternatives to agent forwarding but i guess it is still used because of 
its simplicity. I also use it from time to time *shame*


But thats the only reason in know why one would add it to sshcontrol.

Regards
the2nd

On 2016-01-16 00:47, Glenn Rempe wrote:

Thanks Peter, I was not aware of that (and it certainly explains the
double entry in ssh-add -l.

btw, Werner was not writing that response to me. It was just pointed
out to me, so yes it was
probably not smart card specific I would guess. I'll update the blog
post to reflect that we
probably do not need to modify sshcontrol for use with Yubikey.

Back to the main issue I am having. I followed the instructions to
output a verbose scdaemon log
which I was exercising this issue.  Here is a gist with the commands
I was running and the resulting
logfile.

https://gist.github.com/grempe/e143796b8f399f5fa391 [5]

Perhaps NIIBE Yutaka or someone else more knowledgable than I can
take a look and 
get us closer to resolution. :-)

Thanks for everyone who is helping.

On Fri, Jan 15, 2016 at 3:08 PM Peter Lebbing
<pe...@digitalbrains.com> wrote:


On 15/01/16 21:17, Glenn Rempe wrote:

I added it at the suggestion of Werner in this post:



https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html
[1]


And these blog posts:
http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html

[2]



http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key
[3]


Is this suggestion outdated?


No, but I'm fairly sure Werner did not realise you were using a
smartcard when
he wrote that. Obviously, I can't look into the man's mind, but
that's my guess.

For regular, on-disk keys, it is necessary to add the keygrip to
sshcontrol. For
smartcards, it's automatically added when the smartcard is
inserted. I guess it
fits with automatically added secret key stubs when the smartcard
is inserted
(to use a smartcard on a fresh PC, import your own public key,
insert your
smartcard, and you're done).

HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at
<http://digitalbrains.com/2012/openpgp-key-peter [4]>



Links:
--
[1] https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html
[2] http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html
[3] http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key
[4] http://digitalbrains.com/2012/openpgp-key-peter
[5] https://gist.github.com/grempe/e143796b8f399f5fa391

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 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-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-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 <the...@otpme.org> 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

AW: scdaemon lockup with Yubikey NEO

2015-11-21 Thread the2nd

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 
<biggerbadder...@gmail.com> 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

Re: gpg-agent: error accessing card: Conflicting use

2015-11-20 Thread the2nd


Hi,

now i have the same problem on my ubuntu installation at work. I've 
updated to ubuntu 15.10 and now it happens from time to time just like 
on my sabayon installation. But as i dont use the OTP feature of the 
yubikey at work i can say for sure that the problem exists without 
pressing the yubikey button. Also it happens without yubikey pull out 
and it is not related to my yubikey because a colleague of mine has the 
same problem after upgrading to ubuntu 15.10.


GPG version is 1.4.18.

Any help is appreciated.

regards
the2nd

On 2015-08-11 20:10, the...@otpme.org wrote:

Hi again :)

nobody else with this problem?



On 2015-05-30 14:25, the...@otpme.org wrote:

Hi,

i have a problem with gpg-agent when using it with a yubikey neo.
after some time gpg-agent refuses to sign any data and so any ssh
login with my key stored on the yubikey will fail. the gpg-agent log
shows the following messages:

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

the command to start gpg-agent on KDE login is:
eval "$(/usr/bin/gpg-agent --daemon --enable-ssh-support --log-file
~/.gnupg/gpg-agent.log)"

i haven't found the exact circumstances when it happens but its more
likely to happen when the yubikey was plugged off and re-inserted, but
it also happens without pull off from time to time. a restart of
gpg-agent fixes the issue. it also often happens after i've pressed
the yubikey button to generate an OTP but not always.

gnupg version is 2.0.27-r1 running on sabayon linux.

when using the same yubikey on my ubuntu 14.04 notebook at work i
never had this problem.

thanks for any help.

regards
the2nd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: Re: Smartcard power-down

2015-09-12 Thread the2nd

Thanks for your help. This works great! :)

 Ursprüngliche Nachricht Von: NIIBE Yutaka 
 Datum:09.10.2015  03:13  (GMT+01:00) 
An: gnupg-users@gnupg.org Betreff: Re: Smartcard 
power-down 
On 09/10/2015 05:57 AM, the...@otpme.org wrote:
> pointing out that a "gpgconf --reload scdaemon" should power-down a
> connected smartcard and thus lead to re-asking the PIN. I've tried
> this with a yubikey neo but does not work. I've also tried sending
> SIGHUP to scdaemon as well as gpg-agent but i never get re-asked for
> the PIN when doing a ssh login. After restarting gpg-agent i always
> get asked for the PIN so it seems to work in general. Is there
> anything i can check?

I'm sorry, now, "gpgconf --reload scdaemon" doesn't work in GnuPG 2.0,
because of a bug.

For a while, please do:

   $ gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye

This stops scdaemon.


I've just committed the fix to 2.0 branch.

gpgconf: Fix scdaemon reload.

* tools/gpgconf-comp.c (scdaemon_runtime_change): Add "scd bye".

--

In GnuPG 2.0.x, it doesn't require newer libassuan which has
ASSUAN_FORCE_CLOSE feature.  We need to send "scd bye" to let
the control finish from command loop.

diff --git a/tools/gpgconf-comp.c b/tools/gpgconf-comp.c
index 2454f93..69d160e 100644
--- a/tools/gpgconf-comp.c
+++ b/tools/gpgconf-comp.c
@@ -1064,7 +1064,7 @@ scdaemon_runtime_change (void)
{
   gpg_error_t err;
   const char *pgmname;
-  const char *argv[6];
+  const char *argv[7];
   pid_t pid;

   /* We use "GETINFO app_running" to see whether the agent is already
@@ -1077,8 +1077,9 @@ scdaemon_runtime_change (void)
   argv[1] = "GETINFO scd_running";
   argv[2] = "/if ${! $?}";
   argv[3] = "scd killscd";
-  argv[4] = "/end";
-  argv[5] = NULL;
+  argv[4] = "scd bye";
+  argv[5] = "/end";
+  argv[6] = NULL;

   err = gnupg_spawn_process_fd (pgmname, argv, -1, -1, -1, );
   if (!err)
-- 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Smartcard power-down

2015-09-09 Thread the2nd


Hi,

i found this thread 
(https://lists.gnupg.org/pipermail/gnupg-users/2014-September/050811.html) 
pointing out that a "gpgconf --reload scdaemon" should power-down a 
connected smartcard and thus lead to re-asking the PIN. I've tried this 
with a yubikey neo but does not work. I've also tried sending SIGHUP to 
scdaemon as well as gpg-agent but i never get re-asked for the PIN when 
doing a ssh login. After restarting gpg-agent i always get asked for the 
PIN so it seems to work in general. Is there anything i can check?


regards
the2nd

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Yubikey, GnuPG 2.1 Modern, and SSH on OS X

Re: Yubikey, GnuPG 2.1 Modern, and SSH on OS X

Re: scdaemon lockup with Yubikey NEO

Re: scdaemon lockup with Yubikey NEO

Re: scdaemon lockup with Yubikey NEO

Re: scdaemon lockup with Yubikey NEO

Re: scdaemon lockup with Yubikey NEO

AW: scdaemon lockup with Yubikey NEO

Re: gpg-agent: error accessing card: Conflicting use

AW: Re: Smartcard power-down

Smartcard power-down

11 matches

Site Navigation

Mail list logo

Footer information