CIT 470 Advanced Network and System Administration: Lab #6: ssh keys and agents

Lab #6: ssh keys and agents
Date: February 11, 2008
Due Date: February 11, 2008
Points: 10

In this lab, we'll learn how to access a system remotely using ssh with key-based authentication. Cryptographic keys provide a greater amount of security and offer more possibilities for secure automation than passwords do. We'll use an ssh agent to automate the use of key-based authentication.

You will need two machines for this lab. You will use your physical CentOS host for one and your virtual CentOS machine for the other. If VMWare Server will not start from the Gnome menu, the most common problem is that you have changed something about the system configuration. To solve this problem, run /usr/bin/vmware-config.pl again and answer the questions as you did the first time, remembering that your virtual machine is stored in /var/vm.

Configure the Firewall to permit ssh
1. On the VM, add a new iptables firewall rule to /etc/sysconfig/iptables to permit ssh. See the iptables section of the RHEL 5 Deployment Guide for documentation on the syntax of this file. We need to add the following rule to the file just before the rule that accepts packets in the ESTABLISHED or RELATED states. You'll need to use the appropriate number in place of SSH_PORT below. If you're not sure what port is used by ssh, check the file /etc/services.
```
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport SSH_PORT -j ACCEPT
```
2. Restart iptables.
```
service iptables restart
```
3. Verify that your new rule is being used. Note that the iptables command translates the well known port number to the symbolic name for that port, ssh.
```
iptables -L | grep ssh
```
4. If you haven't created a student account on your CentOS VM yet, create one using the useradd command before going to the next step.
5. Verify that you can connect to your CentOS VM server from your CentOS PC with ssh using the -v for verbose output so you can see how the connection process works and identify any problems.
```
ssh -v student@CENTOS_VM_IP_ADDRESS
```
6. Once you're logged in, run some commands to verify that you are logged into the VM as student.
```
id
who
ifconfig
```
Checking the Host Key
1. When you attempted to connect to your CentOS server, you received a message that the authenticity of the server cannot be established along with a key fingerprint. The fingerprint was of the server's host key, which protects ssh connections from man-in-the-middle(MITM) attacks in a similar manner to how SSL server certificates protect https web connections from MITM attacks. As the name implies, host keys are associated with the host, not the user, and thus are completely separate from the authentication keys we'll use later in the lab. Host keys should always remain the same, unless the OS has been re-installed or the machine has been given a new DNS name or IP address. If you see a new host key for a familiar host, it may indicate that you are subject to a MITM attack. Let's find the key files on the CentOS VM server.
```
cd /etc/ssh
ls *.pub
```
2. Let's verify the key now in your ssh session. We'll use ssh-keygen to list (-l) the key fingerprint. There are two different key algorithms that are commonly used, RSA and DSA, and ssh printed the one it used just before it printed the key fingerprint when you connected to the CentOS server. Replace XXX with the algorithm name in lower case below. This fingerprint must exactly match the one that ssh printed on your initial connection to the CentOS server.
```
ssh-keygen -l -f ssh_host_XXX_key.pub
```
SSH Key Generation
1. Unlike password authentication, key-based authentication requires some initial setup before we can use it. You need to generate a pair of keys, one private and one public. The public key is used for encryption, and the private key for decryption. Our private key can be used to login to any system that uses our public key for key-based authentication, so we will protect it by encrypted it when we generate our keys. Create an RSA key pair on your CentOS PC. Use your root password for key encryption. While in practice, you should use a different password, we do this to ensure that all of the passwords are known to the instructor.
```
ssh-keygen -t rsa
```
2. Verify that the key files exist in your home directory on the client in the location that ssh-keygen printed out. Which file contains your public key and which contains your private key? How do the files differ from each other?
```
cd ~/.ssh
ls -l
cat *
```
3. Since the public key is only used for encryption, it can seen by anyone without compromising our security. To setup ssh key-based authentication, we need to copy the public key to our ~/.ssh/authorized_keys file on the server. We'll need to supply our regular password when using scp (secure copy, a version of cp that allows you to copy files between machines securely using ssh) since we're still in the process of setting up key authentication. If scp does not request a password, you have made a mistake when typing your command line. We'll start by copying the public key file from the client to the server. Note that the destination file path looks like a login that would use for ssh with a colon at the end of it. You can specify which path to copy the file to by adding that path after the colon. If you do not specify a path, the file is copied to the user's home directory.
```
scp ~/.ssh/id_rsa.pub student@CENTOS_VM_IP_ADDRESS:
```
4. Add the public key to your ~/.ssh/authorized_keys file on the CentOS VM server. If student's home directory does not have a subdirectory named .ssh, that means that student has not yet run ssh on the VM. The ssh program will create this subdirectory the first time you run it, so run ssh username@kosh.nku.edu to create it.
```
cat id_rsa.pub >>~/.ssh/authorized_keys
```
5. Key authentication should now work. Try connecting to your CentOS server via ssh in verbose mode. Notice that ssh now asks for your private key file passphrase before proceeding. If the verbose output reveals that ssh tried key authentication and failed, then there is likely a permission problem with your authorized_keys file. Fix the permissions, then try again. If you enter the right key, the verbose output should tell you "Authentication succeeded (publickey)" and you should be logged into the CentOS server.
```
ssh -v student@CENTOS_VM_IP_ADDRESS
```
SSH Agents
1. While key authentication offers some security improvements over passwords (keys aren't transferred to the server, and keys are much longer and harder to guess than passwords so automated guessing attacks aren't effective), it seems that we haven't made any improvements in terms of ease of use as we're still entering a password, just a different one. Let's use ssh-agent to solve this problem for us. On Windows, putty has an agent command called Pageant, which is installed if you download the Windows installer version of putty instead of the simple executable.
```
ssh-agent
# ps will show two agent processes, as Gnome starts one for you when you login
ps auxw|grep ssh-agent
```
2. When we ran ssh-agent it printed several shell commands then moved into the background. Unfortunately, we needed it to run those shell commands to be useful, so let's kill the agent you created and try again.
```
kill SSH_AGENT_PID
```
3. Now let's run ssh-agent the correct way by executing the command in backticks to capture the output and using the shell's eval command to execute those shell commands instead of printing them.
```
eval `ssh-agent`
```
4. We need to add our private key to the agent's cache. The agent can cache multiple keys, but we only have one at the moment. You'll have to enter a password since it's encrypted.
```
ssh-add ~/.ssh/id_rsa
```
5. Now we can ssh to our CentOS server without a password.
```
ssh student@CENTOS_VM_IP_ADDRESS
ls
exit
```
6. You can also scp without a password.
```
scp /etc/hosts student@CENTOS_VM_IP_ADDRESS:
```
7. Of course, you can sftp without a password too. This will work until you exit the shell from which you spawned the ssh-agent.
```
sftp student@CENTOS_VM_IP_ADDRESS
ls
```