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