Previous Section  < Day Day Up >  Next Section

Recipe 17.4. Authenticating Via Public Keys

17.4.1 Problem

You would prefer to authenticate your SSH sessions with keys, rather than your system logins. This will let you use your SSH private-key passphrase instead of your system login, which means your system login is protected, and you can reuse the same public/private key pair for as many remote hosts as you need to connect to.

17.4.2 Solution

In this example, Valorie wishes to log in to saturn from jupiter. To do this, she must generate a new, personal private/public key pair with ssh-keygen on jupiter, then transfer a copy of her new public key to saturn.

This command generates a new RSA key pair, protected by a passphrase:

valorie@jupiter:~$ ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/valorie/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/valorie/.ssh/id_rsa.

Your public key has been saved in /home/valorie/.ssh/

The key fingerprint is:

79:1f:a5:5f:5f:17:e5:a8:bc:02:50:8c:3a:1e:e1:d1 valorie@jupiter

The new key pair is named /home/valorie/.ssh/id_rsa and /home/valorie/.ssh/ Now Valorie copies the new key to her account on saturn. Since this is her first entry in her authorized_keys file on saturn, she can use scp:

valorie@jupiter:~$ scp  ~/.ssh/  valorie@saturn:.ssh/authorized_keys

Now when Valorie logs into saturn, she will be asked for her private SSH key passphrase, instead of her system login:

valorie@jupiter:~$ ssh saturn

Enter passphrase for key '/home/valorie/.ssh/id_rsa':

Linux saturn 2.4.21 #1 Sun Aug 3 20:15:59 PDT 2003 i686 GNU/Linux

Libranet GNU/Linux



To close the session, she can simply type exit.

17.4.3 Discussion

OpenSSH creates both RSA and DSA keys. Both support SSH2, which is the latest and greatest, so it doesn't matter which one you choose. RSA is the default.

A single key in ~/.ssh/authorized_keys looks like this:



yUdMx02GkjA45kPLYiXMpGNCclHRHVHU= valorie@jupiter

Remember, it must be one long, unbroken line. You can store as many keys here as you like.

Another way to copy a key to an authorized_keys file on a remote PC is to simply copy and paste. Open a normal SSH session:

$ ssh valorie@saturn


Then open a text editor on each side of the connection, and copy and paste.

You can do this for any account on the SSH server to which you have access. One public/private key pair should suffice; you can copy your public key to as many hosts as you need to, and use the same passphrase for all of them.

Keep track of where you are! It's easy to type a command thinking you're at the local machine when you're logged into a remote host.

Another point of confusion is which host is the client, and which host is the server. Any host that is running the ssh daemon, and is waiting to accept connections, can be thought of as the server.

Protect your keys! Public keys must be world-readable, but only owner-writable (mode 644). Private keys must absolutely not be anything but owner readable/writable (mode 600). Never, ever share your private keys.

Beware of text editors that automatically make backup copies. Either disable this feature, be very diligent about deleting the backup copies of keys and other sensitive SSH files, or make sure that permissions are set appropriately on the backups.

Public/private key pairs are a lovely stroke of genius that allow "hiding in plain sight." The public key encrypts, the private key decrypts. So you can (theoretically) strew your public keys all over the planet without harm.

17.4.4 See Also

  • ssh(1)

  • SSH, The Secure Shell: The Definitive Guide

    Previous Section  < Day Day Up >  Next Section