using gpg 2.1 under su or sudo
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Apr 1 17:56:08 CEST 2016
Some server administrators connect to their machines via ssh, and then
use sudo or su to switch to a different user account for administering
For example, the qux service for example.org might be running as the
quxd user on machine.example.org; an admin might "ssh
machine.example.org" and then "su - quxd" to configure or administer the
if the service administration requires the use of GnuPG with secret key
material (key generation, signing, encryption, certification, etc) and
the administrator is using "modern" GnuPG (the 2.1 branch or later) then
they're likely to have a problem because of gpg-agent.
in this situation:
* there is no X11 session
* it's unlikely that there is a user dbus session running for quxd
* there may be no system dbus session at all
* the TTY attached to the console is owned by the admin's account
(thanks to sshd), not by quxd, so while the quxd shell (and spawned
subprocesses) can read and write to it thanks to inheriting the file
descriptors, the backgrounded gpg-agent has closed those file
descriptors and its spawned pinentry cannot connect to the pty even
to display the curses fallback.
So there appears to be no way for gpg-agent to prompt the user via any
sort of normal pinentry here.
Does anyone have a suggestion about how to facilitate this particular
One approach is:
echo 'allow-loopback-pinentry:0:1' | gpgconf --change-options gpg-agent
echo pinentry-mode loopback >> ~/.gnupg/gpg.conf
# why isn't pinentry-mode settable via gpgconf?
but this means that the user only gets prompted once for the password
(no strength checking, no confirmation), and it's also tedious setup for
this account -- it'd be better if things "just worked".
Any suggestions about what to do for this scenario?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 948 bytes
Desc: not available
More information about the Gnupg-devel