Why exactly does pinentry fails with gpg-agent and ssh support?

Werner Koch wk at gnupg.org
Mon Jan 22 08:43:41 CET 2018


On Sun, 21 Jan 2018 17:41, doron.behar at gmail.com said:

> As far as I understand, because I use `systemd`'s user service, whenever
> I want to unlock an authentication key I need to run the command
> `gpg-connect-agent updatestartuptty /bye`.

Although I have no experience with the peculiarities of the --supervised
mode, there is no need to run the updatestartuptty command.  That command
is only used to switch gpg-agent's default $DISPLAY and tty to the one
active in the shell you run this command.  This is required because the
ssh-agent protocol has no way to tell gpg-agent (or ssh-agent) the
DISPLAY/tty which shall be used to pop-up the Pinentry.

Another problem with ssh is that ssh can't start gpg-agent on the the
fly.  Thus you need to make sure that gpg-agent has already been started
when you use ssh.  A way to ensure this is to run 

  gpg -K

which lists all your private keys and as a side-effects starts
gpg-agent.  You can also do

  gpg-connect-agent /bye

because it exhibits the same side-effect.  The suggested way to start
gpg-agent for ssh is to use

  gpgconf --launch gpg-agent


Salam-Shalom,

   Werner


p.s.
And the best solution would be to extended the ssh-agent protocol
and openssh to allow starting of an arbitrary process and conveying some
environment variables.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180122/244b53c5/attachment.sig>


More information about the Gnupg-users mailing list