The 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/
Before that, 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 ~/.gnupg/gpg-agent.conf
We can learn for example:
- about the
.extra
one, we can learn both how to disable it and what it is used for:
--extra-socket name
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
.ssh
one:
--enable-ssh-support
--enable-putty-support
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
, gpg-agent-extra.socket
, gpg-agent-browser.socket
, gpg-agent-ssh.socket
and dirmngr.socket
.
The main gpg-agent.socket
is used by gpg to connect to the gpg-agent
daemon.
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.
The gpg-agent-browser.socket
allows web browsers to access the gpg-agent daemon.
The 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.
The 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:
extra-socket /dev/null
browser-socket /dev/null
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