[Bug 1775923] Re: gpg can't access secret keys when logged in via ssh instead of desktop
John S. Gruber
JohnSGruber at gmail.com
Mon Sep 24 01:49:28 UTC 2018
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.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gnupg2 in Ubuntu.
https://bugs.launchpad.net/bugs/1775923
Title:
gpg can't access secret keys when logged in via ssh instead of desktop
Status in gnupg2 package in Ubuntu:
Confirmed
Bug description:
I recently performed a fresh install of 18.04 (Bionic) after
preserving my .gnupg directory from my previous 16.04 LTS (Xenial)
installation, but now, I can't perform gpg operations that require my
secret key unless I'm sitting at the desktop and not logged in via
ssh.
If I'm sitting at the gnome desktop environment, I can run gpg
commands to decrypt encrypted messages and the popup appears to ask my
passphrase, but if I'm connected via ssh, I get errors from gpg-agent
and gpg fails to find my secret key without ever asking for my
passphrase:
$ ps auxww | grep gpg-agent
jesse 16703 0.0 0.0 21536 1040 pts/4 S+ 12:19 0:00 grep gpg-agent
$ gpg --list-keys
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2019-02-22
/home/jesse/.gnupg/pubring.kbx
------------------------------
pub rsa2048 2018-02-22 [SC] [expires: 2019-02-22]
...
uid [ultimate] Jesse Michael <... at ...>
uid [ultimate] Jesse Michael <... at ...>
sub rsa2048 2018-02-22 [E] [expires: 2019-02-22]
pub rsa2048 2018-02-22 [SC] [expires: 2019-02-22]
...
uid [ultimate] Jesse Michael <... at ...>
sub rsa2048 2018-02-22 [E] [expires: 2019-02-22]
pub rsa4096 2017-07-10 [SC] [expires: 2018-07-10]
...
uid [ unknown] ... <... at ...>
sub rsa4096 2017-07-10 [E] [expires: 2018-07-10]
$ gpg --export-secret-keys
gpg: key ...: error receiving key from agent: Operation cancelled - skipped
gpg: key ...: error receiving key from agent: Operation cancelled - skipped
gpg: key ...: error receiving key from agent: Operation cancelled - skipped
gpg: key ...: error receiving key from agent: Operation cancelled - skipped
gpg: WARNING: nothing exported
$ gpg --decrypt somefilename.gpg
gpg: encrypted with 4096-bit RSA key, ID ..., created 2017-07-10
"... <... at ...>"
gpg: encrypted with 2048-bit RSA key, ID ..., created 2018-02-22
"Jesse Michael <... at ...>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key
$ ps auxww | grep gpg-agent
jesse 16716 0.0 0.0 100420 3484 ? SLs 12:19 0:00 /usr/bin/gpg-agent --supervised
jesse 16763 0.0 0.0 21536 1092 pts/4 S+ 12:20 0:00 grep gpg-agent
$ lsb_release -rd
Description: Ubuntu 18.04 LTS
Release: 18.04
$ apt-cache policy gpg gnupg2 gpg-agent
gpg:
Installed: 2.2.4-1ubuntu1
Candidate: 2.2.4-1ubuntu1
Version table:
*** 2.2.4-1ubuntu1 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
100 /var/lib/dpkg/status
gnupg2:
Installed: 2.2.4-1ubuntu1
Candidate: 2.2.4-1ubuntu1
Version table:
*** 2.2.4-1ubuntu1 500
500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
500 http://us.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
100 /var/lib/dpkg/status
gpg-agent:
Installed: 2.2.4-1ubuntu1
Candidate: 2.2.4-1ubuntu1
Version table:
*** 2.2.4-1ubuntu1 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
100 /var/lib/dpkg/status
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1775923/+subscriptions
More information about the foundations-bugs
mailing list