When you first try to login to a remote server you need to authenticate yourself, which means you have to demonstrate that you have rights to be on that server.  You can do this in several ways:

1. Password – You authenticate to the server by typing in your password. This is easy because you can generally remember your password, and it means you can easily login from any computer with that knowledge. This is still the most common authentication mechanism for SSH. It is also the least secure.
2. Public Key – This is much more secure. It involves the creation of a key pair, of course. It is possible to use a key pair generated by PGP or GPG in the most current versions (version 2.0.13 introduced support for this). But there is a long established method using the Unix program ssh-keygen. This is very similar to generating a key pair as we discussed earlier. You run the program ‘ssh-keygen’, harvest some entropy, generate a passphrase to protect it, and so on.
3. Kerberos – This is done through the General Security Services API. This is a programming interface that is broader than just Kerberos—it is supposed to encompass several possibilities, and of course as an API it abstracts from the details. But the GSSAPI library included supports only Kerberos, so it is not yet as general as it might become.
4. Keyboard-Interactive – The server sends one or more prompts to the client to enter certain information. This is not compatible with all client software, however. But it would work in a terminal.

I won’t go into detail on the last two of these, as I consider them very specialized. If you need to know more on either of them a Google search would probably turn up what you need. The most common methods are either entering a password, or using a public key. And like so many things in security, there is a tradeoff between security and ease of use. Passwords are the simplest and easiest way to authenticate, and everyone knows how to use one. But it is also true that passwords can be compromised in a variety of ways. People may use a single password for everything, or they might use a password easily guessed. Or it might be written on a sticky note “hidden” under the keyboard. Or it might be given to someone else to use, particularly in a corporate environment where many people may need to access the same resources. Since the whole idea of using SSH is to increase the security, I don’t like relying on passwords if there is an alternative. And increasingly, public key is that alternative.

Public Key Authentication

The starting point for this is generating the key pair. As we say previously in our tutorial on Symmetric vs. Asymmetric Encryption, there are several possible algorithms that can be used, with RSA still the most common. And the way this works is that you generate two keys, such that key1 will decrypt anything that key2 encrypted, and key2 will decrypt anything key1 encrypted. Arbitrarily one of these is designated as the public key, and the other as the private key. Your algorithm choice is generally from RSA,  DSA, and ECDSA. RSA uses large prime numbers to get its keys, DSA (Digital Signature Algorithm) uses discrete logarithm mathematics, and ECDSA (Elliptic Curve DSA) use Elliptic Curve mathematics. All of these are examples of a one-way algorithm, which means that it uses a computation that is easy to do, but extremely difficult to do in reverse. Right now it looks like RSA is more widely used, but DSA is slightly stronger, and ECDSA is fairly new but coming up fast because it is highly efficient. Since RSA is widely used, it makes sense to go with RSA unless you have a strong reason not to.

Your next decision is the key length, and here the default should be 2048. 1024 is more than the current record for brute force cracking, but not that much more. If you have a current computer, go for 3072. If you want more information on the ssh-keygen command, try the man page. This should give you two files which will reside in the same ~/.ssh/ directory as your known-hosts file. One will be your ID name_rsa (assuming you used RSA), or sometimes just id_rsa, which will be your private key. The other will be your ID name_rsa.pub, or sometimes id_rsa.pub,  which will be your public key. Many systems have a default for bit-length, which may be 2048, but you can use a command line switch of -b to set this. Consult the man page for ssh-keygen, or go to this online version: http://linux.die.net/man/1/ssh-keygen.

NISTIR 7966 is a document that is in review and comments right now that addresses many of these issues, and you can read the draft at http://csrc.nist.gov/publications/drafts/nistir-7966/nistir_7966_draft.pdf.

There are two key switches, then, that you might want to know about when using the ssh command. The first one is the “-b” switch, which lets you set the bit-length of the key. If you are comfortable with 2048 that will probably happen by default, but you can specify 3072 or 4096 if you prefer. But the second switch can modify how you look at this because it specifies the type of key, and the is the “-t” switch. Possible values for this include:

• dsa
• ecdsa
• rsa

