Generating Secure Keys

A Note on the SSH Secure Keys Agent

The ssh-agent program allows you to cache your private ssh key(s) so that you only get the passphrase challenge once per session. It avoids having to enter the passphrase for each ssh or slogin or scp command that you use.

As all NRAO Linux systems are configured to use gdm (the graphical display manager or "greeter") for logins, the ssh-agent process is automatically started for you. You do not have to edit any configuration file, nor do you have to start it by hand. It's there for you to use.

SSH-agent for Text-only Access

For those who prefer not to use this app, or if you are using a text-only login such as a server or one of the Virtual Consoles of a Linux system.login, you may need to start ssh-agent manually. Once you have logged on, or have the terminal app running, type this:

    eval `ssh-agent`

Users with tcsh or csh as their login shell should type eval `ssh-agent -c` instead.

Laptop Users

You probably have a local account or accounts on your laptop. The best procedure for you is to generate a passphrase-enabled key (i.e., one with a non-blank passphrase) on the laptop for each account. Don't overlook any admin or root accounts which you may also have on the laptop.

See below in the For Desktop Users section for how to do the key generation. Once done, you may copy these generated files to your account on the filer at your site(s); you can use, for example:

    scp ~/.ssh/{id_rsa,authorized_keys} login:.ssh/

An alternative command, one that preserves date/time stamps, is:

    rsync -av -e ssh ~/.ssh/{id_rsa,authorized_keys} login:.ssh/

Offsite users need to use the fully qualified domain name, i.e. login.site.nrao.edu, where site is one of cv, gb, or aoc.

The login.site.nrao.edu and ssh.site.nrao.edu servers are one and the same at each site.

Either of these commands will copy your public and private key, and the authorized keys file, from your laptop to your NRAO account at your local site.

It is possible to generate separate keys for each NRAO site at which you have a unique home area, separate keys for your laptop, and separate keys for each offsite Unix account you may have at sister institutions or on a home Linux system. Doing so (with passphrase-enabled keys) would provide extra measures that may help contain damage in the event of a security breach, either here or at other institutions. The Security Staff at NRAO recognise the extra effort such a setup entails, but also the benefit as described here. We hope all staff share this awareness. See below for details on how to handle multiple sites.

Desktop Users

To generate or re-generate your ssh keys, you give the following commands in a terminal window:

    ssh-keygen

Make sure you enter a good, memorable passphrase. This will generate an RSA key pair: id_rsa being the private key (and protected so only you can read it), and id_rsa.pub being the public key. The private key is encrypted with your passphrase. RSA keys are now preferred for enhanced security.

Then enter these commands:

    cd ~/.ssh
    cp id_rsa.pub authorized_keys
    chmod 0644 authorized_keys

You can change the phrase on your private key later by using this command:

    cd ~/.ssh; ssh-keygen -p -f identity

It will prompt you for old phrase, and the new one (twice for verification). There is no need to alter the public key; the passphrase is used only to "unlock" the private one.

Adding Your Key to the SSH Agent

Suppose you have just logged in to a brand new gdm session on your desktop or laptop, sometime after having generated the keys as shown above. In a terminal window, type this:

    ssh-add

This will prompt for your new passphrase. For more security and a GUI, you can instead type:

    ssh-add </dev/null

After either of these, you can verify that your key is in the agent by giving the command:

    ssh-add -l

Now, you can use ssh to connect to other local systems (those where your account shares the same home directory). Example: From my desktop in Charlottesville, I want to log into the bonobo system in the AIPS Caige across the hall. I simply type:

    ssh bonobo

in a terminal window, and I am able to get in with no password or passphrase challenge, because my ssh-agent took care of the authorization for me. Not only that, it automatically forwards both agent and X11 information, so further ssh connections from bonobo elsewhere will work, and any X applications will also show up on my desktop screen.

The ssh command has options to disable agent forwarding and/or X11 forwarding; see the manual page (man ssh) for details.

If it ever becomes necessary, you can delete all keys from the agent with:

    ssh-add -D

Finally, when you log out of your desktop or laptop (i.e., end your gdm or X11 session), your ssh-agent will also be shut down. You will need to activate it again the next time you log in.

Multiple Site Issues with Secure Keys

See the note above about the possibility of generating different keys on systems with different home areas.

Before proceeding with these instructions, you may want to remove (or move) old keys and files from the remote ~/.ssh/ area.

Most users now have a single home area on Unix/Linux systems across NRAO. This means that CV staff who travel to GB or the AOC will get their CV filer login area when they log into systems in GB or NM. However, some users had "legacy" pre-existing accounts with separate home areas in CV, GB, and NM and these separate home areas have been preserved. If you have separate home areas at multiple NRAO sites, you can verify this by logging in to each login host login.site.nrao.edu and typing df . to see on which filer your home area lives. If you have only one login area, and have gone through the key generation as shown above, there is no need to do anything more.

If you have separate home areas at different NRAO sites, and/or if you want to set up secure key based permissions between NRAO and accounts at other institutions or at home (using encrypted, passphrase-enabled keys only!!!), here are two possible strategies to achieve this. Please only choose one of them.

1. Either use the scp command shown above to copy your keys from your local site to the other remote site(s). For example, to copy keys generated on login.cv.nrao.edu to login.gb.nrao.edu you give this command on a CV system:

           scp ~/.ssh/{id_rsa,authorized_keys} login.gb.nrao.edu:.ssh/
        

   You will of course be prompted for the password to your account at the remote site for this command. After the keys are in place, that should no longer happen; scp commands will get you in without a password challenge, as long as you have added your key to the agent with ssh-add at the start of your gdm (X11) session.

   This command does not copy your public key id_rsa.pub to the remote site; it's already in your authorized_keys file anyway.

2. Alternatively, you can use ssh login.gb.nrao.edu (continuing the example above), and go through the procedure of generating a completely separate set of keys there. Then you need to decide on the trust relationship you want between the different accounts.
   
   
   • To permit your CV key to allow you into the GB account, you append the CV public key to the GB authorized_keys file. This can either be done by copying and pasting in editors in two windows, or in a single command on the GB (remote) system:

                ( ssh login.cv.nrao.edu cat ~/.ssh/id_rsa.pub ) >>~/.ssh/authorized_keys
             

     Note the two >> greater-than signs, not one; this appends instead of overwriting the target file!

   • To permit your GB key to access your CV account, you want to append the GB public key to the CV authorized_keys file.

The authorized_keys file can contain many records (each comprising of one rather long line of text) for many keys. Further, you have additional control in this file over the source of the connections you will allow; you could for example prepend a key in the file with the string from=*.nrao.edu to restrict access to NRAO domain names. See the manual page on the ssh daemon (man sshd) for details, and the manual page on ssh_config for the wildcard patterns you can use.

What's the authorized_keys2 File?

Many of us may find we have both an authorized_keys file and another called authorized_keys2. You do not need two separate files anymore. When the second version of ssh came out years ago, it had the ability to use DSA keys as well as RSA keys. However, servers running older versions of the ssh server could not cope with the new DSA keys, so this workaround was used: put DSA keys in the authorized_keys2 file and keep RSA1 keys in the authorized_keys file.

However, because of numerous updates and security fixes, just about nobody is (or should be) running a ssh server that only supports ssh version 1. So it is safe to kust have a single authorized_keys file in your ~/.ssh/ directory.