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.
kwallet is KDE's offering.
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).
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"