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.

Improve this question
6
  • 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 6, 2020 at 23:43
  • Mark sorry I totally missed that. Is SELinux maybe causing the issue?
    – Valentin Bajrami
    Mar 7, 2020 at 8: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 7, 2020 at 18:07
  • Mark did you try it with another user?
    – Valentin Bajrami
    Mar 8, 2020 at 8: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, 2020 at 2:25

3 Answers 3

Reset to default
3 
gpg --gen-key --homedir /home/NEWUSER/.gnupg --passphrase "PASSWORD" --pinentry-mode loopback
Improve this answer
2
  • Got the same issue on arch and this actually worked.
    – Dominik Harz
    Oct 10, 2021 at 11:42
  • I don't understand why does this work. But gpg --full-generate-key doesn't work?
    – maxisam
    Oct 30, 2021 at 7:33
1

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.

Improve this answer
1
  • Same here: killall gpg-agent does the trick :-).
    – AstroFloyd
    Jan 19 at 10:13
0

[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.

Improve this answer

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.