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/id_rsa.pub.
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/id_rsa.pub. Now Valorie
copies the new id_rsa.pub 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/id_rsa.pub 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
valorie@saturn:~$
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:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAnYF8XfIqzuOIOXNw07143OhjOt4OuSN9NgWY8zlB7UkTQNu
AFXo2UWNU2WLDMPu3mJ6V1ixf49+wdfoENvWXNMuuAFiPHopHk2+PPHN750LxlD8kvJc7BMTtYCU7GLj6lpH1OyOgl
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
Password:
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
| 
