CrossNodes Tip: OpenSSH Revisited: Simplify Remote Access with ssh-agent

This is the second part of a look at how to use public key
authentication with OpenSSH to simplify remote logins to a variety of
hosts. The last
, we outlined the steps to create a key pair and install the
public key on remote hosts and discussed a few of the issues that
arise from entrusting login access to a variety of machines to a
single key.

This time, we’re going to look at how to use something called the
ssh-agent to remember the keys to which we know the passwords. Put
simply, the ssh-agent can be told to provide authentication to our
password-protected keys whenever they ask for it — without a user
having to type the password to the key in each and every time.
Consequently, if a user visits a collection of remote hosts that all
use the same keypair, they’ll only be prompted for a password when
they add their key to the ssh-agent pool of authenticated keys.

Once again, we’re assuming use of OpenSSH, though the popular
SecureCRT, a Windows SSH client, has a configuration option (under
Global Configuration/SSH2) that allows for storage of keys in its own
agent): after this tip, SecureCRT users may understand that option a
little better.

There are a variety of ways to start ssh-agent, but none of them
involve simply running the program “ssh-agent,” which will not work on
its own. Instead, ssh-agent has to either be invoked as a parent
process of the user’s login, or through use of the UNIX ‘eval’
command, which sets key variables needed for processes to communicate
with the agent once it’s loaded:

  • As a parent process to a user’s X login: Those who use X
    window may have the easiest time of all using the ssh-agent, since
    all that’s required is a quick modification of their ~/.xsession or ~/.xinitrc
    file, by adding a line like:

    ssh-agent gnome-session


    ssh-agent wmaker


    ssh-agent startkde

    The key point here is that ssh-agent will run, export key
    environmental variables needed by the entire X session, then launch
    the user’s preferred GUI.

  • As a forked process: The next approach makes use
    of the eval command under UNIX systems (or the Cygwin
    Windows environment) to run ssh-agent in
    the background and initialize its needed environmental variables.
    This is done by running the command:

    eval `ssh-agent`

    This causes ssh-agent to run, set up its variables, and fork to the
    background where it will listen for requests to add keys or provide
    keys to servers that request them.

  • As a parent process to a Windows login: Cygwin OpenSSH users have a
    slightly harder row to hoe if they’d like to use a ssh-agent launch
    process similar to that of X Window users, outlined here:

    Essentially, the author recommends creating a series of
    customized batch files that launch the Windows explorer.exe GUI as a
    child process of the agent.

Whatever method is used to start ssh-agent, the next step is adding to
its bank of authenticated keys. This is easily achieved with the
ssh-add key, which, by default, adds the key ~/.ssh/identity
or can take the name of another key as an argument. Consequently, for
the keys generated in the first
part of this tip
, the command to add a key to the ssh-agent would

ssh-add ~/.ssh/

Once that command is run, a prompt for the key’s password will appear.
Upon typing the correct password, that key is authenticated, and any
attempt to log in to or run an application on a remote server on which
the matching public identity ( is correctly installed will
result in a login or successful authentication without having to use a
password for the key again. The agent will continue to run until
either the agent is killed:

eval `ssh-agent -k`

or until the process the ssh-agent spawned (for X Window users) is

Putting it Together

So having learned how to generate a password-protected public key
pair, and having learned how to invoke the ssh-agent to store key
passwords, it’s now possible to log in or run commands on a variety of
remote hosts without having to remember a login password every time.
This raises an issue we’d be remiss to ignore:

Once a key is authenticated, security becomes a physical issue.
In other words, if you authenticate a key at your workstation,
anyone attempting to use your workstation to access a remote ssh
server will be granted the same ease of access you enjoy. Remember
to log out or run the eval `ssh-agent -k` command when
you’re going to be out of sight of your computer.

This also raises some additional convenience issues: it’s now much
easier to run a command on a remote system. For instance, with an
authenticated key, a user can check a remote system log with a command

ssh -t 'tail -f /var/log/httpd/access_log'

or run a mail program:

ssh -t pine

without having to enter a password when prompted.

Similarly, establishing secure tunnels and performing copy operations
with ‘scp’ become much more simple and transparent.

Once again, though, use of ssh-agent and public key authentication
places a responsibility on the user to utilize strong, hard-to-guess
passwords and to remain mindful of physical security issues.

Next Time

Next time, we’ll take one more look at SSH, with a quick tour of the
configuration files, which can be used to simplify the issues surrounding having
multiple user names on multiple remote hosts, and we’ll also examine
how to ensure that a ssh key may only be used for very specific
purposes, thus limiting the potential liabilities easier ssh access
can create.

CrossNodes Net Tips are a regular feature of CrossNodes. If you have a networking tip or trick that you’d like to share, please submit it to the Managing Editor. There can be no financial remuneration, though we will place your byline upon request.

Click here for the complete index to CrossNodes Net Tips.

Latest Articles

Follow Us On Social Media

Explore More