GnuPGv2 & 'pinentry' on Linux w/ remote access
ryan at splintermail.com
Tue Nov 7 01:11:56 CET 2017
I also was frustrated with how GPG pinentry worked by default. In
particular, I *almost* always want to use the ncurses pinentry, unless
through a key shortcut my window manager tries to call gpg (for my
password manager). But if I want to encrypt a file with mutt, I don't
want a popup! I hate popups!
What I did was write a custom pinentry wrapper, which I call rpinentry.
It just dispaches either the curses-based pinentry or a gui pinentry
based on the environment variable PINENTRY_USER_DATA which is read by
gpg and passed to the pinentry program, for jobs like this:
if [ "$PINENTRY_USER_DATA" == "terminal" ] ; then
# always use the terminal if one is handy
# otherwise DISPLAY info is passed on command line, just forward it
Then in ~/.gnupg/gpg-agent.conf I set it to be my default pinentry
In my ~/.bashrc I have the following two lines:
Then in the config file for my window manager, I have the equivalent of:
So this covers all of my bases. If I do something that calls GPG from a
terminal, I get a curses-based pinentry prompt, because each individual
terminal has PINENTRY_USER_DATA set to "terminal" and GPG_TTY set
properly as soon as it is opened, thanks to my ~/.bashrc.
If my window manager does something which calls GPG (just my password
manager, really), then when the window manager spawns gpg it passes
PINENTRY_USER_DATA set to "qt" and I get a gui popup.
I think my setup might be almost a drop-in fix for your gpg-over-ssh
issue, although you will have to figure out where to set the environment
variable for your particular window manager.
More information about the Gnupg-users