Lab 14

Task 1 Introduction to ssh and scp

Estimated Time: 5 minutes

Objectives y Establish a secure session to a remote host using ssh. y Copy les securely from one host to another using scp. Requirements b (1 station) Relevance The ssh and scp commands are the de-facto tools for authenticated and encrypted communication between hosts. Users and administrators alike should be very familiar with these commands. Notices y The SSH suite of utilities should be pre-installed on the system and the commands in the path. Type ssh and hit at the prompt. This should show a list of switches supported by the ssh command (a usage summary). If this is not the case ( an error is shown, instead), ask the Instructor for assistance.

1) Use ssh to establish an encrypted session to the system. Log in to the station as the user
visitor: $ ssh visitor@localhost The authenticity of host localhost can't be established. RSA key fingerprint is 80:1f:26:6f:ac:5e:6e:8b:dd:2d:82:58. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list ofa known hosts. visitor@localhost's password: work $
This response is because SSH is unable to verify that the system claiming to be localhost really is localhost and not another host. This should have logged into the localhost as the user visitor (over an encrypted session) and sitting at a prompt.

2) Use the SSH utility, scp, to securely transfer les. Transfer some les from the /etc/ directory to
the /tmp/ directory on the system:

Chapter 14 - Page 10

$ scp /etc/e* guru@stationX:/tmp/ guru@stationX's password: work . . . output omitted . . .

Be sure to replace stationX with the IP address or name of the system.

3) As the visitor user log out of ssh:

$ exit Connection to localhost closed.

Chapter 14 - Page 11

Lab 14

Task 2 SSH Key-based User

Authentication
Objectives y Generate and use RSA and DSA user keys. Requirements b (1 station) Relevance Public key authentication of users is one of the major features that SSH provides. Administrators and power users with many systems to connect to take advantage of this feature for efciency and ease of authentication. This lab task covers generation and deployment of an SSH public user key.
Estimated Time: 10 minutes

1) Before key based user authentication can take place, it is necessary to generate a key pair using
the ssh-keygen program. Run this command on the local workstation as the guru user:

$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (~guru/.ssh/id_dsa): Enter passphrase (empty for no passphrase): secret Enter same passphrase again: secret Your identification has been saved in ~guru/.ssh/id_dsa. Your public key has been saved in ~guru/.ssh/id_dsa.pub. The key fingerprint is: 17:42:19:d4:7a:a0:59:d5:3e:d3:63:d3:e3:5e:38:2f guru@stationX

The -t dsa option species the creation of a SSH version 2 DSA key pair. The default is a SSH version 1 RSA key pair.

2) Examine the key pair les generated by the previous command:

$ ls -l ~/.ssh/id_dsa* -rw------- 1 guru guru 736 Apr 6 18:54 ~guru/.ssh/id_dsa -rw-r--r-- 1 guru guru 602 Apr 6 18:54 ~guru/.ssh/id_dsa.pub
Note the secure (user only) permissions on the private key.

3) To enable RSA / DSA authentication, the public key must be copied to each remote system, for
each account that needs to be accessed via SSH. This step only needs to be performed once per remote account. SSH keys, either RSA or DSA, need to be stored in the ~/.ssh/authorized_keys le. Multiple public keys can be used by simply appending additional keys to the le:

$ cd ~/.ssh/ $ scp id_dsa.pub visitor@localhost:~/guru@stationX-id_dsa.pub visitor@localhost's password: work id_dsa.pub 100% 616 0.6KB/s
Chapter 14 - Page 12

00:00

4) SSH to the visitor account to setup the .ssh directory:

$ ssh visitor@localhost visitor@localhost's password: work

5) Make sure that the .ssh directory exists. If it does not, create it and ensure that it has the correct
permissions set:

$ ls -d .ssh ls: .ssh: No such file or directory $ mkdir .ssh $ chmod 700 .ssh/
If the ~/.ssh/ directory does not have the correct mode (permissions) set, the sshd daemon will not utilize its contents and key-based authentication will not be possible.

6) Move the copied public key le to the correct location:

$ mv guru@stationX-id_dsa.pub .ssh/
If it was know that the ~/.ssh/ directory already existed, the le could have been copied directly there, instead, using the earlier scp command. In that case, this mv command would be unnecessary.

7) Append the new public key to the authorized_keys le:

$ cd .ssh/ $ cat guru@stationX-id_dsa.pub >> authorized_keys
Note, if the le does not already exist, this command will create it; if it does already exist, this command will append the contents of the public-key le to the end of it, also preserving any keys already in place. For this reason, it is HIGHLY recommended that you always use this command to add keys to the

~/.ssh/authorized_keys
le.

Chapter 14 - Page 13

$ chmod 600 authorized_keys

It is only necessary to run this command when the authorized_keys le is rst created. If this le's mode is not set properly, newer versions of OpenSSH's sshd will not allow the use of the authorized_keys le.

8) Logout of the visitor account:

$ exit Connection to localhost closed.

9) Test RSA / DSA authentication by attempting a ssh or scp connection to the remote account. If
the previous steps were performed properly, the system will prompt for the passphrase used to encrypt the private key:

$ cd $ ssh visitor@localhost Enter passphrase for key '/home/guru/.ssh/id_dsa': secret Last login: Fri Mar 3 10:52:35 2006 from localhost $ exit

The RSA / DSA authentication worked, so return to the local workstation.

Chapter 14 - Page 14