Managing services using SysVinit
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 deviceONBOOT="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.
- DNS2=
- DOMAIN=
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).
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"
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.
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
No comments:
Post a Comment