Graphical prompt (pinentry-gnome3) invoked even when connected via ssh

Bug #1758071 reported by Jani Uusitalo
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gnupg2 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

When I'm connected to my desktop computer via ssh, with the desktop computer's desktop environment running and unlocked, trying to decrypt a gpg-encrypted file causes gpg-agent to invoke pinentry-gnome3 on the desktop. Assuming I'm physically elsewhere, I'm obviously unable to use the prompt on the desktop to enter the passphrase.

This happens despite both pinentry-tty and pinentry-curses being present on the desktop (in addition to pinentry-gnome3), and having GPG_TTY point to the correct tty (export GPG_TTY=$(tty)). Under these circumstances I'd expect gpg-agent to gracefully fall back to non-graphical alternatives.

Granted, I've so far only simulated being physically elsewhere by first ssh'ing out of the desktop, then back in again from the other end. If gpg-agent is using some kind of magic to detect that in reality I'm still physically on the desktop, then this report is invalid (although I'd still feel uneasy about such magic).

== Steps to reproduce ==
1. log in to desktop computer A
2. use another computer B to ssh in to the desktop computer
3. still physically on B, invoke `gpg -d encrypted.gpg` on A (over ssh)

== What happens ==
Graphical passphrase prompt pops up on A, while your ssh terminal on B waits

== What I expect to happen ==
For a non-graphical passphrase prompt (such as pinentry-tty or pinentry-curses) to appear on B's ssh terminal

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gpg-agent 2.2.4-1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7
Uname: Linux 4.15.0-12-generic x86_64
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 22 16:04:09 2018
InstallationDate: Installed on 2016-10-13 (525 days ago)
InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
SourcePackage: gnupg2
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Jani Uusitalo (uusijani) wrote :
Revision history for this message
Jani Uusitalo (uusijani) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in gnupg2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Luke Fraser (lukefrasera) wrote :

I have found that using pinentry-gtk-2 is the only one that currently performs a graceful fallback to tty. This has been my solution in the interim. This still has an annoying behavior of not pulling the terminal or application back into focus after entering your pin.

Revision history for this message
karlwilbur (karlwilbur) wrote :

In the hope that this might help someone else...

When trying to sign over SSH I was getting `Operation cancelled`:
```bash
-> % echo "test" | gpg --clearsign
gpg: using "FD2073A7" as default secret key for signing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

test
gpg: signing failed: Operation cancelled
gpg: [stdin]: clear-sign failed: Operation cancelled
```

I'd tried `pinentry-gtk-2` (from `pinentry-gtk2`) and it didn't work for this situation:

```bash
-> % sudo apt install pinentry-gtk2
-> % sudo update-alternatives --config pinentry
# Select option for `/usr/bin/pinentry-gtk-2`
-> % echo "test" | gpg --clearsign
gpg: using "FD2073A7" as default secret key for signing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

test
gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device
```

While it didn't work, it was progress. After running `GPG_TTY=$(tty); export GPG_TTY` it worked! But each time I connect, I need to set the `GPG_TTY` and `update-alternatives` for `pinentry` to `/usr/bin/pinentry-tty` or `/usr/bin/pinentry-gtk-2`. Not a good solution, but at least it works.

(Ref: https://unix.stackexchange.com/questions/257061/gentoo-linux-gpg-encrypts-properly-a-file-passed-through-parameter-but-throws-i/257065#257065)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.