gpg-agent can have multiple personalities and deliver different services.
For example, you can stop having
ssh-agent running on your box, and use
gpg-agent as a drop in replacement... as long as you use the proper socket,
S.gpg-agent.ssh because it has to implement the proper protocol
ssh is expecting to discuss. Why could be that useful? For example, until very recently,
ssh was not able to use keys stored in FIDO2/U2F (like Yubikeys), this was only added in 8.2 released not long ago, which then makes things dead simple as explained in https://blog.snapdragon.cc/2020/02/23/direct-fido2-u2f-support-in-openssh-8-2-on-macos/
gpg-agent would be used, because
gpg has support for the U2F thing as handled like a smartcard. This is one of the canonical documentation on how to do that: https://florin.myip.org/blog/easy-multifactor-authentication-ssh-using-yubikey-neo-tokens
Now back to
gpg-agent, its full manual is at https://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html#Invoking-GPG_002dAGENT
You can find all options at https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html#Agent-Options which can be put in a configuration file, typically
We can learn for example:
- about the
.extra one, we can learn both how to disable it and what it is used for:
The extra socket is created by default, you may use this option to change the name of the socket. To disable the creation of the socket use “none” or “/dev/null” for name.
Also listen on native gpg-agent connections on the given socket. The intended use for this extra socket is to setup a Unix domain socket forwarding from a remote machine to this socket on the local machine. A gpg running on the remote machine may then connect to the local gpg-agent and use its private keys. This enables decrypting or signing data on a remote machine without exposing the private keys to the remote machine.
- For ssh support, the
The OpenSSH Agent protocol is always enabled, but gpg-agent will only set the SSH_AUTH_SOCK variable if this flag is given.
In this mode of operation, the agent does not only implement the gpg-agent protocol, but also the agent protocol used by OpenSSH (through a separate socket). Consequently, it should be possible to use the gpg-agent as a drop-in replacement for the well known ssh-agent.
- For the browser socket and more information you can use https://wiki.archlinux.org/index.php/GnuPG#gpg-agent that says:
gpg-agent is mostly used as daemon to request and cache the password for the keychain. This is useful if GnuPG is used from an external program like a mail client. gnupg comes with systemd user sockets which are enabled by default. These sockets are
gpg-agent.socket is used by gpg to connect to the
The intended use for the
gpg-agent-extra.socket on a local system is to set up a Unix domain socket forwarding from a remote system. This enables to use gpg on the remote system without exposing the private keys to the remote system. See gpg-agent(1) for details.
gpg-agent-browser.socket allows web browsers to access the gpg-agent daemon.
gpg-agent-ssh.socket can be used by SSH to cache SSH keys added by the ssh-add program. See #SSH agent for the necessary configuration.
dirmngr.socket starts a GnuPG daemon handling connections to keyservers.
So there is no harm in having them even if you don't use them.
If you really want to make sure they are not there, you can try to put the following in a gpg-agent configuration file:
I did not test that, the documentation does not speak about
browser-socket but this older question does: https://askubuntu.com/questions/777900/how-to-configure-gnupgs-s-gpg-agent-socket-location