OPS335 Lab 1

Configuring a Linux Gateway

This lab will introduce you to some skills you will be using for the rest of the course (and your career). You will edit files to change how your system works, and to configure a service. You will also use systemd to manage when a service runs. This will occur in the simple intranet you set up in the previous lab. Here is a diagram of your setup.

Requirement - Lab 0
Lab 0 must be completed before you can begin this lab.

Instructions

Managing services using systemd

Before you start, if you are more familiar with the chkconfig or service commands, you may wish to review the SysVinit to Systemd Cheatsheet. Boot up your Centos host system, login with your learn id and use Firefox to authenticate yourself on SENEnet so you can download and install new software.

• Open a terminal window and su to root.
• Ensure your system date and time are correct.
• Ensure your system is up to date

yum update

• Now boot up your VMs, log in, and update them too.

• You will want to be able to communicate with your machines using ssh.
  • Check the ip address of the virtual machine by running the following command on each one.

 ip address show

• Start the ssh service on the virtual machine. Also set the service to start automatically when the machine boots.

service sshd start
Redirecting to /bin/systemctl start sshd.service

• Notice that your command was redirected to 'systemctl', the command executed was 'systemctl start sshd.service'. Record this in your lab book.
• Enable sshd to start at boot

chkconfig sshd on
Note: Forwarding request to 'systemctl enable sshd.service'.
ln -s '/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'

• Again notice your command was redirected to 'systemctl', the command executed was 'systemctl enable sshd.service'. A symbolic link was created as well, explain its purpose in your lab book.
  • Use ssh to connect from your host to the virtual machine.
    • You will be prompted to store the virtual machine's identification. Choose yes. This allows your machine to store a 'fingerprint' of the machine you are connecting to. From now on, when you connect to that machine, it will compare the fingerprint you have stored to the one available on that machine. If you connect to a machine and that fingerprint has changed, it is often an indication that something has gone wrong.
  • Reboot the virtual machine and check the status of your ssh service.
• You may occasionally encounter services that have not yet been moved to Systemd. In those cases Systemd will redirect the command to the appropriate older method. e.g.

systemctl enable example.service
example.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig example on
Warning: unit files do not carry install information. No operation executed.

Testing Connectivity

• Edit each of your VM's to use a static IP address. VM01 should use the first available address in the subnet, VM02 the second and VM03 the third.
  • This should be done using the command line on all 3 virtual machines. Make note of the files used and entries required.
• Restart each VM and run the following command to ensure they have the IP address you set. Do not continue until they keep the address you set.

ip address show

• Test connectivity by pinging each of your VM's.
• Try to ssh from the guest to the host machine, then from the host to the guest.
  • Both should fail with the error message 'No route to host'.
• As root, run the following command on each machine (which will modify the firewall so it accepts incoming ssh connections):

iptables -I INPUT -p tcp --dport 22 -j ACCEPT

• Try to ssh from the host to the guest machine again. It should work now.
• We won't save your firewall rules for now, as we'll be making a permament set of rules next lab.

• Try to ping matrix and google from your host machine. Record the ip address of each.
• Try to ping matrix and google (using their ip addresses) from each of your VM's to ensure you can reach the outside world (you will need to be authenticated to the network on your host machine).
  • If your VMs can not ping external machines, use the following command to examine their routing information.

ip route show

• If you did not give the VMs a default route when you gave them a static IP address, they don't know where to send packets in order to get outside the network.
• Add your host's IP address (192.168.x.1) as the default route.
• Again try to ping matrix by its ip address.
  • It should now work.
• Try to ping matrix by name, and it should fail.
  • Your virtual machines do not know how to turn the hostname matrix.senecac.on.ca into the ip address.
  • While they had dhcp addresses your host was telling them where a DNS server was, but now that they have static addresses you need to configure that for them.
  • Edit /etc/resolv.conf, delete what's there and enter this data instead.

 nameserver 142.204.1.2
 nameserver 142.204.43.43

• Note that this will go away when you reboot. We will cover how to set this permanently in a later lab.
• Once you can ping matrix, try to ssh to your Matrix account from the VMs.
  • It should work now.
• Perform these steps on each of your machines so you can ssh between each VM and the host (and between the VMs).
• Try to ssh from your Matrix account back to your host.

User management

• Find a partner for this step and create a user on your host machine that matches the user on their host.
• Create a password for that user, but do not share it with your partner.
• Have your partner run the following command on their host machine:

 ssh-keygen -t rsa

