I believe the issue is as follows. When given the option ttyname=... pinentry will open() the given tty and that fails since it is owned by the regular user and not root; strace reports:

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

However, when not given this option, pinentry will simply write() to stdout which causes no permission problem; through sudo and the terminal this goes to /dev/pts/1.

I found a way to replicate that error with just pinentry by doing (as root):

# tty
/dev/pts/1
# pinentry
OK Pleased to meet you
OPTION ttyname=/dev/pts/1
OK
GETPIN
S ERROR gtk2.open_tty_for_read 83918849
ERR 83918849 Permission denied <Pinentry>

When I remove OPTION ttyname=... there is no error.

My other terminals (xterm) are /dev/pts/1, /dev/pts/2, etc. and I can reproduce the bug in them too.

I did not (neither in my root shell nor in my user shell) but setting and exporting this environment variable does not make any difference: gpg --gen-key still fails as above. (Note that tty indeed returns /dev/pts/0 .)

Thanks for your help investigating this.

What is weird is that pinentry supposedly detects the absence of an X session and falls back on curses. For instance, I have:

This seems to work with gnupg-2.1.4. Thanks!