Assignment 9. SSH setup and use in applications

Laboratory

Use OpenSSH to establish convenient logins, so you should use ssh-agent on your host to manage authentication. That is, you should be able to log out of a host (dropping all your connections to it), then log back in, type your passphrase once to ssh-agent, and then be able to use ssh to connect to any of your other hosts, without typing any passwords or passphrases.

You should also use port forwarding so that you can run a command on a remote host that displays on your host. For example, you should be able to log into a remote host, type the command xeyes, and get a graphical window on your display. You will need to use ssh -X and/or ssh -Y when you use port forwarding.

Finally, you should be able to do a multihop or “daisy-chain” connection conveniently. For example, you should be able to ssh into lnxsrv07, and then from lnxsrv07 to lnxsrv09, and so on. You want these daisy chains to be convenient as possible. On SEASnet this is merely an exercise, since you can connect to any one of the lnxsrv* hosts as well as any of the others; but in the real world these sorts of connections are useful when for security reasons one cannot connect to an inner server directly. Investigate Transparent Multi-hop SSH and see which technique works best for you.

Keep a log of every step you personally took during the laboratory to configure your or your team members' hosts, and what the results of the step were. The idea behind recording your steps is that you should be able to reproduce your work later, if need be.

Homework

On the SEASnet GNU/Linux servers, use GNU Privacy Guard's shell commands to create a key pair. Use GPG version 2. Export the public key, in ASCII format, into a file hw-pubkey.asc. Use this key to create a detached signature for your submission so that the commands described below can successfully verify it.

If you are creating a key pair on the SEASnet GNU/Linux servers, you may exhaust its entropy pool as described in Launchpad bug 706011. The symptom will be a diagnostic saying "It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy." Since you can't use the keyboard or mouse on the SEASnet servers, you'll have to use the disks, for example, by using the find command to copy every readable file to /dev/null; this is something that you can do in another session that is logged into the same machine. Please remember to interrupt the find once the key pair is generated, so that you don't tie up the server unnecessarily.

Briefly answer the following questions.

1. Suppose the other teams really had been observing all the bytes going across the network in your lab exercise. Is your resulting network still secure? If so, explain why, and explain whether your answer would change if (1) you assumed the other teams had also tapped your keyboards after you completed all client-server setup and had thereby obtained your team's keystrokes during later operation, or (2) you are booting off USB and you assume the other teams temporarily had physical control of the USB. If not, explain any weaknesses of your team's setups, focusing on possible attacks by such outside observers.
2. Explain why the gpg2 --verify command in the following instructions doesn't really verify that you personally created the file in question. How would you go about fixing this problem?

Submit

Submit five files, as follows:

1. The file hw-pubkey.asc as described above.
2. A copy of your lab log, as a file log.txt.
3. The answers to the homework, as a file hw.txt. This and log.txt should both be ASCII text files, with with no more than 200 columns per line.

The following shell commands should work:

mkdir -m go-rwx .gnupg
gpg2 --homedir .gnupg --import hw-pubkey.asc
awk '200 < length' log.txt hw.txt

The gpg2 --verify command should say "Good signature". The last awk command should output nothing.