SSH Frequently Asked Questions
How does ssh-agent work?
The agent runs as a separate process, which simply holds your decrypted keys in memory. Programs such as the SSH client communicate with the agent via a Unix-domain socket (or "named pipe"), which appears as a node in the filesystem (e.g. /tmp/ssh-XXLGfkdd/agent.2141); programs find the agent socket via an environment variable such as SSH_AUTH_SOCK.
While the agent is running, access to your keys is now protected only by local filesystem permissions (the permissions on the agent socket). However, it is not equivalent to temporarily decrypting your private key files. This is because the agent does not give out your keys at any time; it cannot be instructed to do so via the agent protocol. Instead, it will only perform designated operations with your keys. For example, a client of the agent can ask it to sign a given block of data with one of the keys it holds; the agent will perform the signature, and send it back. So, an attacker who gains access to the agent socket could use it to forge your signature on a document, but not to steal your key itself and use it in the future.
When run without arguments, ssh-agent forks a copy of itself to be the agent, then prints out shell commands to set the needed environment variables, and exits. Thus it can be used like this:
% eval `ssh-agent` % ssh-add ...The eval command tells the shell to run the output of ssh-agent as shell commands; thereafter, processes run by this shell inherit the environment variables and have access to the agent. It is typical to use this technique early on in login or X session startup files, so that the login shell or X window manager have the variables, and thus propagate them to every process in the user's session.
Some people express irritation over this seemingly convoluted procedure, and wonder why they can't just run ssh-agent and be done with it. In Unix, there is no way for a process to directly change the environment of other existing processes; it can only change its own environment, and those of child processes it starts. Thus, running ssh-agent cannot affect the environment of the shell which starts it the agent. Having the agent print out shell commands which can be easily executed to set the variables, is as convenient as it gets.
When run with a filename argument, ssh-agent simply execs the argument program in a child process with access to the agent; when the child exits, so does the agent. Which form to use is just a matter of convenience in a given situation.