[pkg-gnupg-maint] Bug#841909: Bug#841909: /usr/bin/gpg: Configuration error over ssh
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Oct 24 17:57:24 UTC 2016
Control: tags 841909 + moreinfo
Hi Craig--
On Mon 2016-10-24 07:13:25 -0400, Craig Small wrote:
> Since the latest upgrade, I am unable to sign anything using a ssh
> shell.
>
> $ gpg --sign gpg.txt
> File 'gpg.txt.gpg' exists. Overwrite? (y/N) y
> gpg: signing failed: Configuration error
> gpg: signing failed: Configuration error
>
> There is a work-around
> ssh to the remote system
> killall gpg-agent
> unset DBUS_SESSION_BUS_ADDRESS
> gpg will now work.
>
> I am unsure why this environment variable causes the problem. It has
> something to do with the gpg-agent not gpg itself.
>
> I tried it with two ssh sessions, one running gpg and one running gpg
> agent. If the agent had that variable unset, it worked even if the
> window running gpg itself had it set. The other way around it failed
> meaning gpg-agent and not gpg itself has the problem with the
> environment.
>
> This is gpg-agent with the environment vatiable set.
>
> gpg-agent --verbose --homedir /home/csmall/.gnupg --use-standard-socket --daemon /bin/bash
> gpg-agent[28745]: WARNING: "--use-standard-socket" is an obsolete option - it has no effect
> gpg-agent[28745]: listening on socket '/run/user/1000/gnupg/S.gpg-agent'
> gpg-agent[28745]: listening on socket '/run/user/1000/gnupg/S.gpg-agent.rstrd'
> gpg-agent[28745]: listening on socket '/run/user/1000/gnupg/S.gpg-agent.brwsr'
> gpg-agent[28745]: listening on socket '/run/user/1000/gnupg/S.gpg-agent.ssh'
> gpg-agent[28746]: gpg-agent (GnuPG) 2.1.15 started
> $ gpg-agent[28746]: handler 0x7f347273d700 for fd 8 started
> gpg-agent[28746]: starting a new PIN Entry
> gpg-agent[28746]: failed to unprotect the secret key: Configuration error
> gpg-agent[28746]: failed to read the secret key
> gpg-agent[28746]: command 'PKSIGN' failed: Configuration error <Pinentry>
> gpg-agent[28746]: handler 0x7f347273d700 for fd 8 terminated
> gpg-agent[28746]: handler 0x7f3471f3c700 for fd 9 started
> gpg-agent[28746]: handler 0x7f3471f3c700 for fd 9 terminated
It sounds to me like what you're seeing is pinentry-gnome3, which knows
to fall back to curses if DBUS_SESSION_BUS_ADDRESS is unset, but which
fails when run with an active DBUS session but no way to prompt the
user.
I'd like to confirm this, though: what version(s) of pinentry do you
have installed on the system in question? what is the default pinentry?
dpkg -l 'pinentry-*'
readlink -f $(which pinentry)
additionally, you could try adding debug-pinentry to the gpg-agent
config, to see if there's any additional information provided.
If my guess is correct and you're using pinentry-gnome3 but the system
doesn't have gcr running or available, you might try the attached patch
to pinentry-gnome3. i proposed the it to upstream but there's been some
pushback. If you could confirm that it works for you in this context
that'd be good to know.
Alternately, try specifying pinentry-curses as your preferred pinentry
on the remote machine, either via pinentry-program (in gpg-agent.conf)
or via "update-alternatives --config pinentry", or by just purging all
the graphical pinentries and leaving only pinentry-curses (if your
machine never has a graphical environment available).
let me know what you find!
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0011-pinentry-gnome3-fall-back-to-curses-if-gcr-prompt-cr.patch
Type: text/x-diff
Size: 2778 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161024/55858667/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161024/55858667/attachment.sig>
More information about the pkg-gnupg-maint
mailing list