ssh key setup exercise

Make a note of the IP address or domain name for the ssh "server" given by the instructor.
The instructor will start the ssh server daemon on the server machine (requires root).

Establishing an encrypted login session to an ssh server using key-based authentication

ON THE CLIENT, IN CLASS

Login as user "student" (create if non-existent). Create a key pair, of dsa type

cd
ssh-keygen -t dsa (respond to all the prompts by pressing enter)

Note the resultant new directory (.ssh within your home directory) and the 2 files in it (id_dsa, id_dsa.pub).

ls -ld .ssh      (shows the directory
ls -l .ssh         (shows its contents

id_dsa.pub is your public key. Move a copy of it to the server. Per your instructor, use either ftp or sftp (this will depend on what the particular client, server, and their firewalls support). Login as the user indicated by your instructor (e.g., student1) with the password indicated (e.g., password). If your instructor tells you to use ftp:

cd .ssh
ftp <server address>
[supply name and password when prompted]
ftp> passive
ftp> put id_dsa.pub
ftp> quit

or else, if you're to use sftp:

cd .ssh
sftp <server address>
[supply name and password when prompted]
s ftp> put id_dsa.pub
s ftp> quit

Now that you have a matched pair of keys, and a copy of the public one on the server, you'll  next go to the server and place the public key into the strategic file used by ssh to enable key-based authentication for logging in. That file is /home/<user>/.ssh/authorized_keys2, where <user> is the user as whom you will want to log in.


ON THE SERVER, REMOTE FROM CLASS

Log in remotely to the server. Per your instructor, use either telnet or ssh to do so. Login as the user indicated by your instructor (e.g., student1) with the password indicated (e.g., password).

Below, in your home directory you create a subdirectory named .ssh. (Note it will be "hidden" because its name starts with a period; so if you want to see it using ls, be sure to use ls's -a option.) Then restrict access to it by explicitly setting its permissions to exclude everybody but you (an ssh requirement).

cd
mkdir .ssh
chmod 700 .ssh

In that directory create a file named authorized_keys2, make its permissions suitably restrictive, then get the public key you imported from your client in class into this file:

cd .ssh
touch authorized_keys2 (or, echo -n "" > authorized_keys2)
chmod 600 authorized_keys2
cat ../id_dsa.pub >> authorized_keys2

Leave the server by quitting from telnet.

exit


BACK ON THE CLIENT AGAIN, IN CLASS

Logged in as the same user as before, gain a remote prompt from the server as the indicated user (e.g., student1):

ssh student1@<server address>

answer "yes" to any question about host authenticity that may appear. You should get the prompt and be able to operate on the remote machine as student1 much as if you had used telnet. Exit the remote server by quitting from ssh:

exit

Note that what you have done here:

 What you set up:  transparent (passwordless) remote command access via ssh
 How you did it:  by remote command access via either telnet or non-transparent ssh

If you used telnet for the exercise, note that logically, it's pointless to bother getting remote access when you already have it. Practically in the real world, you would not already have it. Neither telnet nor ssh would yet be available to you. Telnet in parallel with ssh makes no sense because it defeats ssh's purpose of confining remote access to secure connections. In the absence of telnet access to the server, that is in the real world, key placement would have to be done by cooperation of ssh server's local owner or administrator.