Bug 659512 - no chance to enter a password during key generation in command-line mode
Summary: no chance to enter a password during key generation in command-line mode
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gnupg2
Version: 6.0
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-02 23:05 UTC by Jim Kinney
Modified: 2018-08-14 19:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-06 09:45:01 UTC


Attachments (Terms of Use)

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!


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