5

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?

Improve this question

3 Answers 3

Reset to default
2

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.

Improve this answer
4
  • We actually discussed doing this yesterday. I'll give this a try and see how it goes. Thanks
    – Bill
    Commented Aug 3, 2014 at 1:30
  • Another option rather than modifying the device permissions is: export GPG_TTY=/dev/tty
    – Russell Reed
    Commented Jan 15, 2016 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
    Commented May 11, 2016 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
    Commented May 14, 2016 at 16:41
1

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.

Improve this answer
3
  • Are you saying to run "sudo" inside the CGI script itself?
    – Bill
    Commented Jul 31, 2014 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
    Commented Aug 1, 2014 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
    Commented Aug 4, 2014 at 19:32
1

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .