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

In the second part of our quick look at ssh and the steps we can take to make access to remote hosts more seamless, we examine the role of ssh-agent in storing authenticated keys so you can enjoy secure, transparent access to all the machines you maintain without having to log in every time you access them.

By Enterprise Networking Planet Staff | Posted Mar 18, 2002
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

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 time, 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
    
    or
    ssh-agent wmaker
    
    or
    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:

    http://sources.redhat.com/ml/cygwin/2000-12/msg01054.html

    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 be:
ssh-add ~/.ssh/id_dsa.pub
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 (id_dsa.pub) 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 exited.

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 like:

ssh remotehost.com -t 'tail -f /var/log/httpd/access_log'
or run a mail program:
ssh remotehost.com -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.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter