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)       *see footnote below to make sure this works; best to substitute rsa here, and below, for dsa

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., student01; you use your assigned user account instead please) with the password indicated (e.g., password#University). 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 <user>@<server address>
[supply name and password when prompted]
sftp> put id_dsa.pub
sftp> quit

or else, if scp (sftp is interactive, scp is not):

cd .ssh
scp  id_dsa.pub  <user>@<server address>:/home/<user>

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., student01) 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 containing a copy of the the public key you imported from your client in class. Make its permissions suitably restrictive (an ssh requirement):

cd .ssh
cat ../id_dsa.pub >> authorized_keys2
chmod 600 authorized_keys2

Leave the server by quitting from telnet/ssh.

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., student01):

ssh student01@<server address>

answer "yes" to any question about host authenticity that may appear. You should not get any password prompt. Nevertheless, you should get the command prompt and be able to operate on the remote machine as student01 much as if you had used telnet or ssh login. (ssh can be used for a variety of non-login purposes. This key-based authentication is convenient for such uses within scripts that will run unattended, where no human would be available to supply a password on behalf of the script.) 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 or ssh login via password for the exercise (you did!) 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 pre-existing access to the server, that is in the real world, key placement would have to be done by the ssh server's administrator, with his active and deliberate cooperation.

--------------------

* OpenSSH from version 7.0 made the decision to deprecate the dsa type of public/private keys, and disable their use by default. (I found a lot of debate concerning the decision's wisdom online.) From a practical perspective, the result is that this exercise as written stopped working. The newer ssh client would not accept/utilize the dsa -type public key (though a server, if originally accepting of such keys remained so). This exercise can be made to work either by reconfiguring the ssh client to reenable dsa keys, or using another key type such as rsa.

To do the former, add the following line to the /etc/ssh/ssh_config file, which configures the ssh client:

PubkeyAcceptedKeyTypes +ssh-dss

This PubkeyAcceptedKeyTypes is new, and appears in later but not earlier man pages for the ssh_config file, as follows:

PubkeyAcceptedKeyTypes
 Specifies the key types that will be used for public key authentication as a comma-separated
 pattern list. Alternately if the specified value begins with a '+' character, then the key
 types after it will be appended to the default instead of replacing it. The default for this
 option is:

  ecdsa-sha2-nistp256-cert-v01@openssh.com,
  ecdsa-sha2-nistp384-cert-v01@openssh.com,
  ecdsa-sha2-nistp521-cert-v01@openssh.com,
  ssh-ed25519-cert-v01@openssh.com,
  ssh-rsa-cert-v01@openssh.com,
  ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
  ssh-ed25519,ssh-rsa

 The -Q option of ssh(1) may be used to list supported key types.


To do the latter, use

 ssh-keygen -t rsa

instead of

 ssh-keygen -t dsa

(It will produce files ~/.ssh/id_rsa and id_rsa.pub instead of their "dsa" counterparts. Adapt the file nomenclature above accordingly.)