Ssh Setup with Public Keys

Explains how to avoid having to type in a password every time you use ssh to log in or transfer files. This is for openssh on Gentoo Linux. There may be differences for other host and target operating systems and ssh clients.

Use the space bar or right arrow for next slide,
left arrow to back up. Use 'a' key to toggle between single page and slide modes.

1. Generate Keys

Do this only once on your primary workstation (e.g., your laptop computer).

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/baker/.ssh/id_dsa): (hit enter)
Enter passphrase (empty for no passphrase): (hit enter)
Enter same passphrase again: (hit enter)
Your identification has been saved in /home/baker/.ssh/id_dsa.
Your public key has been saved in /home/baker/.ssh/id_dsa.pub.
The key fingerprint is:
6c:a4:bf:77:82:b2:d4:f6:e0:3e:0e:66:45:e2:ae:e3 baker@sis
The key's randomart image is:
+--[ DSA 1024]----+
|                 |
|                 |
|      . o        |
|     . *         |
|      o S        |
|     . =         |
|      * =.       |
|    .=.+o+o .    |
|   .E..==o.o     |
+-----------------+

That will have created for you a private DSA key id_dsa and a public DSA key id_dsa.pub Now protect it.

$ chmod 700 /home/baker/.ssh/id_dsa

This will create a private key without a passphrase It would be more secure to include a passphrase, so that someone who gets your private key cannot use it to access your computers without also having the passphrase. However, then you would need to enter the passphrase every time you use a Git command with ssh.

If you do this, you will need to be very careful to protect your private key. In particular, you should make the Unix access mode 700, to prevent any other user from reading it.

Still, if someone hacks into your workstation, they will be able to get your private key and use it to escalate their break-in to all the other machines where you have set up certificate-based ssh authentication. For this reason, don't copy your private key around to other machines. If you want to plug this hole better, read about ssh-agent.

2. Install Public Keys on Remote Host

Using sftp, scp or some other file transfer technique, copy the public key file ~/.ssh/id_dsa.pub to the remote host, e.g., sis.cs.fsu.edu.

$scp ~/.ssh/id_dsa.pub baker@sis.cs.fsu.edu

Then log into the remote host, and append the content of each file to ~/.ssh/authorized_keys.

$cat id_dsa.pub !/.ssh/authorized_keys

3. Check your Ssh Client Configuration

If you are now able to log in to the remote host from your workstation without providing a password, you succeded. If you have such a problem with sis.cs.fsu.edu, please let me (baker@cs.fsu.edu) know. For other systems, check with the system administrator to make certain the ssh servers is configured to support certificate-based authentication.

4. Setting Up X11 Forwarding

You can set up X11 forwarding through your ssh connection, but beware that it may be very slow if you are not working from within the CS local area network. If I do this from my home computer it takes so long for a remote emacs window to come up initially, and so long to refresh the screen, that I have given up using it.

You can read about X11 forwarding at http://en.gentoo-wiki.com/wiki/X-Forwarding.

I believe sis.cs.fsu.edu is set up to allow this, so you should only need to do the set the user-specific set-up. However, remember on Linux systems to use the "ssh -Y" command line option to activate X11 forwarding when you connect.

References