RH253读书笔记(8)-Lab 8 Securing Data

Lab 8 Securing Data

Goal: Gain familiarity with encryption utilities

Sequence 1: Using SSH keys with no passphrase

Scenario: alice and bob are users on possibly different stations who would like to establish account equivalency. In other words, alice would like to be able to access bob's account without needing to issue a password, and vice versa. You will use ssh to provide this equivalency.

This sequence will refer to stationX, which contains the user alice, and stationY, which contains the user bob. When performing this lab, you will need to adjust the steps so the hostnames reflect your situation. If you are working with a partner, stationX and stationY would be the respective machine names of you and your partner. If you are using a single machine, both hostnames may be replaced with localhost.

Deliverable: Users bob and alice are using SSH secured communications

Instructions:

1. Create these user accounts if they do not already exist, and give them passwords. On stationX create the alice user account, and on stationY create the bob account. Give them passwords.

a. [root@stationX]# useradd alice

b. [root@stationX]# echo alice | passwd --stdin alice

c. [root@stationY]# useradd bob

d. [root@stationY]# echo bob | passwd --stdin bob

2. Have root on bob's machine ensure that the sshd daemon is running.

a. [root@stationY]# service sshd start
[root@stationY]# service sshd status

3. If alice knows bob's password, she can use ssh to access his account. Note that all transactions with bob's account are encrypted, including the password exchange. As alice, run the following commands, supplying bob's password when appropriate.

[alice@stationX]$ ssh bob@stationY ls /tmp
[alice@stationX]$ ssh bob@stationY
[bob@stationY]$ exit

[alice@stationX]$ scp bob@stationY:/etc/services .
[alice@stationX]$ scp -r bob@stationY:/etc/xinetd.d .

4. Assuming that alice and bob would like a more secure authentication scheme, have alice generate an ssh public/private key pair. Note that ssh-keygen should be invoked with the -t command-line switch, so that keys appropriate for the DSA algorithm are generated. Have alice examine her private key (id_dsa) and public key (id_dsa.pub).

Choose default options for key locations. Also, choose a null passphrase by pressing Enter when prompted.

a. [alice@stationX]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/alice/.ssh/id_dsa):Enter
Created directory '/home/alice/.ssh'.
Enter passphrase (empty for no passphrase): Enter
Enter same passphrase again: Enter
Your identification has been saved in /home/alice/.ssh/id_dsa.
Your public key has been saved in /home/alice/.ssh/id_dsa.pub.
The key fingerprint is:
aa:11:33:45:11:cc:aa:66:99:00:ee alice@stationX.example.com

5. Take a look at the newly created files.

[alice@stationX]$ ls ~/.ssh
[alice@stationX]$ cat ~/.ssh/id_dsa
[alice@stationX]$ cat ~/.ssh/id_dsa.pub

6. Have alice mail bob a copy of her public key, if stationY accepts mail from stationX. If not, either setup the mail server on stationY, or use scp. Have bob save a copy of the public key as the file ~/.ssh/authorized_keys.

a. [alice@stationX]$ mail -s "my key" bob@stationY < ~/.ssh/id_dsa.pub

b. [bob@stationY]$ mail
Mail version 8.1 6/6/93. Type ? for help.
"/var/spool/mail/bob": 1 message 1 new
>N 1 alice@stationY.exa Sun Sep 24 23:00 71/3947 "my key"
& w alices_key
"alices_key" [New file]
& q

[bob@stationY]$ mkdir -p ~/.ssh; chmod 700 ~/.ssh
[bob@stationY]$ cat alices_key >> ~/.ssh/authorized_keys
[bob@stationY]$ chmod 600 ~/.ssh/authorized_keys

