1

I believe I've read and tried all the suggestions, starting with this post about the exact same issue.

I'm trying to generate a new key with:

gpg --full-generate-key

and it keeps ending with:

gpg: agent_genkey failed: No such file or directory
Key generation failed: No such file or directory

Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-88-generic x86_64), headless

gpg --version

gpg (GnuPG) 2.2.4
libgcrypt 1.8.1
Home: /home/mark/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
    CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

I've killed gpg-agent and restarted the server multiple times.

gpgconf --kill gpg-agent

ps aux | grep gpg-agent

mark      1637  0.0  0.0  14428  1052 pts/0    S+   13:55   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn gpg-agent

The .gnupg directory permissions:

drwx------ 3 mark mark 4.0K Mar 6 14:01 .gnupg

I've deleted ~/.gnupg multiple times, rebooting each time for good measure:

ls -la ~/.gnupg

total 12K
drwx------  3 mark mark 4.0K Mar  6 14:00 .
drwxr-xr-x 17 mark mark 4.0K Mar  6 14:01 ..
drwx------  2 mark mark 4.0K Mar  6 14:00 private-keys-v1.d

I've repeated the following several times with the same result:

Trying to generate gpg key

ls -la ~/.gnupg

total 16K
drwx------  3 mark mark 4.0K Mar  6 14:01 .
drwxr-xr-x 17 mark mark 4.0K Mar  6 14:04 ..
drwx------  2 mark mark 4.0K Mar  6 14:00 private-keys-v1.d
-rw-------  1 mark mark   32 Mar  6 14:01 pubring.kbx

I changed pubring.kbx to 700 and ran again, same result (grasping at straws)

ps aux | grep gpg-agent

 mark      1751  0.0  0.0  93316  3348 ?        SLs  14:02   0:00 /usr/bin/gpg-agent --supervised
 mark      1758  0.0  0.0  14428  1084 pts/0    S+   14:06   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn gpg-agent

I also ran with strace but not sure how to decipher that output. Last line is +++ exited with 2 +++

strace -o /tmp/foo gpg --full-generate-key

I'm at a loss here.

Mark
  • 111
  • 1
  • 1
  • 4
  • Thanks for the link but it's the same one I linked to in the first line of this post. That looked promising but my issue persists. You can see above the screenshot, that directory exists with permissions 700 as described in that answer. – Mark Mar 06 '20 at 23:43
  • Mark sorry I totally missed that. Is SELinux maybe causing the issue? – Valentin Bajrami Mar 07 '20 at 08:22
  • @ValentinBajrami no, SELinux is not enabled - this is a box in a closet used for testing/learning. I try to avoid any extra security measures to keep things simple and avoid possible confusion, like you mentioned. – Mark Mar 07 '20 at 18:07
  • Mark did you try it with another user? – Valentin Bajrami Mar 08 '20 at 08:39
  • @ValentinBajrami - I did not but after reading your question I did and it worked, with two different users. So I tried it again using my account and it worked this time. The only difference I can think of is that the machine had been powered down completely instead of just being rebooted. Thanks for the suggestion. – Mark Mar 10 '20 at 02:25
  • Mark, good to hear and thanks for the feedback. This is a really strange edge case. Such an unfortunate that the classic "Did you try to turn it off and on again" did not work. – Valentin Bajrami Mar 10 '20 at 08:48

3 Answers3

4
gpg --gen-key --homedir /home/NEWUSER/.gnupg --passphrase "PASSWORD" --pinentry-mode loopback
Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
2

I ran into something that looked a lot like this...

In my case it was because I had gpg-agent running and had deleted the files it was referring to in order to "start again". By killing the old gpg-agent I resolved the issue.

rconan
  • 21
  • 1
1

[Crossposting from a related question.]

In this issue this was called expected behaviour with the reason being a lack of ownership of the terminal-related device file. This can happen when e.g. starting the terminal as regular user, but running the gpg command as root via su or sudo.

Instead of doing wild stunts with chmod in the /dev tree, this comment demonstrates a quick fix using tmux. Basically just run the same gpg command within a tmux session, as tmux will take care of proper device file ownership.