gpg-agent

eval `gpg-agent --daemon`

If you don't use an X server, you can also put this into your regular startup file ~/.profile or .bash_profile. It is best not to run multiple instance of the gpg-agent, so you should make sure that only one is running: gpg-agent uses an environment variable to inform clients about the communication parameters. You can write the content of this environment variable to a file so that you can test for a running agent. This short script may do the job:

Print the program version and licensing information. Not that you can abbreviate this command.

Print a usage message summarizing the most useful command-line options. Not that you can abbreviate this command.

Print a list of all available options and commands. Not that you can abbreviate this command.

Run in server mode and wait for commands on the stdin. The default mode is to create a socket and listen for commands there.

Run the program in the background. This option is required to prevent it from being accidently running in the background. A common way to do this is:

Reads configuration from file instead of from the default per-user configuration file. The default configuration file is named `gpg-agent.conf' and expected in the `.gnupg' directory directly below the home directory of the user.

Set the name of the home directory to dir. If his option is not used, the home directory defaults to `~/.gnupg'. It is only recognized when given on the command line. It also overrides any home directory stated through the environment variable `GNUPGHOME' or (on W32 systems) by means on the Registry entry HKCU\Software\GNU\GnuPG:HomeDir.

Outputs additional information while running. You can increase the verbosity by giving several verbose commands to gpgsm, such as '-vv' .

Try to be as quiet as possible.

Don't invoke a pinentry or do any other thing requiring human interaction.

This option is only useful for testing; it sets the system time back or forth to epoch which is the number of seconds elapsed since the year 1970.

Select the debug level for investigating problems. level may be one of: .RS .TP none no debugging at all. .TP basic some basic debug messages .TP advanced more verbose debug messages .TP expert even more detailed messages .TP guru all of the debug messages you can get .RE How these messages are mapped to the actual debugging flags is not specified and may change with newer releaes of this program. They are however carefully selected to best aid in debugging.

This option is only useful for debugging and the behaviour may change at any time without notice. FLAGS are bit encoded and may be given in usual C-Syntax. The currently defined bits are:

0 (1)

1 (2)

2 (4)

5 (32)

6 (64)

7 (128)

9 (512)

10 (1024)

12 (4096)

--debug-all

--debug-wait n

--no-detach

-s

--sh

-c

--csh

--write-env-file file

$ eval `gpg-agent --daemon`

An alternative way is by replacing ssh-agent with gpg-agent. If for example ssh-agent is started as part of the Xsession intialization you may simply replace ssh-agent by a script like:

This is the standard configuration file read by gpg-agent on startup. It may contain any valid long option; the leading two dashes may not be entered and the option may not be abbreviated. This file is also read after a SIGHUP however only a few options will actually have an effect. This default name may be changed on the command line (see: [option --options]).

This is the list of trusted keys. Comment lines, indicated by a leading hash mark, as well as empty lines are ignored. To mark a key as trusted you need to enter its fingerprint followed by a space and a capital letter S. Colons may optionally be used to separate the bytes of a fingerprint; this allows to cut and paste the fingerprint from a key listing output. Here is an example where two keys are marked as ultimately trusted: .RS 2

  # CN=Wurzel ZS 3,O=Intevation GmbH,C=DE
  A6935DD34EF3087973C706FC311AA2CCF733765B S
  
  # CN=PCA-1-Verwaltung-02/O=PKI-1-Verwaltung/C=DE
  DC:BD:69:25:48:BD:BB:7E:31:6E:BB:80:D3:00:80:35:D4:F8:A6:CD S 

Before entering a key into this file, you need to ensure its authenticity. How to do this depends on your organisation; your administrator might have already entered those keys which are deemed trustworthy enough into this file. Places where to look for the fingerprint of a root certificate are letters received from the CA or the website of the CA (after making 100% sure that this is indeed the website of that CA). You may want to consider allowing interactive updates of this file by using the see: [option --allow-mark-trusted]. This is however not as secure as maintaining this file manually. It is even advisable to change the permissions to read-only so that this file can't be changed inadvertently. It is possible to add further flags after the S for use by the caller. The only flag currently defined is relax to relax checking of some root certificate requirements. As a special feature a line include-default will include a global list of trusted certificates (e.g. `/etc/gnupg/trustlist.txt'). This global list is also used if the local list is not available.

This file is used when support for the secure shell agent protocol has been enabled (see: [option --enable-ssh-support]). Only keys present in this file are used in the SSH protocol. The ssh-add tool y be used to add new entries to this file; you may also add them manually. Comment lines, indicated by a leading hash mark, as well as empty lines are ignored. An entry starts with optional white spaces, followed by the keygrip of the key given as 40 hex digits, optionally followed by the caching TTL in seconds and another optional field for arbitrary flags. A ! may be prepended to the keygrip to disable this entry. The follwoing example lists exactly one key. Note that keys available through a OpenPGP smartcard in the active smartcard reader are implictly added to this list; i.e. there is no need to list them. .RS 2

  # Key added on 2005-02-25 15:08:29
  5A6592BF45DC73BD876874A28FD4639282E29B52 0

This is the directory where gpg-agent stores the private keys. Each key is stored in a file with the name made up of the keygrip and the suffix `key'. Note that on larger installations, it is useful to put predefined files into the directory `/etc/skel/.gnupg/' so that newly created users start up with a working configuration. For existing users the a small helper script is provied to create these files (see: [addgnupghome]).

This signal flushes all chached passphrases and if the program has been started with a configuration file, the configuration file is read again. Only certain options are honored: quiet, verbose, debug, debug-all, debug-level, no-grab, pinentry-program, default-cache-ttl, max-cache-ttl, ignore-cache-for-signing, allow-mark-trusted and disable-scdaemon. scdaemon-program is also supported but due to the current implementation, which calls the scdaemon only once, it is not of much use unless you manually kill the scdaemon.

Shuts down the process but waits until all current requests are fulfilled. If the process has received 3 of these signals and requests are still pending, a shutdown is forced.

Shuts down the process immediately.

Dump internal information to the log file.

This signal is used for internal purposes.

info gnupg

should give you access to the complete manual including a menu structure and an index.