Crossnodes Tip: Secure and Convenient? Key Authentication with OpenSSH

The ssh protocol has become remarkably important to administrators
and remote workers everywhere. By providing an encrypted login
session between a user and a remote system, it ensures that many of
the attacks that caused problems with insecure protocols like telnet
and ftp are less of a threat. It also allows for more advanced uses,
such as providing an encrypted tunnel through which data from other
protocols can pass, adding a layer of encrypted armor to traditionally
less secure services like IMAP, POP, and SMTP.

We’ll look at the OpenSSH implementation of the ssh protocol,
primarily because as a client it happens to be easily available on a
wide variety of operating systems: the Windows family, Mac OS X, and
assorted UNIX variants. The OpenSSH home page is located at For Windows users,
the best way to get OpenSSH is through the Cygwin ports collection. We’ll
assume that the ssh server being accessed on the remote host is a
UNIX variant of some sort.

The first part of this multipart tip will center around creating a
key pair for accessing remote systems that have a SSH server of some
sort running on them. The benefit of creating a key pair, especially
for those who interact with a number of different hosts, is that it
provides an easy way to log in to a variety of machines without having
to remember a large collection of passwords. In fact, a properly
tuned SSH setup can make the act of logging in to dozens of systems
almost transparent by allowing for one-time configuration that hides
nuisances like differing user names from system to system.

With this ability comes some responsibility, which we’ll touch on
at the end of this tip: a single key for accessing everything is a
blessing in terms of convenience, and a potentially disastrous curse
in terms of security. The temptation will exist to skip assigning a
password to a key pair in order to enjoy passwordless logins, but this
is a dangerous and reckless idea. In the next few days, we’ll examine
how to achieve a similar effect that provides for more security, so
please stick with us when we say:

Assign a very strong password to any keys you plan to use for
production environments: there are ways to make ssh less cumbersome,
and we’ll cover them. In the mean time, just enjoy the convenience of
a single password (guardedly).

Almost every implementation of the ssh protocol allows for a
variant on these activities of some sort, so once you’ve stepped
through this tip a few times, you should be able to apply the
principles with other implementations and programs, such as SecureCRT (which
we’ll be reviewing shortly) without a lot of trouble.

So, before getting into the details, here’s an overview of what we’ll

We’ll create a key pair that will allow us to access remote
hosts with a password we assign to our key instead of the password we
use on the remote host itself. There’s not a lot to say about key
pairs except that they’re comprised of two parts: a private key that
must be kept secure, and a public key against which the private key
can be checked. We’ll copy the public portion of our key pair over to
the remote hosts we want access to, then make sure the public key is
located in the right place and has the proper access permissions.

Step By Step

  1. Create a key pair using the command ssh-keygen -t dsa.
    The ‘-t’ switch designates the keytype. ssh2, the more secure
    version of the ssh protocol, uses DSA keys. When prompted, provide
    a secure password: it’s important that this be a strong password
    that’s hard to guess. By default, ssh will want to place the keys in
    ~/.ssh. It will create two files: id_dsa
    (the private key) and, the public key.

  2. Copy the key over to the host on which you want
    remote access. This can be accomplished using the scp

    scp ~/.ssh/ [email protected]:

    where ‘user’ is your username on the remote machine.

    At this point in the process, you may see something similar to:

      The authenticity of host ' (' can't be established.
      DSA key fingerprint is 73:39:c1:f1:5d:6b:a0:6f:28:83:13:a5:da:5e:2c:26.
      Are you sure you want to continue connecting (yes/no)?

    to which it’s appropriate to respond “yes.”

  3. Log in to the remote host using the ssh command:

    If your login name on the remote host differs from that of your
    local login name, you can use the ‘-l’ switch:

    ssh -l joe
  4. You’ll be prompted for your password on the remote host. Once
    logged on, the public key you copied
    over has to be appended to the authorized_keys file in the ~/.ssh
    directory on the remote host. If you don’t have a .ssh directory on
    the remote host, create it:

    mkdir ~/.ssh
  5. assign your new .ssh directory proper permissions:
    chmod 700 ~/.ssh
  6. then copy your public key ( to the file .ssh/authorized_keys2
    cat >> .ssh/authorized_keys2
  7. then make sure that permissions on .ssh/authorized_keys2 are set
    correctly (writable only by the owner):

    chmod 644 ~/.ssh/authorized_keys2
  8. At this point, it’s possible to log out of the remote host and log
    back in again using the ssh command:



    ssh -l your-remote-username

    You’ll be prompted for the password of your key this time, not your
    password on the remote host.

For people who have accounts on quite a few systems, repeat the
steps of copying the key to each host and appending it to
~/.ssh/authorized_keys2, also making sure that permissions on that
file are set appropriately each time.

A Caveat

Having copied your public key over to ~/.ssh/authorized_keys2, life
has just become a little easier: it’s no longer necessary to keep your
passwords straight on every host since authentication is now handled
via the public key. On the other hand, that really underscores the
importance of having a strong password for the key to be used: if a
cracker learns it and manages to steal a few minutes in front of your
workstation (or just copies your private key (id_dsa) to a floppy and
walks off), he’s got access to every machine you do with the same
single password.

If you should discover that your key has been compromised,
immediately try to log in to each machine and either remove the key
from ~/.ssh/authorized_keys2 by editing the file (if you have more
than one public key in use on that machine) or by simply removing the
~/.ssh/authorized_keys2 file altogether and simply going back through
the procedure to create a new key and disseminate to all the remote
hosts on which you need access.

What’s Next:

Now that you’ve got a key pair created and you’re happily visiting
remote hosts with it, the next step is figuring out how to make life
easier yet. Next time, we examine how to use the ssh-agent
to store and remember your keys during a computing session so you only
have to use your password once to gain access to every machine on which you
have a key.

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