Cryptographic Agents

One useful technique for cryptographic security is to limit access to your primary secrets (private keys, passphrases, etc) to a single software process, often called an "agent". The agent can communicate with other processes using a simple interface to allow cascaded access to the secrets as needed.


The advantages to an isolated cryptographic agent are similar to the reasons for the classic Unix Philosophy.


Because the process which holds the secrets is relatively limited functionality, it's easier to review the source code of the agent itself. This means that you can be more sure that it's handling your secrets securely. Because it's not trying to do too many other things, it has fewer places to fail.


Because access to the secrets go through the defined interface to the agent, there is an opportunity to log all access attempts. This allows you to audit the use of the agent.


Your security needs might change as your habits develop. By requiring all access to secrets to go through the agent, you can change the rules for distributing access in a simpler, central location. Require user confirmation for access to your private keys? Just modify the agent.

Existing Implementations


ssh-agent is distributed with OpenSSH.


gpg-agent is offered by the GnuPG folks. It offers an agent for use with gpg and gpg2, and is also capable of emulating ssh-agent.


gnome-keyring is the GNOME environment's default daemon. It claims to offer a range of features, including ssh-agent emulation.


kwallet is KDE's offering.


wallet is offered by Russ Albery of Stanford, and focuses on kerberos 5 authentication.

Agent Collisions

Many of the above-listed programs have slightly different interfaces. Often, one will attempt to offer the interface of another, to reduce the number of agents in use. But this can lead to problems when the new agent isn't able to support the full functionality of the agent it's usurping (e.g. gnome-keyring being unable to support adding keys requiring a confirmation prompt).

This happened to me (dkg) on squeak on 2008-04-17, when i upgraded gnome-keyring to 2.22.1-1. The new gnome-keyring automatically started up at my next session, and began offering an ssh-agent-style interface, despite the fact that the gnome-keyring-daemon was unable to handle the smartcard information that i usually pass to ssh-agent. Since there was already something offering ssh-agent info (i.e. the SSH_AUTH_SOCK environment variable was set), ssh-agent declined to start with my new session. I repaired this by disabling gnome-keyring's ssh features for my own user account. I did:

gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false

And then logged out and logged back in to restart my session (if you're clever, you can probably avoid restarting your session, but this is the simplest way to get functional again).

Updated on 2012-02-12: a friend reports that the same gconftool-2 invocation works to tell gnome 2.30.2 to avoid running its ssh-agent emulation mechanism, and restored access via the traditional openssh ssh-agent implementation, so the above is still worth trying if you're having this problem.

Unfortunately, on 2012-02-19, i received a report that ubuntu 11.10 does not respect this user setting. Apparently, some of the instructions over here were helpful in resolving the issue (they seem drastic to me, since stef walter suggested a less-invasive fix, but apparently Walter's suggestion no longer works).

On 2012-08-03, Hans-Christoph Steiner suggested the following way to disable GNOME's ssh-agent implementation:

12:23 < _hc> there is an individual item for ssh in /etc/xdg/autostart
12:23 < _hc> so you just put a disable .desktop file in ~/.config/autostart
12:26 < _hc> [...] its simple: go to the GNOME control center, 
             go to "Startup Applications" and remove "SSH Key Agent"
Last modified 5 years ago Last modified on Aug 3, 2012, 12:42:17 PM