What you need to remember here is that the appropriate keylength depends on the encryption algorithm being used. ECDSA is more efficient, but is newer and may not be accepted in all situations right now. I would recommend for safety that you stick with RSA, but increase the bitlength to 3072 with this command:

ssh-keygen -t rsa -b 3072

This will work like this:

kevin@Kimball:~$ ssh-keygen -t rsa -b 3072
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kevin/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kevin/.ssh/id_rsa.
Your public key has been saved in /home/kevin/.ssh/id_rsa.pub.
The key fingerprint is:
2b:68:7f:15:bd:14:e8:08:aa:4d:ac:ee:f8:42:11:51 kevin@Kimball
The key's randomart image is:
+--[ RSA 3072]----+
| .oE . |
| . . . . |
| .. . . o . . |
| . + . o o |
| .= S o . |
| .o .. .. . |
|.. o . .. |
|.... . .. |
|.+o .. |
+-----------------+


You can specify a different file to save your key in, the default is usually fine. The passphrase is not shown for security, so the system compares them. Note that there is no way to recover a passphrase, so make sure oyun remember it or store it safely. And the randomart image is something I ignore, though some people say they can tell if it is the right image, which would get you some security I suppose.

If you are a Windows user, try downloading puttygen.exe, which works with PuTTY. Instructions can be found at https://kb.siteground.com/how_to_generate_an_ssh_key_on_windows_using_putty/. Your two files will be C:\Users\Your ID Name\.ssh\your ID name_rsa (private key), and C:\Users\Your ID name\.ssh\your ID name_rsa.pub

Here is an example of a public key file:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDWO6yEpN8Wp4un0yJp3L4cwc3D9Amzu7ijHeuczIhCaG3kz1AclNe7U+WEMAzVbJk+zj30PpBu376evv7izu2cefMMnnlf1lzndnd0DGhA4vVG0hqKCpsBdKe5yX+UkhVahNqL0js3mI8CMZtkE+zK59IaygR+6Xqg8KSwWPKznjne28ynBIx03LYfynE4Tbi8ILQQyx+Bom/EPv+UxLsdJ0OyCuvE6kHdUYGVpr1SOti6pDGGYbJNNiuKrjdn7SF6Pp7Y1xSkAW6ZC9CGMgiaSVtEQM/2jmVJztW2mnZWnLZWQwitC6E6tH+beznXZfg4G4Kau7slNK0QFc3wABfwQyx7PzN9R4N2fnZXbJBKwLEH4M9VWi2gbFxbsJIKqY3UJ30uhVmS3B7kfo6Ua8iWyXnL6pUV13OzV3S/24QQB2JGPB7Pg2WnJu1Gs9LfEgVmqS9nuCe5wEHh4u9a1hnccBBpDqhmMuXNtrwbARXNm/lCLQwL2shIJKBxNTe74n8= kevin@Kimball

Note that at the start it says ssh-rsa, which identifies the kind of key it is, and at the end it says = kevin@Kimball, which is my login name and the name of the machine I created it on. In between is the public key, and like all public keys it can be freely shared, so this is not a security risk. When you add it to the authorized_keys file, the server can use your public key to encrypt a symmetric key that will be used to encrypt the connection. Only your private key can decrypt this. If you need a refresher on this, take a look at the previously mentioned tutorial Symmetric vs. Asymmetric Encryption which covers this. The reason we use a symmetric key is that it is more efficient, but we use the key pair to securely transmit this symmetric key.

Final Caution

There are some things to keep in mind here. First, just as with your PGP key for e-mail, which we discussed previously, if you lose your key you are in trouble. Backing up is important. If you don’t back up your keys, you may find one day that you no longer have access to those remote systems. You might be able to get new access by deleting the old keys and getting new ones added, but if you log into a lot of sites that will be a royal pain. Also, what happens if a computer that has your keys on it is decommissioned, sold, or compromised in some way? How secure is your access now? One recommendation is that you don’t use the same keys on different machines to help guard against this. It might seem like additional work to create key pairs on each machine separately, but if the point is security it just might be a good idea. Note that when you create the ssh key pair you are asked for a file name to save it to. By default, my Kubuntu systems simply call it “id”, while other systems may put in your username. But you could create a key with the name of the remote site and do that for each site you want access.

Listen to the audio version of this post on Hacker Public Radio!