I'm not sure when the use of sshcontrol emerged. My impression was that it
is only used as part of GnuPG 'Modern' 2.1.x versions. That being said, If
I remove the keygrip entry from the sshcontrol file it appears to work
fine. The only difference I've just noticed is in the output of 'ssh-add
-l':
with keygrip in sshcontrol:
~/.gnupg$ ssh-add -l
error fetching identities for protocol 1: agent refused operation
2048 SHA256:X3YiWulZ1xJlqGRFqeaQOmLuZvyfJV/r7Qwo/kmUgCg cardio:000MYCARDNUM
(RSA)
2048 SHA256:X3YiWulZ1xJlqGRFqeaQOmLuZvyfJV/r7Qwo/kmUgCg (none) (RSA)
without key grip in sshcontrol:
~/.gnupg$ ssh-add -l
error fetching identities for protocol 1: agent refused operation
2048 SHA256:X3YiWulZ1xJlqGRFqeaQOmLuZvyfJV/r7Qwo/kmUgCg cardno:000MYCARDNUM
(RSA)
Any ideas for also eliminating that error message, or understanding why its
there are appreciated.
As for the suggestion by the2nd at otpme.org regarding the scdaemon bug.
This sounded promising, but when I investigated a bit it seems that the
commit in that thread that indicated this issue might be fixed on master
(f42c50dbf00c2e6298ca6830cbe6d36805fa54a3) was committed on Dec 2, 2015,
and gnupg version 2.1.10 was tagged on Dec 4, 2015. So that fix should
already be in the version of GnuPG I am using (2.1.10) and yet I am still
seeing a problem.
/tmp/gnupg (master ✔)$ git log f42c50dbf00c2e6298ca6830cbe6d36805fa54a3
commit f42c50dbf00c2e6298ca6830cbe6d36805fa54a3
Author: NIIBE Yutaka <gni...@fsij.org>
Date: Thu Dec 3 11:26:24 2015 +0900
scd: Fix "Conflicting usage" bug.
* scd/apdu.c (apdu_close_reader): Call CLOSE_READER method even if we
got an error from apdu_disconnect.
* scd/app-common.h (no_reuse): Remove.
* scd/app.c (application_notify_card_reset): Deallocate APP here.
(select_application, release_application): Don't use NO_REUSE.
--
Reproducible scenario: Invoke gpg --card-edit session from a terminal.
Invoke another gpg --card-edit session from another. Remove a token.
Insert a token again. Type RET on both terminals. One of terminal
answers "Conflicting usage".
Perhaps, having NO_REUSE field was to avoid race conditions. Now,
APP can be safely deallocated by application_notify_card_reset.
Thanks to the2nd.
I installed 2.1.10 from this homebrew recipe:
https://github.com/Homebrew/homebrew-versions/blob/master/gnupg21.rb
My SSH client is the one that comes with OS X 'El Capitan':
/tmp/gnupg (master ✔)$ ssh -V
OpenSSH_6.9p1, LibreSSL 2.1.8
On Fri, Jan 15, 2016 at 12:31 PM Simon Josefsson <si...@josefsson.org>
wrote:
> > > Why do you add the keygrip to the sshcontrol file? I have never
> > > needed that step. For me it uses the right key directly. Is it
> > > because you have another (revoked) A subkey? It sounds somewhat of
> > > sub-optimal behaviour for gpg-agent's SSH support to use a revoked
> > > key instead of the non-revoked key.
> >
> > I do have a revoked Authentication sub-key on my primary key, but I
> > no longer use it and that is also not why I added the keygrip entry to
> > sshcontrol file. I added it at the suggestion of Werner in this post:
> >
> > https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html
> >
> > And these blog posts:
> > http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html
> > http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key
> >
> > Is this suggestion outdated?
>
> I don't recall ever using it, and I've been using SSH with smartcards
> through gpg-agent for over 10 years. What happens if you drop that
> part? For me it has always selected the right subkey automatically.
>
> /Simon
>
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
