Managing services using SysVinit
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 (or
use sudo before each command). Ensure your system date and time are
correct, and that your system is up to date by issuing the following
command:
sudo yum -y 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.
sudo systemctl start sshd
Enable sshd to start at boot
sudo systemctl enable sshd
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.
Testing Connectivity
In
order to allow easier access to each of your VM's, we will configure
them to use a static IP address using the sample configuration provided
below. centos1 should use the first available address in the subnet (the
second assignable IP, as network manager uses the first assignable for
the host), centos2 the second and centos3 the third.
This should
be done using the command line on all 3 virtual machines (steps
outlined below). Make note of the files used and entries required.
To
view the available interface (should be eth0 but may sometimes be eth1)
and it's configured ip address. Make note of the device name and
hardware or mac address when you issue the following command:
ip address show
The
file we need to edit to assign a static IP address is located in the
directory /etc/sysconfig/network-scripts, and is named (note: you must
create this file initially) ifcfg-eth# where # is the number
corresponding to the interface you wish to assign a static ip address
(obtained using the previous command). Sample syntax follows:
DEVICE="eth0"
IPADDR="192.168.0.2"
NETMASK="255.255.255.0"
GATEWAY="192.168.0.1"
HWADDR=mac address for the device
ONBOOT="YES"
NM_CONTROLLED="YES"
Bring the interface down and back up to apply the changes (using ip link or ifdown/ifup). Try to ping
www.google.com, note there is no DNS resolution.
Issue the command cat /etc/resolv.conf, and observe the contents. This is the dns resolution library
source. Edit your interface config file and add the following parameter at the bottom where x is your network number:
DNS1="192.168.x.1"
**
Note: 8.8.8.8 and 8.8.4.4 are two free public DNS servers provided by
Google. They are great addresses to remember when testing DNS.
Bring
the interface down and back up again to apply the changes. Look at
/etc/resolv.conf (using cat) again and notice the difference.
Remember these files, as we will be adding these additional options in lab 3.
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.
Try to ping matrix and google from your host machine. Record the ip address of each.
Try
to ping matrix and google 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).
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 (though you
may wish to set a passphrase for your key – remember what it is if you
do!).
Your output should look something similar to this:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/jmcarman/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/jmcarman/.ssh/id_rsa.
Your public key has been saved in /home/jmcarman/.ssh/id_rsa.pub.
The key fingerprint is:
f5:07:8c:aa:b6:08:e0:45:81:ca:d6:88:8c:aa:1a:7b jmcarman@c6host.jmcarman.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.
Issue the command ssh-copy-id username@ipaddress, and have your partner enter their credentials and password.
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 (with the -s option). 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.
Applying What We've Learned
Repeat these steps (for your own user) on your host and virtual machines, until you can ssh into each without a password
Your
first attempt to ssh, a prompt will appear asking you to enter the
passphrase (the one you entered when you created the key). Check the box
that says "Automatically unlock this private key when I login"
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. 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.
Completing the Lab
to go back in directory you can type cd ..
