From ArchWiki

System login with gnupg smartcard (yubikey, p-card, rsa token, etc)

gnupg with poldi can be used for system login. There is a thread asking whether it is possible to use gpg for system login. A new tip section explaining gnupg smartcard for logging into Arch Linux system is a nice addition here.

Alive4ever (talk) 02:27, 4 August 2016 (UTC)

User configuration files not created

Per the wiki, it states, "You will find skeleton files in /usr/share/gnupg. These files are copied to ~/.gnupg the first time gpg is run if they do not exist there."

I could very well be doing something wrong so I'd ask that this could be verified. If we need to copy skel configuration files, it should be clearly explained in the wiki shouldn't it?

I was unable to import public keys until I manually created a blank ~/.gnupg/gpg.conf with just keyserver in it.

I also found this when searching for info, It states: There are no configuration files and only a few options are implemented.

NuSkool (talk) 04:09, 26 September 2016 (UTC)

On the same topic but on a different note, update GnuPG#Configuration_files to remove out of date warning and add the following informtion:
1) ~/.gnupg/gpg.conf and ~/.gnupg/dirmngr.conf are not created by default. So, the user can create them to implement the changes.
2) global config file is located at /etc/gnupg/gpgconf.conf shown by command gpgconf --list-config. This is also not created by default. The example file is
at /usr/share/doc/gnupg/examples/gpgconf.conf
--RaZorr (talk) 12:51, 16 January 2022 (UTC)
I've used gpg and I don't have the configuration files. The wiki is wrong. Pound Hash (talk)
I am having difficulty corroborating the existence of this functionality. There is no "default" gpg.conf in the GnuPG repository, and I'm not sure if it even makes sense to have one. This file is for overriding defaults. For instance, this is what mine looks like:
keyring keyring-path
default-key default-key
It shouldn't be a complicated configuration file, just command line options that you want to use all the time. dirmngr.conf is exactly the same way, as far as I can tell. So, RaZorr got it totally right with 1). With 2), though, /etc/gnupg/gpgconf.conf is actually not the global version of ~/.gnupg/gpg.conf. /etc/gnupg/gpgconf.conf is a "legacy mechanism" for setting up defaults using the gpgconf progrma. The modern way for configuring system-wide GnuPG defaults is ~/.gnupg/gpg.conf's actual global analog: /etc/gnupg/gpg.conf, which was introduced in 2020 [1].
I gave a shot at fixing this part of the page. Thanks, CodingKoopa (talk) 08:21, 20 May 2022 (UTC)

Recommendation to add

By default, no skeleton files exist (as mentioned above) but in my case the lack of a dirmngr.conf meant that any --recv-keys failed with useful(?) errors like "gpg: keyserver receive failed: Server indicated a failure" or "gpg: error searching keyserver: Server indicated a failure". Route to get here was via makepkg, and so I skipped all the installation steps etc since gpg was already installed and went straight for a recv.

   echo > $HOME/.gnupg/dirmngr.conf 'standard-resolver'

Beepboo (talk) 17:09, 22 March 2020 (UTC)

also requires to restart dirmngr.service Louson (talk) 13:32, 25 April 2022 (UTC)
but the problem is probably on the /etc/resolv.conf file. Are you using systemd-resolved ? Then check Systemd-resolved#DNS Louson (talk) 13:46, 25 April 2022 (UTC)

A comment on provided code snippet

The test from Set_SSH_AUTH_SOCK :

   [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]

would probably always fail, since [2] sets gnupg_SSH_AUTH_SOCK_by to the process id of gpg-agent, and the line above tests it for the process id of the bash process.


   export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" 

will probably get executed every time. However, it most likely wouldn't break anything since at worst it will reset SSH_AUTH_SOCK to the same value.

—This unsigned comment is by Thread13 (talk) 11:16, 1 May 2021‎ (UTC). Please sign your posts with ~~~~!

Invalid IPC response and Inappropriate ioctl for device

I solved this problem simply by removing an # inside /etc/pinentry/preexec enabling the desired option and then setting /usr/bin/pinentry as default. Pavlov (talk) 15:19, 2 May 2021 (UTC)

Another suggestion for troubleshooting automatic key fetching from keyservers in case that SRV lookup fails

If the port is not explicitly stated, than GnuPG will try to use a DNS lookup using SRV [1]. This may fail due to various reasons, so troubleshooting will be to explicitly set the keyservers with the ports, e.g. in ~/.gnupg/dirmngr.conf (or where appropriate) keyserver hkps:// instead of just keyserver hkps:// [1] --Tobias.predel (talk) 10:09, 10 June 2022 (UTC) is not resolving is not resolving, but is used many times within this documenation. Anyone have an ideas on an alternative? Jahway603 (talk) 17:11, 9 March 2023 (UTC)!

Deprecated --supervised option for gpg-agent

As per, it seems as though gpg-agent --supervised, and as such systemd-based activation altogether, is deprecated by GnuPG. What would the ideal startup method for gpg-agent be instead in that case? 90 (talk) 17:41, 6 June 2023 (UTC)

I'd like to drop-in Werner's initial reply, and add the removal applied for >=2.4.1. --Indigo (talk) 18:48, 19 September 2023 (UTC)

What about setting ForwardAgent yes as shown in OpenSSH#Agent forwarding?

I tested the gpg-agent forwarding and the OpenSSH ForwardAgent yes options. I am able to forward the use of my gpg key on my hardware key with the former, but it doesn't work with the latter. Seodisparate (talk) 12:23, 24 June 2023 (UTC)