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 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 startkdeThe 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.
ssh-add ~/.ssh/id_dsa.pubOnce 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 pinewithout 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, 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.