SSH Key Authentication *

By Howard Draper, Computer Support Specialist, Information Security.

If you're reading this article, you probably use SSH (Secure Shell). If you don't know what SSH is, or you want to know more about it, go to SSH or type "man ssh" on a Linux/Unix environment. Typical implementations of SSH use a username and password to authenticate users. This method has considerable drawbacks:

Any password can be guessed over time
Most people don't watch their secure.log for failed login attempts
By default, the root account may be remotely logged into via SSH, leaving the system completely vulnerable if someone is able to brute-force the login credentials

If you run SSH on the standard port 22/tcp, and it's listening on our public UNT network, and password authentication is enabled, then malicious users outside the UNT domain are attempting to log in. By trying every possible character combination (and especially common ones), they will succeed eventually.

So what are SSH keys?

SSH keys are a pair of cryptographic keys used to authenticate users instead of (or in addition to) a username/password. One key is private and goes on your source device in the ~/.ssh directory, and the public key goes in the destination device's ~/.ssh/authorized_hosts file.

How long does it take to generate SSH keys?

Seconds-- although RSA takes slightly longer than DSA. See this for an actual RSA vs DSA benchmark.

So do I use RSA or DSA?

RSA has undergone more public cryptanalytic scrutiny, and is tried and true. DSA is based off a different encryption algorithms (privately developed by the NSA), and can sign faster, but verifies slower. Keep in mind this means 300 milliseconds of difference. RSA can be used to encrypt or sign. DSA is only intended for signing.

What are the commands to create and implement SSH keys?

For this instruction set, I'll use RSA for simplicity. To use DSA instead, simply specify "-t DSA" when you use ssh-keygen.

First, type the ssh-keygen command to generate your ssh-key pair.

   # ssh-keygen -t rsa
   

   Generating public/private rsa key pair.

At this prompt, hit enter unless you want to specify a custom name.

   Enter file in which to save the key (/Users/exampleuser/.ssh/id_rsa):

Now you'll be twice asked to create a passphrase. If you don't use one, you can SSH to another machine without having to type anything. However, if anyone else ever has your private key, or a copy of it, they'll have all the same connectivity privileges that you do. For this reason, we recommend that you use a passphrase, and you can use ssh-agent if you wish to only type your password once per day. If you are a system administrator and want to use blank passphrases for easy automated connections, you can bind certain commands directly to the SSH keys to limit privileges of those auto connecting accounts.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

After this, you're done with creating the keypair. Now all that's left is copying the *.pub key to your remote (destination) computer.

The following command will securely transmit the key to the destination host.

  # scp id_rsa.pub username@system-name.or.ip.address.edu:/home/username/.ssh

Now SSH into that remote machine, and move into the .ssh directory.

If you don't see a file called "authorized_hosts", then create it and move the *.pub key into it with the following command.

  # cat id_rsa.pub > authorized hosts

If the file already exists and may contain other keys already, then type this to append your key to the existing contents.

  # cat id_rsa.pub >> authorized_hosts

You may need to chmod 700 the destination's ~/.ssh directory and chmod 600 the actual authorized_keys file. These permissions requirements may vary depending on your UNIX/LINUX variant.

Now you should be able to ssh from your source to destination computer without having to use a password. At this point, to completely thwart brute-force login attacks, you can edit your destination host's /etc/sshd_config file to disallow password authentication.

BE CAREFUL DOING THIS REMOTELY; CONSOLE ACCESS IS RECOMMENDED. BACK UP THE ORIGINAL SSHD_CONFIG FILE FIRST.

  #PasswordAuthentication yes
   PasswordAuthentication no

To troubleshoot problems with SSH key connections, you can try the verbose switch with SSH.

  # ssh -v desination.IP.some.where

^*From the UNT Info Security Wiki.

CORRECTION (1/2011) -- In the interest of avoiding misinformation on this topic, the following corrections are offered to the above article.

The following command will securely transmit the key to the destination host.

# scp id_rsa.pub
username@system-name.or.ip.address.edu:/home/username/.ssh/id_rsa.pub.remoteconnect

Now SSH into that remote machine, and move into the .ssh directory. If you don't see a file called "authorized_keys", then create it and move the *.pub key into it with the following command.

# cat id_rsa.pub.remoteconnect > authorized_keys

If the file already exists and may contain other keys already, then type this to append your key to the existing contents.

# cat id_rsa.pub.remoteconnect >> authorized_keys

Originally published, June 2007 -- Please note that information published in Benchmarks Online is likely to degrade over time, especially links to various Websites. To make sure you have the most current information on a specific topic, it may be best to search the UNT Website - http://www.unt.edu . You can also search Benchmarks Online - http://www.unt.edu/benchmarks/archives/back.htm as well as consult the UNT Helpdesk - http://www.unt.edu/helpdesk/ Questions and comments should be directed to benchmarks@unt.edu