|This article needs additional citations for verification. (May 2010)|
Public-key cryptography plays the central role in the idea of logging into a server from a local machine via SSH. The main point is that a key pair will be generated consisting of a private key and a public key. The public key is available for everyone and often stored on public key servers. Any user has access to this key, whereas the private key must be kept secretly. Messages encrypted with the public key can be decrypted with the private key. Messages signed with the private key can be verified with the public key.
A password-based authentication process (in the common example of OpenSSH) may be vulnerable to brute-force attacks, if no mechanism is in place to detect them. To mitigate this lack of security, ssh supports public key authentication. In order to log in securely to a remote system via a secure shell, a private key/public key pair is generated. The private key is stored on the local machine. The public key is stored on the target machine in the
$HOME/.ssh/authorized_keys file. Public keys are not sensitive information and may be known to anybody, whereas the private key needs to be protected very carefully by a strong passphrase.
ssh-agent remembers the decrypted private key so that the user does not need to type a passphrase every time he or she wants to connect or send data to the server.
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.
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.
There is a possibility to try to prevent malware from using the
ssh-agent socket. If the
ssh-add -c option is set when the keys are imported into the
ssh-agent, then the agent requests a confirmation from the user using the program specified by the
SSH_ASKPASS environment variable, whenever
ssh tries to connect.
On the local system, it is important that the root user is trustworthy, because the root user can, amongst other things, just read the key file directly. On the remote system, if the
ssh-agent connection is forwarded, it is also important that the root user is trustworthy, because they can access the agent socket (though not the key).
There are many different programs that perform the same functionality as the original OpenSSH ssh-agent, some with very different user interfaces. PuTTY, for example, uses a Graphical User Interface in its bundled Pageant ssh-agent.
There are tools designed to provide key-agent functionality for both symmetric and asymmetric keys; these usually provide ssh-agent functionality as one of their application interfaces. Examples include GNOME Keyring and KWallet.
Some monolithic SSH clients include the ability to remember SSH passphrases across sessions. Examples include: SecureCRT.
Status on Mac OS X
On the Mac OS X operating system, ssh-agent has been integrated since Leopard (version 10.5). Third-party open-source implementations of ssh-agent were available previously, and are still popular with some users.