Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 659512 - no chance to enter a password during key generation in command-line mode
no chance to enter a password during key generation in command-line mode
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gnupg2 (Show other bugs)
6.0
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Tomas Mraz
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-02 18:05 EST by Jim Kinney
Modified: 2018-08-14 15:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-06 04:45:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jim Kinney 2010-12-02 18:05:30 EST
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 03:11:35 EST
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 09:59:53 EST
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 11:01:59 EST
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 04:45:01 EST
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 07:00:55 EDT
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-25 21:23:40 EDT
I was able to workaround by running gpg2 in a script session

```
$ script /dev/null
$ gpg2 --gen-key
...
```
Comment 10 Ishwar 2018-08-14 14:16:09 EDT
(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!

Note You need to log in before you can comment on or make changes to this bug.