Encryption V

Configuring SSH to Use Public Key Authentication



In addition to authenticating to the SSH server with a username and
password combination, you can also configure your sshd daemon to allow
authentication using an RSA or DSA public key.


For this to work, the public key of the user on the client system must be stored in the



~/.ssh/ authorized_keys 



file in the home directory of the user on the server system that you will 
authenticate as. To do this, you need to securely copy the public key from 
the client system to the server system. The private key, of course, remains
on the client system.




If you configure the SSH server to use public key authentication:


a) The SSH client tells the SSH server which public key should be used for
    authentication when the SSH session is initially established.

b)The SSH server then checks to see if it has that client’s public key; if
    it does, it will generate a random number and encrypt it with that
    public key.

c) It then sends the encrypted number to the client, which
   decrypts it using the private key associated with the public key.

d) The client then calculates an MD5 checksum of the number it received from
     the server.

e) It sends the checksum back over the SSH server system,
    which then calculates its own MD5 checksum of the number it originally
    sent. If the two checksums match, the user is automatically logged in.



To configure public key authentication, the first thing you need to do
is create the public/ private key pair on the client system so that
you can send the public key to the SSH server. This can be done using
the



ssh-keygen 



command. Complete the following:





1. At the shell prompt of the client system, enter



ssh-keygen –t rsa




or



ssh-keygen –t dsa



depending on which encryption method your SSH server supports. To be safe,
you can simply use both commands to make two key pairs—one for RSA encryption
and the other for DSA encryption.





2. When prompted for the file in which the private key will be saved,
press enter to use the default filename of 



~/.ssh/id_rsa 



or



~/.ssh/id_dsa




The associated public key will be saved as




~/.ssh/id_rsa.pub 



or



~/.ssh/id_dsa.pub




respectively.


3. When prompted, enter a passphrase for the key. It is important that
    you use a passphrase. If you don’t, then anyone who manages to get a
    copy of your key files could authenticate to the SSH server without
    being required to enter a passphrase. Assigning a passphrase to the
    key renders the key useless if someone doesn’t know it.


    At this point, your key pair is created. An example of creating an RSA
    key pair is shown here:


    rtracy@ws1:~> ssh-keygen -t rsa
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/rtracy/.ssh/id_rsa): Enter
   passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/rtracy/.ssh/id_rsa. Your
   public key has been saved in /home/rtracy/.ssh/id_rsa.pub. The key
   fingerprint is: ba:14:48:14:de:fd:42:40:f2:4b:c8:8b:03:a4:6d:fc
   rtracy@ws1
   The key's randomart image is:


+--[ RSA 2048]----+
| . +oo |
|oo + = o |
|o + = + o |
|o++o . |
| oEoS. |
| . o. |
|o|
| .. |
|.|
+-----------------+



rtracy@ws1:~>



The next thing you need to do is to copy the public key you just
created to the SSH server. 



An easy (and secure) way to do this is to use the 



scp 


command you learned about earlier in this chapter. The
syntax is




scp ~/.ssh/key_name.pub   user_name@address_of_SSH_server:filename





In the example shown here, the RSA public key for the local rtracy
user on WS1 is copied to the home directory of the rtracy user on WS3
and saved in a file named keyfile:



rtracy@ws1:~> scp ~/.ssh/id_rsa.pub ws3:keyfile
Password:



id_rsa.pub                                    100%  392     0.4KB/s   00:00
rtracy@ws1:~>


At this point, the contents of the key file you just copied need to be
appended to the end of the 



~/.ssh/authorized_keys 


file in the home directory of the user you will connect to the SSH server as.



An easy way to do this is to connect to the SSH server system using a standard
(password- authenticated) SSH session and then use the cat command to
append the contents of the key file to the end of the



~/.ssh/authorized_keys 



file in the user’s home directory. An example of how to do this is shown here:


rtracy@ws1:~> ssh -l rtracy ws3
Password:
Last login: Thu Jun  2 15:05:34 2011 from 192.168.1.84
rtracy@WS3:~> mkdir ~/.ssh
rtracy@WS3:~> cat keyfile >> ~/.ssh/authorized_keys
rtracy@WS3:~>


In this example, I logged in to the WS3 system via an SSH connection
as the remote rtracy user and then created the hidden .ssh directory
in that user’s home directory. I had to create the directory because
it didn’t exist yet. If the .ssh directory already exists, you can
skip this step and just append the contents of the key file to the end
of the authorized_keys file. 



Notice in the example that I used the cat command with the >> redirection 
characters to add the contents of the file named keyfile to the end of the authorized_keys file.





In this example, the authorized_keys file didn’t exist yet, so the
redirection process automatically created it for me. Because of this,
I could have actually just used a single > redirection character
because the file didn’t exist.




If, on the other hand, the authorized _keys file does already exist,
it’s very important that you remember to use the >> redirection
characters instead of >. Remember, using >> will append the output of
the command to the end of the specified file. Using a single
redirection > character will overwrite the entire file with the output
of the command. That wouldn’t be a good thing if the authorized_keys
file already had several keys in it that you wanted to keep.




You can now test the configuration to see if public key authentication
works. If you’re still logged in to an SSH session with the SSH
server, exit out of it. Then establish a new SSH session with the
server. You should be prompted for the key file’s passphrase instead
of a username and password, as shown in Figure 18-9.





Once you enter the passphrase, you will be authenticated to the SSH
server. Notice in the next example that no password was requested to
establish the SSH session:




rtracy@ws1:~> ssh -l rtracy ws3
Last login: Thu Jun  2 16:13:39 2011 from 192.168.1.84
rtracy@WS3:~>



If desired, you can use the



ssh-agent 



command to eliminate the need to enter the passphrase every time you establish 
an SSH connection.



Complete the following:




1. At the shell prompt of your client system, enter



ssh-agent bash


2. At the shell prompt, enter


   ssh-add ~/.ssh/id_rsa 


   or


   ssh-add ~/.ssh/id_dsa



   depending on which key file you have created.




3. When prompted, enter the key file’s passphrase. When you do, you
   should be prompted that the identity has been added. An example
   follows:

      rtracy@ws1:~> ssh-agent bash
      rtracy@ws1:~> ssh-add ~/.ssh/id_rsa
      Enter passphrase for /home/rtracy/.ssh/id_rsa:
      Identity added: /home/rtracy/.ssh/id_rsa (/home/rtracy/.ssh/id_rsa)
      rtracy@ws1:~>



    Once this is done, the ssh-agent process stores the passphrase in
    memory. It then listens for SSH requests and automatically provides
    the key passphrase for you when requested.














LX0-104 Exam Objectives (X)