COMP1475, Lab #2

Your Linux VM

Lecturer Mariusz Pelc Phone 020 83318588

e-mail
Office QM366 m.pelc@gre.ac.uk
address
Office
Mon 4-6pm and by appointment
hours

Description:
No practical exercise in this week.

Learning Outcomes:
No practical exercise in this week.

Tasks:
This lab is designated to make you familiar with your Linux VM.

Lab 2 - Your Nix Server

1. Getting to know your server.

You must work in your allocated teams and you should continue in those teams for labs during
the remainder of this module. Please note the advice given to you throughout these exercises.
In particular, if you change the root password (which you always should) then you MUST
remember it or much of your development work may be lost to you and you will have to repeat it
on a new installation of the server. However, never work as root unless required so to do in
order to configure the server. All files should be created by lesser privileged admins.

The way you can access your VM through putty is the following:

i. Use putty to log in to your linux student server (student.cms.gre.ac.uk). Please mind that
the password you should use to log in to the student server might be your very first
university password you received in e-mail.
ii. From putty login to vme (ssh vme). Again, while the system prompts your for password,
use the same you used to log in to student server.
iii. From putty login to your group VM (ssh comp1475-centos7-_two_digit_group_no -l
root). E.g. ssh comp1475-centos7-01 -l root. Root password is ‘password’.
iv. Change root password for your VM (passwd).

v. REMEMBER the password 😊

2. Nix Users and Groups

i. Login and su to root,

ii. Review man/info pages for useradd, groupadd and passwd,

1
 iii. Where is the group file [find / -name group]? Read the file with less. What groups are
there on the server. Note: sometimes it is best to write the results of a search
using find to a text file, particularly if working as a lesser privileged user, when multiple
permission issues may make the results output onscreen difficult to interpret. In that
case you could try writing the result to a file in your home area, e.g [find / -name group >
~/results], which should yield only the positive results.
iv. Create a new group 'vhXXteam', where XX is the number of your server, [man
groupadd]
v. Create users <names of your team members> each to be members of the vhXXteam
group [hint: you will need the -m and -g flags],
vi. As root you may need to set the initial passwords separately for the users you have just
created [passwd <uid>],
vii. Each team member should change their passwords (keep these private) [passwd -
when logged on as the team member user],
viii. logoff as root and login as a lesser privileged admin, [exit su ]
ix. => try creating another user,
x. su to root,
xi. Find the passwd and shadow files [find / -name passwd],
xii. Read them with less (never vi in case you accidentally edit something),
xiii. What information is listed there about each of your vhXXteam group?
xiv. Where is each user's home area located? (to go there [cd ~])
xv. Logoff
xvi. Each team member can now logon separately. Do so and create a simple test textfile in
your own user area using vi(m).
xvii. Please mind that from today onward you will only be able to logon to your VM only as
your own username created on the VM.

3. Disabling the Direct Root Logon.

It is possible to configure ssh to reject any attempt to logon directly as root, so that you are only
able to logon as a lesser privileged user and you then have to su to root if required. The
advantage of this is that a cracker would have to guess two passwords to obtain root access to
your server rather than one, which is a useful additional deterrent.

---

Please mind that you SHOULD NOT disable direct root login in case there is no another
account you can use to log in to your system

---

i. First check that it is possible to logon to your server as root. Exit to vme and ssh to your
server as the root user (with its brand new, strong password). You should be able to do
that.
ii. /etc/ssh/sshd_config is the ssh server configuration file (hence the 'd' for 'daemon'). Read
it first with the [less] utility.
iii. Last week we discovered that only ssh using protocol 2 is now to be considered secure.
What protocol is the ssh server on your virtual Linux host using?
iv. Somewhere in the file are configured authentication options. One of these is
'PermitRootLogin', which defaults to 'yes'. That is why you were able to logon as root.
Using vi edit the file and change the PermitRootLogin value to 'no'. NB Be _very_
careful with this. If you disable or corrupt the ssh daemon you will not be able to
communicate with your server and the only option then would be a fresh install with total
loss of data. So be sure not to change any other configuration option. Then save the file.
v. Then you have to restart the daemon so that the configuration changes will be read and
implemented by the server. [systemctl restart sshd], This is the script that manages the
daemon. Again, be very careful with this. What would happen if you issued the
command with “stop” parameter instead of “restart”? Do _not_do this!.

2
 vi. Where is the sshd daemon? Hint: what is it likely to be called, what type of file would it
be and how would you look for it? You could also try reading the management script for
an instruction that locates it.
vii. Now exit to vme and test that you are unable to logon directly as root. [Note: you may
need to kill a hanging process and return to the command prompt with [Control C]. Then
test that you are still able to logon as a lesser privileged user and su to root.

4. Delegating Root Privileges

Often it is necessary to give lesser admins restricted root privileges on a temporary basis. For
this there is the sudo command.

i. Logon as an ordinary team user and try to look at the /etc/shadow file [less
/etc/shadow].
ii. su to root and try again.
iii. Use the command sudo vi to raise the sudo configuration file with vi (please mind that
sudo command works only if the user running are listed in the /etc/sudoers file, hence
you main need add yourself and other group members to the file prior running the
command; the /etc/sudoers file can only be edited by root). Edit it so that any member of
the vhXXteam group can use the sudo command for ALL commands.
iv. logon (or exit) to the lesser-privileged admin and attempt to read the /etc/shadow file
directly
v. Then use the sudo command to try again [sudo less /etc/shadow]. That should be
successful. How long would you have to carry out sudo commands? [hint: visudo will tell
you].
vi. What happens if another user without sudo privileges tries using the sudo command?
What would you do about it?

Techniques/resources:
Solution of all the above tasks will require using UoG Windows machines.

Marking:
No marking, this is to gain practical knowledge necessary for your coursework.

Deadline:
No deadline.