Client Use

There are a few preliminaries to get out of the way. First stop is key generation.

Generating SSH Client Keys

Before we can really use the power of SSH, we need to generate keys for the user account. We do this by using the ssh-keygen command:

[joe@acme.com]: ssh-keygen -t ed25519
  Generating public/private key pair.
  Enter file in which to save the key (/home/joe/.ssh/id_ed25519):
  Enter passphrase (empty for no passphrase): **********
  Enter same passphrase again: **********
  Your identification has been saved in /home/joe/.ssh/id_ed25519.
  Your public key has been saved in /home/joe/.ssh/id_ed25519.pub.
  The key fingerprint is:
  da:07:3f:49:a3:b6:65:da:06:c7:53:9f:b6:28:06:0f joe@acme.com

You should now see the public and private ed25519 keys ~/.ssh/id_ed25519.pub and ~/.ssh/id_ed25519:

[joe@acme.com]: ls -l .ssh/
 total 8
 -rw-------    1 joe  users   736 Apr 28 23:30 id_ed25519
 -rw-r--r--    1 joe  users   609 Apr 28 23:30 id_ed25519.pub

The file ~/.ssh/id_ed25519.pub contains the DSA public key for authentication. The contents of this file should be added to ~/.ssh/authorized_keys on all machines where the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret.

Once distributed, ssh will perform a random number challenge based on the public key, which the originating client must decrypt using the private key. This all happens transparently to you, but the result is that no passwords or passphrases are directly sent over the network, even in encrypted form.

Let us test this by copying ~/.ssh/id_ed25519.pub to your remote server and putting the contents into the ~/.ssh/authorized_keys files:

[joe@acme.com]: scp ~/.ssh/id_ed25519.pub server.acme.com:.ssh/authorized_keys
 Are you sure you want to continue connecting (yes/no)? yes
 Permanently added 'server.acme.com,192.168.0.109' (DSA) to known hosts
 joe@server.acme.com's password:
 id_ed25519.pub           100% |******************|   609       00:00

Now we can test this out by trying to ssh into the server. We expect now to be asked for the passphrase and NOT the password (note we change the prompt to emphasize the user and host):

[joe@acme.com]: ssh server.acme.com
 Enter passphrase for key '/home/joe/.ssh/id_ed25519': ********

[joe@server.acme.com]: hostname
 server.acme.com

It works! So far so good. Lets do some exercises and then talk about typcial ssh applications.

Exercise:

Why is passphrase authentication better than password authentication?
(hard) Use ethereal to try to see what is being sent in the ssh challenge. Report your findings below.

Now that the heavy lifting is out of the way, we can finally use SSH to do some encrypted communications. We will go through the most common uses in their order of complexity.

Exercises

The simplest of test is to connect to a remote host:

[joe@acme.com]: ssh server.acme.com
Enter passphrase for key '/home/joe/.ssh/id_ed25519': ********

Next we connect to remote as another user using user@server.acme.com. Ask your neighbor to set up an account for joe with password “joejoe”. Note that since you dont have your public key there yet, you have to use a password.:
```
[joe@acme.com]: ssh joe@server.acme.com
joe@server.acme.com's password: ********
```
Install your public key on joe@server.acme.com as above and try again using passphrases.