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 www.openssh.org. 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 do:
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
- 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 id_dsa.pub, the public key.
- Copy the id_dsa.pub key over to the host on which you want
remote access. This can be accomplished using the scp
scp ~/.ssh/id_dsa.pub email@example.com: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 'remotehost.com (192.168.1.5)' 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."
- Log in to the remote host using the ssh command:
ssh remotehost.comIf your login name on the remote host differs from that of your local login name, you can use the '-l' switch:
ssh -l joe remotehost.com
- 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:
- assign your new .ssh directory proper permissions:
chmod 700 ~/.ssh
- then copy your public key (id_dsa.pub) to the file .ssh/authorized_keys2
cat id_dsa.pub >> .ssh/authorized_keys2
- then make sure that permissions on .ssh/authorized_keys2 are set
correctly (writable only by the owner):
chmod 644 ~/.ssh/authorized_keys2
- 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 remotehost.comYou'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 id_dsa.pub key to each host and appending it to ~/.ssh/authorized_keys2, also making sure that permissions on that file are set appropriately each time.
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.
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.