gpg can't access secret keys when logged in via ssh instead of desktop

When attempting to decrypt a message, these messages show up in syslog:

Jun 8 15:55:29 wopr systemd[2245]: Started GnuPG cryptographic agent and passphrase cache.
Jun 8 15:55:29 wopr gpg-agent[25712]: gpg-agent (GnuPG) 2.2.4 starting in supervised mode.
Jun 8 15:55:29 wopr gpg-agent[25712]: using fd 3 for ssh socket (/run/user/35000001/gnupg/S.gpg-agent.ssh)
Jun 8 15:55:29 wopr gpg-agent[25712]: using fd 4 for std socket (/run/user/35000001/gnupg/S.gpg-agent)
Jun 8 15:55:29 wopr gpg-agent[25712]: using fd 5 for extra socket (/run/user/35000001/gnupg/S.gpg-agent.extra)
Jun 8 15:55:29 wopr gpg-agent[25712]: using fd 6 for browser socket (/run/user/35000001/gnupg/S.gpg-agent.browser)
Jun 8 15:55:29 wopr gpg-agent[25712]: listening on: std=4 extra=5 browser=6 ssh=3
Jun 8 15:55:29 wopr gnome-shell[4354]: remove_mnemonics: assertion 'label != NULL' failed
Jun 8 15:55:29 wopr gnome-shell[4354]: remove_mnemonics: assertion 'label != NULL' failed
Jun 8 15:55:29 wopr gpg-agent[25712]: failed to unprotect the secret key: Operation cancelled
Jun 8 15:55:29 wopr gpg-agent[25712]: failed to read the secret key
Jun 8 15:55:29 wopr gpg-agent[25712]: command 'PKDECRYPT' failed: Operation cancelled <Pinentry>

Status changed to 'Confirmed' because the bug affects multiple users.

I had the same type of problem when attempting to decrypt using gpg2 on a remote host, logged in via ssh from Ubuntu 18.04 client. Turned out that GPG2 was unable to ask for passphrase via X-forwarding. I got it working by disabling X forwarding ("ssh -x .." or "unset DISPLAY"), which triggers a text-only pop-up asking for passphrase in the terminal.

I have this problem testing Cosmic as well. In fact it is a problem both when using a virtual tty (alt-cntl-F2 for example), and when using ssh.

The problem appears to me to be that pinentry, the program to collect the passphrase for one's private key, is not working as it was.

Assuming I am not signed on elsewhere, first entering the following works for me:

GPG_TTY=$(tty)
export GPG_TTY

Ideally this would go in your shell startup script, e.g. .bashrc. It's from "man gpg-agent".

But it gets stranger and then the above is not enough.

If I am signed on a graphic session, when I try to use my private key through either an ssh session or a virtual terminal, the prompt for unlocking the private key goes to the graphic session rather than to where I'm typing. That happens even if the graphic session is locked and invisible.

In this case the gpg "--pinentry-mode loopback" option works to have a passphrase prompt go to where I'm typing (though the prompt is very basic compared to the text pop-up).

Should user set-up add the above GPG_TTY commands to everyone's .bashrc for the first case?

I've been looking into this for the last couple of days.

With the new gpg versions the gpg command refers operations needing private keys to gpg-agent, a separate process it starts when needed.

When gpg-agent needs to ask the user for a key's passphrase it starts up a third independent process called pinentry. pinentry is actually one of 5 related programs, selected in Ubuntu with the update-alternatives mechanism.

The default for Ubuntu is pinentry-gnome3. It provides the prettiest graphic dialog box on your computer's graphics screen. Unfortunately it does this (successfully or not) even if you are using gpg2 from an ssh terminal session (or from a virtual console). pinentry-gnome3 uses a facility called "Gcr System Prompter".

This can fail in one of at least 4 ways:

1. You may be ssh'ing from a remote location and therefore you won't be able to see the dialog box on you graphics display and you have no way to provide the passphrase.

2. You may not be signed on a graphics session.

3. You may be signed on but the session may be locked.

4. You may be signed on to a graphics session but left the computer in a virtual console.

In at least one of these pinentry-gnome waits about 25 seconds to try put up the dialog box and then falls back to using a curses text box. In testing the no graphics sessions case I think I always got an immediate fallback to the curses text box. Both are these are probably the best result you can wish for if you are remote from the target computer.

In the other cases the dialog box goes up until there is a timeout, (or forever).

------------------------

My suggestion is for desktop computer users who use ssh with gpg or other passphrase protected keys to use pinentry-gtk-2 or pinentry-curses instead.

You can use 'update-alternatives --display pinentry' to find out which is the default for your system. You use 'sudo update-alternatives --config pinentry to pick out what you want from a menu.

The pinentry program can also be changed in the ~/.gnupg/gpg-agent.conf file. To do this add a line such as:

pinentry-program /usr/bin/pinentry-curses

My alternate suggestion is to use gpg's --pinentry-mode loopback" option when using a command that will require a passphrase.

----------------------

While the GPG_TTY environment variable is necessary for ssh's use of gpg-agent, it isn't needed when gpg uses it--it informs gpg-agent directly of the name of the tty that is controlling gpg. I think my comment above in #4 about GPG_TTY is irrelevant for this bug report.