7. Assuming all pieces are in place (i.e., bob now has a copy of alice's public key in his list of authorized keys), alice should now be able to access bob's account without needing to supply a password.

[alice@stationX]$ ssh bob@stationY id
501(bob) gid=501(bob) groups=501(bob)
[alice@stationX]$ ssh bob@stationY tar czvf - /home/bob > /tmp/bob.stationY.tgz

If things are not properly configured, ssh will fall back to password authentication, and prompt alice for a password. There are several steps you can take to help debug the situation. First, examine /var/log/messages and /var/log/secure on the server for helpful information. Second, use the -v command-line switch with the ssh client. This will output useful debugging information. Multiple -v options will produce more debug information.

8. Perform the equivalent configuration for bob, so that he has access to alice's account.

Sequence 2: Using SSH keys with a passphrase

Scenario: If someone should find a way to get alice's private key, they would be indistinguishable from alice. A passphrase associated with alice's key would prevent this confusion, but then "she" (you) must enter a passphrase for the commands in the previous tasks. ssh-agent/ssh-add allows us to enter a passphrase only once per "session".

Note: the following assumes that you have logged in directly as alice, not using su.

Deliverable: Users alice and bob are using SSH keys with passphrases

Instructions:

1. Start by exiting your session and logging in directly as alice. Have alice generate a new key, this time with a passphrase. When asked if you want to overwrite id_dsa answer yes. Use a passphrase of your own choosing... of at least 6 characters.

a. [alice@stationX]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/alice/.ssh/id_dsa): Enter
/home/alice/.ssh/id_dsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): passphrase
Enter same passphrase again: passphrase
Your identification has been saved in /home/alice/.ssh/id_dsa.
Your public key has been saved in /home/alice/.ssh/id_dsa.pub.
The key fingerprint is:
44:45:cc:22:66:66:ee:aa:0f:62:66 alice@stationX.example.com

2. Send bob a copy of your newly generated public key. Refer to the previous Sequence if you need help.

3. As alice, repeat the commands from the previous Sequence. Notice that now you are prompted for the passphrase for /home/alice/.ssh/id_dsa.

4. Start the ssh-agent running by typing the command:

[alice@stationX]$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-BEKcxu4520/agent.4520; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4521; export SSH_AGENT_PID;
echo Agent pid 4521;

If this command fails try: eval 'ssh-agent' or ssh-agent bash.

Provide your ssh-agent with the key for /home/alice/.ssh/id_dsa. You will be required to enter your passphrase so ssh-agent can access the key.

[alice@stationX]$ ssh-add
Enter passphrase for /home/alice/.ssh/id_dsa: passphrase
Identity added: /home/alice/.ssh/id_dsa(/home/alice/.ssh/id_dsa)

5. As alice, repeat the commands again(!) from the previous Sequence. Notice that now ssh-agent is able to reply to the challenge provided by stationY. No passphrase is required.
Note: if alice is logged in at a Red Hat Enterprise Linux graphical user interface (GUI), then the previous Sequence will play out as described. However, if all she has is a text terminal session, then execute:

[alice@stationX]$ ssh-agent bash

This will "wrap" the bash shell with the ssh-agent utility.

What makes the Red Hat Enterprise Linux GUI so SSH friendly? The desktop sessions are similarly "wrapped" as the bash shell is in the previous command example. In fact, as described in the Unit notes, by selecting from the System->Preferences->More Preferences->Sessions->Start Up Programs , and selecting the Add button the following dialog is displayed. Enter the path to ssh-add as shown, then save and close the dialog. Logout alice and login again. After the initial "splash screen" is displayed, a dialog will display asking for alice's SSH passphrase. All SSH connections spawned from processes within this X11 session will be provided the passphrase... you can even skip the previous step.

Logout alice and login again. After the initial "splash screen" is displayed, a dialog will display asking for alice's SSH passphrase. All SSH connections spawned from processes within this X11 session will be provided the passphrase... you can even skip the previous step.

Sequence 3: Using an SSH tunnel

Scenario: alice has established public key authenticated shell access to bob's account. She would now like to securely access the (plaintext) web server that is running on bob's machine.

Deliverable: Web access through an encrypted tunnel

Instructions:

1. Ensure that a webserver is running on bob's machine (stationY). If not, as root on bob's machine, install and start the web server. Refer to the appendix if bob's machine needs to register with the RHN server.

a. [root@stationX]# yum -y install httpd

2. Have alice test the web server from stationX.

a. [alice@stationX]$ links http://stationY/

3. Using ssh, have alice connect to bob's account, and as a side effect, establish an encrypted tunnel between alice's port 12345 (or any other unused port) and bob's webserver (port 80).

[alice@stationX]$ ssh bob@stationY -L 12345:stationY:80

(and from another terminal...)

[alice@stationX]$ links http://localhost:12345

alice should see the same web page in both step 1 and step 2. In step 1, however, data traveled from the webserver to alice's links client in plaintext, and were subject to packet sniffing. In step 2, packets traveled from the web server, through bob's ssh daemon, across the network in ciphertext to alice's ssh client, and then deciphered and passed to alice's links client.

4. Challenge Question: Can you find the options that will put the ssh tunnel in the background and not execute a remote command?

Run the ssh command again, to determine the differences.

a. The options are -f and -N. The command should be:
[alice@stationX]$ ssh -Nf bob@stationY -L 12345:stationY:80