• when you enter this command just hit ENTER for all the questions. Here's what I got when I ran it on my host

 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/peter/.ssh/id_rsa):
 Enter passphrase (empty for no passphrase):
 Enter same passphrase again:
 Your identification has been saved in /home/peter/.ssh/id_rsa.
 Your public key has been saved in /home/peter/.ssh/id_rsa.pub.
 The key fingerprint is:
 f5:07:8c:aa:b6:08:e0:45:81:ca:d6:88:8c:aa:1a:7b peter@host.pcallagh.org
 The key's randomart image is:
 +--[ RSA 2048]----+
 |       o+++      |
 |    E .ooo..     |
 |     ...o.       |
 |       ...o     .|
 |       .S+ +   o.|
 |        . = . o .|
 |           o +   |
 |          o +    |
 |           . .   |
 +-----------------+

• When you run that command you generate both halves of a paired-key encryption scheme. In order to be able to log in to another machine without a password, each machine needs one half. You keep the private key (in this case id_rsa), and you give the public key (id_rsa.pub) to the machine you want to log in to.
• Have your partner email you their public key.
  • Copy it into /home/<partner's user>/.ssh/authorized_keys on your host machine.
• Have your partner attempt to ssh from their host to yours.
  • If they are prompted for a password, you have done something wrong. Make sure the path is correct, and that no one other than that user has write permission to their .ssh directory or the authorized_keys file (If anyone does, even that user's group, the ssh service will not consult that file).
• Once they have successfully logged in without a password, use the usermod command to change their default shell to /sbin/nologin.
  • They should no longer be able to log in.
• You can use this command to edit many other things about your users, including their home directory, the group they belong to, their user id, etc.

Configuring a Service

• A common, if somewhat blatant, way to try to hack into a machine is to try to ssh as root and brute-force the password.
  • The root user always exists, meaning the attacker doesn't need to try guessing what user names are on your system.
  • And if they can get access to root, they can do anything.
• To prevent this, we'll edit the configuration file for the ssh service to prevent root from ssh'ing into your host machine.
• Use cat to display /etc/ssh/sshd_config on your host.
• This file contains the configuration parameters for the ssh service.
• Lines that begin with # are comments. Either simple explanations of parameters, or parameters that have not been set.
• Open the man page for sshd_config
  • This lists all the possible parameters in alphabetical order along with a brief explanation of what each one does.
  • The parameter we are looking for is PermitRootLogin, read its description.
• Use an editor (e.g. vi) to open /etc/ssh/sshd_config, and find the line that has PermitRootLogin.
  • By default it is set to yes, allowing the root user to ssh in to the machine.
  • Uncomment it, and change it to no.
• Now try to use ssh from one of your VMs to log into your host as root.
  • You'll still be able to. This is because (for most services) the changes you make to the configuration file do not take effect until the service restarts.
  • Restart the sshd service on your host and try to ssh in again. Now it should prevent you.
• The configuration files for most services follow a very similar format. Some use an = between the parameter and its value, some require you to group certain parameters together, and most use # to be a comment. You will get lots of experience working with the configuration files for services in this course.

Minimizing your VM's footprint

• Since all VMs used in this course are intended to be servers, the presence of a GUI in not recommended - servers are typically managed from the command line.
• Make it boot by default to the command line only
  • Fedora 17 and onward do not use '/etc/inittab' to set the default run level but rather use targets as a more flexible replacement. Note the output of the following command:

ll /etc/systemd/system/*.target
lrwxrwxrwx. 1 root root 36 Dec  3 09:35 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target

and

ll /lib/systemd/system/*.target

Systemd uses symbolic links to point to the default runlevel in use. To change the default runlevel you must first remove the existing symlink.

rm /etc/systemd/system/default.target

To change your system to boot in multi-user mode by default:

ln -s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Make note of the command that would be needed to change the default 'runlevel' (or 'target' as it is now referred to when using systemd) to graphical or runlevel 5. Test your VM to make sure that it boots correctly before moving on to the next step.

Completing the Lab

In completing this lab you have started gaining experience with some of the skills you need to be successful in this course, and as a future system administrator. You have started to manage what a service does and how it works. You have worked with a configuration file, and tested to make sure that the changes you wanted took effect.

Answer the following questions in your logbook.

1. How can you tell if a service is native or non-native to 'systemd'?
2. Explain the iptables rules displayed when you ran the command 'iptables -t nat -L'. How did they differ after creating your personal network.
3. Explain the output displayed when you enabled sshd to start at boot by running the command 'chkconfig sshd on'.
4. What file was edited to change the host name on your VM's?
5. What iptables rule was added to allow ssh connections to the guest vm's?
6. How are ping and ssh affected (on both machines) when you run the following command on the host machine?
   • echo 0 > /proc/sys/net/ipv4/ip_forward
7. Change the default target on vm02 and vm03 to multiuser.
   • What command(s) was used?
   • What option can be added to reduce this to a single command?

Time for a new backup!
Once have successfully completed this lab, make a new backup of your virtual machines.