Bug 659512

Summary:	no chance to enter a password during key generation in command-line mode
Product:	Red Hat Enterprise Linux 6	Reporter:	Jim Kinney <jim.kinney>
Component:	gnupg2	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED CANTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.0	CC:	bugzilla.redhat.specked070, ibhatkat, pasik, thorsummoner0
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-12-06 09:45:01 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jim Kinney 2010-12-02 23:05:30 UTC

Description of problem: when generating a new gnupg key there is no opportunity to enter a key passphrase when working over an ssh connection at the command line.

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

gpg: cancelled by user
gpg: Key generation canceled.

Time interval between "You need a Passphrase" and "cancelled by user" is less than 1 second.


Version-Release number of selected component (if applicable):
gnupg2-2.0.14-4.el6.x86_64

How reproducible:


Steps to Reproduce:
1. start gpg-agent with gpg-agent --daemon and export the GPG_AGENT_INFO data.
2. export GPG_TTY=$(tty) data as well
3. gpg2 --gen-key and enter required data up through Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
  
Actual results:
gpg: cancelled by user
gpg: Key generation canceled.

Expected results:
expected to see generate random data, making key, etc.

Additional info:

Comment 2 Tomas Mraz 2010-12-03 08:11:35 UTC

I cannot reproduce the problem. Do you have pinentry package installed? Do you use X forwarding on the ssh session?

Comment 3 Jim Kinney 2010-12-03 14:59:53 UTC

Yes, pinentry is installed.

I've done some more digging into this: It works from the local console (without gpg-agent being set up at all). However it does NOT work by doing a su - <user> then gpg2 --gen-key.

It looks to be a tty issue with pinentry.

Comment 4 Jim Kinney 2010-12-03 16:01:59 UTC

to replicate :

ssh:
create two user accounts on rhel6 server
log in as user1 over ssh
su - root
su - user2
gpg --gen-key (fails)

on console:
login as root
su - user2
gpg --gen-key (fails)

on console:
login as user2
gpg --gen-key succeeds at providing the password entry ability.

over ssh:
ssh into server as user2
gpg --gen-key succeeds with password screen

Comment 5 Tomas Mraz 2010-12-06 09:45:01 UTC

Yes, su does not open a new pty for the su-ed user session. Unfortunately this is a design limitation of the GnuPG2 that it always requires access rights to open the tty for the pinentry. The workaround would be to use X forwarding and pinentry-gtk to enter the password. Also note that for su - to forward the XAUTHORITY ticket to the user session from a root account, you have to create file $HOME/.xauth/export and put into it the su-ed to user name.

Comment 8 Tomas Mraz 2016-06-13 11:00:55 UTC

The proper workaround is to install screen and run it after the su command and run the gpg --gen-key inside the screen session.

Comment 9 Dylan Scott Grafmyre 2017-06-26 01:23:40 UTC

I was able to workaround by running gpg2 in a script session

```
$ script /dev/null
$ gpg2 --gen-key
...
```

Comment 10 Ishwar 2018-08-14 18:16:09 UTC

(In reply to Dylan Scott Grafmyre from comment #9)
> I was able to workaround by running gpg2 in a script session
> 
> ```
> $ script /dev/null
> $ gpg2 --gen-key
> ...
> ```

Thank you for posting the workaround!

Comment 11 Alberto 2020-03-24 09:59:44 UTC

Dylan Scott Grafmyre, you are my hero! Thanks!