From: Kartik Krishnan (kartik@caam.rice.edu)

To: all_se4c03@cas.mcmaster.ca

CC: kartik@optlab.cas.mcmaster.ca, shalabhm@mcmaster.ca, dongz@mcmaster.ca

Subject: How to Lab 4 correctly

Hello all,

There was a lot of confusion on how to do part A of Lab 4 in ITB 238 yesterday.

To set things right, here is how we will proceed with Lab 4. Please follow the instructions carefully.

ssh with public-key authentication has the advantage that you do not need to type your password; instead you will use your passphrase that you used when generating your public/private keys.

Now suppose Kartik on host 15 wants to ssh into host 30 (we will assume he has an account kartik on both machines) here is how he will proceed with the public-key authentication.

On host 15 Kartik's generates his private/public key pair using ssh-keygen -t dsa (or ssh-keygen -d as mentioned in the Lab; dsa or the -d option stands for the digital signature algorithm). The directory in which the files id_dsa (private key) and id_dsa.pub (public key) are created should be Kartik's .ssh directory. Kartik is prompted for a passphrase, and he types something that is different from his password on host 30. Once this key generation is done you should ensure that the private key id_dsa is in the .ssh directory in your home account (for Kartik this is on host 15).

Kartik then sshes into host 30 (the normal way with his password) and copies the contents of id_dsa.pub (his private key generated on host 15) into the authorized_keys2 file in the .ssh directory in his home account on host 30 (note that this is part of the setup!). Once this is done, Kartik logs out of host 30 and then tries to ssh into this machine now using public-key authentication. This time Kartik is prompted for his passphrase (not password) and gets into host 30 without using his password.

So if you want to ssh from a local machine (client) into a remote machine (server), you will generate your public/private keys on the client machine, put your private key in the .ssh directory of the client machine; ssh into the server (the regular way using your password) put the public key you generated on the client into the authorized_keys2 file in the .ssh directory of the server. Once this is set up you can always log into the server using public-key authentication, i.e. using your passphrase instead of your password. Hope this is clear!.

To summarize, this is what happens when everything is set up. When Kartik sshes into host 30 from host 15, host 30 generates a random session key encrypts it using the public key which is in the authorized_keys2 file in the .ssh directory, i.e., it challenges Kartik to decrypt this; Kartik then calmly types his passphrase when prompted; host 15 decrypts Kartik's private key in its .ssh directory (using the passphrase), and uses the private key to decrypt the challenge and sends this challenge back to host 30; if this is correct host 30 grants Kartik access.

Finally, you want to give only yourselves read and write permissions to the authorized_keys2 file on the remote machine (server); this will ensure that nobody changes your public key.

Hope this is clear!. Comments and suggestions welcome!.

Thanks,

Kartik