Here's the scenario, we're using GnuPG to encrypt data between 2 web servers. 1 is on RHEL. GnuPG will be accessed through cgi scripts to encrypt and decrypt. So I need a keyring that the apache user has access to. This has proven to be difficult for me on Red Hat, I was able to get this set up pretty easily on Ubuntu. Here's what I've tried to, maybe someone has a better/easier way to accomplish this.

I became the apache user

su -s /bin/bash apache

when running

gpg --gen-key

it couldn't create the .gnupg directory at /var/www, so I created that and set the owner to apache.apache. now when generating keys, I get

can't connect to `/var/www/.gnupg/S.gpg-agent': No such file or directory
gpg-agent[26949]: command get_passphrase failed: Operation cancelled
gpg: cancelled by user
gpg: Key generation canceled.

so I created that file, after reading the man page a bit (and some googling)

mknod -m 700 S.gpg-agent p

now I get

can't connect to `/var/www/.gnupg/S.gpg-agent': Connection refused
gpg-agent[26949]: command get_passphrase failed: Operation cancelled
gpg: cancelled by user
gpg: Key generation canceled.

I haven't been able to get anywhere after this as I'm getting into areas I don't know much about. I'm assuming it has to do with that apache isn't really a user in the since of having a bash profile, etc. So where do I go from here?


Have you tried creating a new user and invoking the command with sudo instead? If fear this might be some permission issue and the easier way would be removing the agent node from /var/www to somewhere we know is accessible to the gpg user, maybe the /tmp directory. You can manually specify the agent node location changing the env variable GPG_AGENT_INFO.

  • Are you saying to run "sudo" inside the CGI script itself? – Bill Jul 31 '14 at 13:10
  • yes, as soon you don't have any parameters is should be relatively safe. For added security you can always specify allowed commands in /etc/sudoers – Francesco Manzoni Aug 1 '14 at 8:01
  • I was able to import keys into the keyring, however, when trying to sign them, I'm back to where I started: can't connect to /var/www/.gnupg/S.gpg-agent: No such file or directory` gpg-agent[24458]: command get_passphrase failed: Operation cancelled gpg: cancelled by user gpg: signing failed: General error Key not changed so no update needed. – Bill Aug 4 '14 at 19:32

That is probably a device file permission problem. pinentry doesn't use the inherited file descriptors but tries to access the passed TTY directly which doesn't work.

You may run tty in the shell and afterwards ls -l /dev/pts/1 with the result and you will probably notice that apache does not have access to it.

You may also run

strace -o gpg.strace -f -e trace=open gpg --gen-key

and will probably find something like

open("/dev/pts/1", O_RDONLY)      = -1 EACCES (Permission denied)

The dangerous solution is to (temporarily) give apache access to a root console... (chown apache /dev/pts/1). The better solution is to make a real login as apache.

This affects key generation only. You could also create a key pair as another user, export it and import in in the apache account.

  • We actually discussed doing this yesterday. I'll give this a try and see how it goes. Thanks – Bill Aug 3 '14 at 1:30
  • Another option rather than modifying the device permissions is: export GPG_TTY=/dev/tty – Russell Reed Jan 15 '16 at 19:22
  • +1 I've faced this problem also in SLES 11 SP4. Setting GPG_TTY as suggested by @RussellReed did not help. I neither like chmod'ing (or chown'ing) $tty, so I instead ssh into the account from which I need to sign artifacts (In my case, I already had keys but needed to sign some objects). As support links, see also bugs.gnupg.org/gnupg/issue1391 and lists.gnupg.org/pipermail/gnupg-users/2009-May/036544.html – Alberto May 11 '16 at 9:46
  • Alberto, just to double check, you specified /dev/tty and didn't try to substitute the actual tty device, like /dev/pts/1, right? – Russell Reed May 14 '16 at 16:41

I suspect it's a regression regarding this bug https://rhn.redhat.com/errata/RHBA-2011-1096.html

From the errata:

This update fixes the following bug:

  • Prior to this update, there was a problem when entering a password using the pinentry-curses utility; an error message was displayed instead of the password entry dialog if pinentry-curses was run under a user different from the user who owned the current tty. This bug has been fixed in this update so that no error message is now displayed and pinentry-curses asks for a password as expected. (BZ#677665)

The problem appears to be, when you su or sudo, the tty is still owned by the original owner of the tty, which blows up pinentry.

I will note that we couldn't create gpg keys as any user other than root on a Cent 6 system yesterday. To generate the keys, we had to log in as root, create the keys, copy the .gpg dir to the user's home directory and change the ownership.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.