GnuPGv2 & 'pinentry' on Linux w/ remote access

Ryan Beethe ryan at
Tue Nov 7 01:11:56 CET 2017

Hi Sander,

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
        /usr/bin/pinentry-qt "$@"

Then in ~/.gnupg/gpg-agent.conf I set it to be my default pinentry

    pinentry-program /path/to/rpinentry

In my ~/.bashrc I have the following two lines:

    export PINENTRY_USER_DATA="terminal"
    export GPG_TTY=$(tty)

Then in the config file for my window manager, I have the equivalent of:

    export PINENTRY_USER_DATA=qt

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 mailing list