46

I have a line in my gpg.conf file which says use-agent.
I understand this refers to gpg-agent which is a daemon. The man page states "gpg-agent is a daemon to manage secret (private) keys independently from any protocol. It is used as a backend for gpg and gpgsm as well as for a couple of other utilities."

Can anybody explain what this means in the context of gpg? What is the point of gpg-agent?

I have GPG 1.4 at present.

  1. How can I tell whether the agent is running? I'm actually not even clear on whether gpg-agent is installed with the basic GPG 1.4 package.
  2. How can I start it, if it is not running?
  3. How can I stop it, if it is running?
Improve this question
0

1 Answer 1

Reset to default
57

Gpg-agent is a program that runs in the background (a daemon) and stores GPG secret keys in memory. When a GPG process needs the key, it contacts the running gpg-agent program through a socket and requests the key. If the agent process has the key, it provides it to gpg. If it doesn't, it attempts to load the encrypted key from your keyring, and prompts you for the key's passphrase. Once the agent has obtained the decrypted key, it passes it to the gpg process. In addition to GPG keys, Gpg-agent can similarly store SSH keys and provide them to SSH processes, like the ssh-agent program that comes with SSH.

The main point of using a key agent is so that you don't have to type your passphrase every single time you use your key. The agent keeps the key in memory from one time to the next. GPG itself can't do that because the process terminates once it's done its job.

Another thing that a key agent can do is allow GPG running on a remote machine to obtain keys in the local agent (which may load them from a local file and prompt for your passphrase). Gpg-agent can't do this yet, it is a planned feature. SSH has had agent forwarding for a very long time. (This is a reason not to use gpg-agent for SSH keys.)

GPG 1.x or 2.0.x knows that the agent is running because the GPG_AGENT_INFO variable is set. This variable contains the location of the socket to communicate with the agent as well as the process ID of the agent. GPG 2.1 always places the agent socket in ~/.gnupg. GPG 2.x always starts an agent process if one isn't running.

You can start the agent simply by running gpg-agent. If you want to keep an agent process as part of your session, you can replace the invocation of your session manager by gpg-agent my-session-manager; some distributions set this up automatically. GPG will automatically start the agent, and GPG 2.1 will additionally find a running agent without needing an environment variable, so you don't need to start it this way unless you use an older version of GPG or you use the agent to store other types of keys such as SSH.

You can send the agent commands with the gpg-connect-agent shell command. Send the kill command to kill the agent process (or send it a signal).

Gpg-agent ships with GPG itself. Some distributions package it separately.

Improve this answer
4
  • 18
    "When a GPG process needs the key, it contacts the running gpg-agent program through a socket and requests the key. If the agent process has the key, it provides it to gpg." Slightly misleading. The agent does not provide a key to the client process. Instead, it performs actions using the key, on behalf of the client process. (The client provides the agent with something to sign, encrypt, or decrypt, and the agent does so.) When using an agent, your SSH and GPG client software never gains access to the actual key.
    – Peter Samuelson
    Jun 14, 2016 at 19:28
  • 6
    "Gpg-agent can't do this yet, it is a planned feature. SSH has had agent forwarding for a very long time. (This is a reason not to use gpg-agent for SSH keys.)" Not quite true. gpg-agent works fine with SSH agent forwarding. I use it every day. The SSH client handles the forwarding, gpg-agent is not really involved in that. What is not supported is for GPG itself to talk to an agent remotely.
    – Peter Samuelson
    Jun 14, 2016 at 19:28
  • Is it the decrypted private key that is cached, or the passphrase (which was used to encrypt/decrypt the private key)?
    – nyg
    Feb 26 at 21:55
  • 2
    @nyg It caches the private key, which is both faster (decryption with a password is slow) and somewhat more secure (in case the user uses the same passphrase elsewhere).
    – Gilles 'SO- stop being evil'
    Feb 26 at 22:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .