I've read the official definition:

ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA, ECDSA). The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program. Through use of environment variables the agent can be located and automatically used for authentication when logging in to other machines using ssh(1).

"a program to hold private keys" - IMHO, ssh keys are generated by a user with the ssh-keygen command and simply stored in ~/.ssh - why do I need some daemon to hold these keys? How exactly does it hold them anyways? - aren't they just stored in .ssh?

"are started as clients to the ssh-agent program" - I don't get it. Where would one need that? I usually just use ssh as this:

 ssh -i ~/.ssh/private_key_name username@hostname

What exactly does the above definition mean by "clients"? What clients? Don't you just run the ssh command from a terminal to connect to another machine? What other clients are there and why can't they just use the standard path to that private key file, just like the ssh command?

  • another benefit is that you may not have control over the call to ssh and cannot pass options regarding which key to use, and you may not want to add files to ~/.ssh. Using ssh-add and some minimal bash statements you can add keys from environment variables and make sure they get used next time someone else calls ssh for you.
    – NeilG
    Commented Feb 27 at 8:02

5 Answers 5


The SSH agent handles signing of authentication data for you. When authenticating to a server, you are required to sign some data using your private key, to prove that you are, well, you.

As a security measure, most people sensibly protect their private keys with a passphrase, so any authentication attempt would require you to enter this passphrase. This can be undesirable, so the ssh-agent caches the key for you and you only need to enter the password once, when the agent wants to decrypt it (and often not even that, as the ssh-agent can be integrated with pam, which many distros do).

The SSH agent never hands these keys to client programs, but merely presents a socket over which clients can send it data and over which it responds with signed data. A side benefit of this is that you can use your private key even with programs you don't fully trust.

Another benefit of the SSH agent is that it can be forwarded over SSH. So when you ssh to host A, while forwarding your agent, you can then ssh from A to another host B without needing your key present (not even in encrypted form) on host A.

  • 18
    I feel this is the most complete answer, but there is still one point missing. Using a key agent also allows using multiple keys easily. Instead of having to specify the path to the key, when using a key agent ssh will try every key in it.
    – phemmer
    Commented Apr 15, 2013 at 23:27
  • 13
    @Patrick which may also be it's disadvantage - try too many invalid keys on a server and it will close the connection before you got to the valid key. Of course, that's what ~/.ssh/config's IdentityFile option is good for, with or without the agent Commented Apr 16, 2013 at 11:26
  • 1
    @AndreyFedorov Yes you can have multiple keys without an agent, but you can also specify in your ~/.ssh/config which key to use for which remote host, so that it knows exactly which one it needs.
    – phemmer
    Commented May 2, 2017 at 22:04
  • 8
    so one can assume that ssh-agent is not necessary if a private key is not protected by a passphrase?
    – pkaramol
    Commented Oct 17, 2017 at 14:30
  • 1
    @pkaramol a private key without a passphrase is a security risk and for the most part ssh-agent is the answer to the security versus usability discussion that led some people to make passwordless keys. Assuming that the system memory is secure this is a much safer compromise. Aside from that, the other big benefit of ssh-agent is that SSH connections can forward the agent's socket along its connection, which can be enormously useful when you need to chain logins and ProxyJump isn't a viable option. Commented Aug 30, 2020 at 17:13

The benefit to ssh-agent is that you only need to enter your passphrase once. If your private RSA key is not encrypted with a passphrase, then ssh-agent is not necessary. The ssh command would be an example of a client.


If you are routinely sshing into a variety of different machines, each with their own key and passphrase, then running ssh-agent allows you to enter the passphrase for each key once1 at the start of your session and then you can authenticate to each machine as many times as you like without having to re-enter your passphrase.

A further benefit is that, as per the man page, the agent never sends a private key over its request channel; so if you are hopping between different boxes, your private keys are protected.

1You can set the life time that the keys are held in the agent.


Wikipedia article probably has the best description:

The verification to the server is based on challenge-response authentication. ssh connects to the server with a user name and the request for a key. The ssh daemon gets the request and sends back a challenge based on the public key stored in the authentication file. ssh uses the private key to construct a key response, and sends it to the waiting sshd on the other end of the connection. It does not send the private key itself. The ssh daemon validates the key response, and if valid, grants access to the system. ssh-agent simplifies this by creating a socket that listens for SSH connections. The user simply starts ssh-agent, telling it how to find their keys (if they are not in the default location), enters the passphrase for each key to be used, on a one-time basis, and then ssh-agent handles the rest every time the user connects to a remote server.

Again verbatim from the wikipedia article:

... ssh-agent creates a socket and then checks the connections from ssh. Everyone who is able to connect to this socket also has access to the ssh-agent. The permissions are set as in a usual Linux or Unix system. When the agent starts, it creates a new directory in /tmp with restrictive permissions. The socket is located in the folder.

It's typically put in either a system or user's rc files such as $HOME/.bashrc or $HOME/.profile (for bash shells) so that the environment variables ssh-agent set get incorporated into your environment completely.

On my Fedora 14 system it starts up pretty early as part of the X11 subsystem. In this file, /etc/X11/xinit/xinitrc-common:

# Prefix launch of session with ssh-agent if available and not already running.
if [ -z "$SSH_AGENT_PID" ] && [ -x /usr/bin/ssh-agent ]; then
    if [ "x$TMPDIR" != "x" ]; then
        SSH_AGENT="/usr/bin/ssh-agent /bin/env TMPDIR=$TMPDIR"

The variable $SSH_AGENT is then made use in other X11 start-up scripts such as here, /etc/X11/xinit/Xclients:

exec -l $SHELL -c "$SSH_AGENT $XCLIENTS_D/Xclients.$1.sh"

By incorporating it into here, the following environment variables are getting set as part of a parent shell, therefore all forked children should also have them, for example:

SSH_AUTH_SOCK=/tmp/ssh-PspRF18958/agent.18958; export SSH_AUTH_SOCK;

There is a little more complexity to this but in a nutshell this is basically what's going on with ssh-agent.

For example in GNOME, ssh-agent is actually launch per user as a start-up application:

                     ss of startup apps


Bottom line, ssh-agent exists so that when your ssh keys are required you only have to unlock them one time with their passphrase (assuming they have one), and from then on they're available in their decrypted form in memory (RAM).


"are started as clients to the ssh-agent program" refers to the idea that ssh-agent is started during (local) login session initialization so that all programs get the environment variables $SSH_AGENT_PID and $SSH_AUTH_SOCK which are necessary for connecting the agent.

Another advantage of taking the private key handling out of ssh is that ssh-agent can be replaced by gpg-agent. Thus you can use OpenPGP keys (with authentication capability) for SSH. That's a nice solution for OpenPGP keys on a smartcard.

You must log in to answer this question.

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