Open Source

Configure IT Quick: Use Keychain to simplify SSH connections

Learn how to use Keychain to configure secure, passwordless authentication with SSH on remote systems.

SSH has become the de facto standard for making secure connections to remote Linux machines. Although it's normally used much like Telnet—by starting a connection and then entering a password—SSH can be extended to be even more secure and, ultimately, simpler to use. That may sound hard to believe, but with the use of RSA/DSA keys and a little utility called Keychain, it’s never been easier to make secure remote connections to Linux systems. I'm going to show you how to configure secure, passwordless authentication using Keychain.

SSH security
SSH is a vast improvement over the insecure Telnet, but it still uses a single password by default as its authentication mechanism. The password is, of course, encrypted, but it's still sent over the wire. One common way to make SSH more secure is with a public/private key pair. This allows you to create a private key (usually a phrase instead of a single word) that you then enter in place of a password when logging in to a remote host.

This is done through the use of RSA/DSA authentication, which uses a public/private key scheme, and it's what will eventually allow us to connect to a remote host without a password. Basically, the public key is used to encrypt a message that only the private key can decrypt. Thus, nothing confidential is transmitted. A random number is generated on the remote side and encrypted with the public key. It is then sent back to the initiating host and a decrypt is attempted with the private key. If the near side is successfully able to decrypt the number, it is sent back and access granted.

Although this obviously increases security, it can take away from the overall ease of use. This can be helped with the use of ssh-agent, a component of SSH. Once configured, your private key is stored in memory and allows you to connect to a remote machine without entering anything at all. The problem you may come across with ssh-agent is that you need to enter your passphrase upon login, even if there is already an ssh-agent process running that knows your private key.

As an example, let’s say you have one Linux box you usually connect to in order to make outbound connections. This could be your workstation or a centralized server used by multiple users. Using only the ssh-agent method, you would have to enter your passphrase every time you log in to this main server, even if you have a connection open in another window.

One way around this problem is to keep your session or sessions open constantly. But another, more permanent solution is to use the Keychain utility. Keychain either starts ssh-agent or attaches to an existing instance and is then used on a permanent basis—at least, until the next reboot. This can be a great timesaver when you’re logging in and out of Linux servers and get tired of typing that password or passphrase every time.

Installation and configuration
You can download Keychain in RPM format here. Then, install with the following command:
rpm –Uvh keychain-2.0.2-1.noarch.rpm

This should install the script to /usr/bin/keychain. Typing keychain —help will output useful information on how to complete the installation, plus further options. Once you install Keychain on your system, you'll need to configure your SSH setup, if you haven’t already done so.

First you'll need to generate your RSA and DSA private/public key pair:
ssh-keygen –t dsa
ssh-keygen –t rsa

By default, this will create ~/.ssh/id_dsa, ~/.ssh/, ~/.ssh/id_rsa, and ~/.ssh/ RSA is the default for SSH version 1 and DSA for SSH version 2. Any recent version of OpenSSH should support both.

The output should look something like the following:
[tnooning@swingline]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/tnooning/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tnooning/.ssh/id_dsa.
Your public key has been saved in /home/tnooning/.ssh/
The key fingerprint is:

Once you've created the keys, you'll have to update some of SSH’s configuration files. For each host you'll be connecting to, append the public key (.pub) to ~/.ssh/authorized_keys:
scp ~/.ssh/ tnooning@remotehost:
ssh tnooning@remotehost
cat >> ~/.ssh/authorized_keys

Your private key should remain on the centralized server you will be connecting from and shouldn’t be distributed to any remote systems. The next step is to modify ssh_config (usually in /etc/ssh/) and set the ForwardAgent variable to "yes." This means that after you ssh to one box that accepts your key, you can ssh from there to another box and it will query the ssh-agent process running on your trusted machine. This adds an extra layer of security because only one instance of the ssh-agent is required.

After your keys are set up, you can finish the configuration of Keychain by adding the following lines to your .bash_profile:
keychain ~/.ssh/id_rsa ~/.ssh/id_dsa
. ~/.keychain/${HOSTNAME}-sh

You can then try your new setup by rereading the .bash_profile (type source .bash_profile) and attempting to ssh to a host on which you’ve modified ~/.ssh/authorized_keys.

Keychain also has a few options that may come in handy:
—clear [Used to increase security; will delete all host keys]
—noask [Does not prompt to add any recently added keys]
—stop | -k [Stops all running ssh-agent processes and exits]
—quiet | -q [Turns off verbose mode and prints only errors and interactive messages; useful for automated scripts]

If everything works properly the first time, congratulations! If you’re like me, though, it always seems to take a few times to get it all working properly. One thing to keep in mind when working with SSH is the issue of file permissions. If you have any problems, check and make sure that the file ownership is correct and all files under ~/.ssh are set to 600 and the directory itself is set to 700. Also verify settings in ssh_config and sshd_config, especially if you have any nonstandard settings. For instance, the variable PubkeyAuthentication in sshd_config should be set to "yes" if it’s not already. A number of excellent how-to's and assorted documents are available on the Internet. Do a Google search for keychain ssh and you'll find a plethora of good links.

Finding a balance between ease of use and security concerns is never easy. However SSH offers ways to simplify matters and stay protected. By configuring a private/public key pair and using Keychain, you can quickly and securely access any number of Linux servers via SSH. This allows you to connect from a central or “trusted” server to any host on which you have set up your public key. Keep in mind that although such a configuration may make it harder for someone sniffing your packets, it makes things easier if they do get access to your terminal. You can mitigate that by locking your screen or configuring an automatic screensaver with password protection so that, when you are away from your desk, someone can't hijack your connections. Security will always be a concern, but it doesn’t always have to slow advances in productivity.

Editor's Picks