Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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 user with ssh-keygen command and simply& straightforward 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 manual means by "clients" - what clients? Don't you just run ssh command from terminal to connect - what other clients are there and why can't they just use a path to that ssh private file, just like ssh command?

share|improve this question
add comment

5 Answers 5

up vote 22 down vote accepted

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 pass phrase, so any authentication attempt would require you to enter this passphrase. This can be undesirable, so the ssh agent caches they 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.

share|improve this answer
5  
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. –  Patrick Apr 15 '13 at 23:27
2  
@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 –  Tobias Kienzler Apr 16 '13 at 11:26
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.
SSH_AGENT=
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"
    else
        SSH_AGENT="/usr/bin/ssh-agent"
  fi
fi

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;
SSH_AGENT_PID=18959; export SSH_AGENT_PID;

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

TL;DR

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).

share|improve this answer
add comment

"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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.