Why exactly does pinentry fails with gpg-agent and ssh support?
andre at colomb.de
Mon Jan 22 09:36:34 CET 2018
On 2018-01-22 08:43, Werner Koch wrote:
>> 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.
I can confirm that it actually IS necessary to send "updatestartuptty"
for ssh-agent functionality to work in this scenario. The gpg-agent
process started by systemd's user session has no $DISPLAY and no
$GPG_TTY set (looking at /proc/###/environ). Its cmdline does not
contain --supervised either.
I always wondered why I got the message "agent refused operation" when
using an SSH key from gpg-agent. Restarting gpg-agent manually after
logging in was my workaround thus far, but today I found out that
Strange thing is, I could use the GPG part of gpg-agent already before
issuing that command. Why does that behave differently?
Can something be done to the systemd user unit file so the process gets
told the correct $DISPLAY at least?
From: André Colomb <andre at colomb.de>
More information about the Gnupg-users