Lab 2 - ETAIS¶

Welcome to the 2nd lab. Here is a short action list that we will do during this lab:

• Accessing ETAIS
• Creating a public/private key pair
• Creating a new CentOS 9 virtual machine in Cloud
• Configuring VPN Client
• Accessing Server over SSH
• Adding scoring account and its public key with no password for '''sudo''' commands
• Update dnf configuration

1. How to login to ETAIS:¶

For the rest of the labs, we use a cloud service called ETAIS. ETAIS’s main aim is to serve Estonian students and researchers. For access, you have been sent an email with instructions on how to log in. You have also been invited into the System Administration organization, and have a private project in that organization.

2. Creating a public/private key pair¶

Before you continue we need to set up public / private key pair so you could use them to connect to the machine.

Public key cryptography, or asymmetrical cryptography, is any cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner. This accomplishes two functions: authentication, where the public key verifies a holder of the paired private key sent the message, and encryption, where only the paired private key holder can decrypt the message encrypted with the public key.

In a public-key encryption system, any person can encrypt a message using the receiver's public key. That encrypted message can only be decrypted with the receiver's private key. To be practical, the generation of public and private key pairs must be computationally economical. More on that here.

Generating key pair and uploading the public key to the SSH server¶

Copy the public key to ETAIS.¶

Once the public key is successfully added, you should be able to see it in the list of SSH Keys in the left-side menu in ETAIS:

3. Creating a new Virtual Machine (VM)¶

General Network Topology¶

Normally each virtual machine has a Internal and External IP listed in ETAIS. Upon creating a project's virtual private cloud (done for you in this course), a virtual router is set up for your project. This router possesses and internal and external IP address.

Internal IP¶

Internal IP is obtained from a pool of private network address space - 192.168.42.0/24. When your VM only has this address it operates behind the virtual router as any home/small-office router - your private network is behind a source network address translation (Source NAT). While your VM's internal IP is taken from the address space of 192.168.42.0/24, your virtual router gets an address of 192.168.42.1/24. Upon sending data to the world (making a request for some sort of data e.g. requesting a google.com in your browser) from an IP of 192.168.42.X, your packets first hit your router's internal IP (192.168.42.1), then the source NAT is applied and the traffic exiting your router has an address of 172.17.X.X. When data is retrieved from the internet based on your initial request the data initially hits the external IP of 172.17.X.X and then gets translated back to 192.168.64.X. This only allows traffic in when it is initiated from the private network. If you would like to initiate connection with your VM (e.g. ssh, web request) with only Internal IP then it would not be possible due to Source NAT - same applies for home/small-office setups.

External IP¶

An External IP is obtained from a pool University Campus network address space - 172.17.0.0/24. When an External IP is applied to your VM, your project's virtual router becomes invisible. This means your machine becomes visible from inside the University of Tartu's internal network. You can initiate communications with your VM from your laptop and elsewhere from the UT's internal network. This is like an public IP address but only in the sense that it works in the university's internal network - keep in mind, that when trying to connect to the External IP from home you need to have the university VPN running or you need to be in university's Eduroam network.

Network topology diagram¶

4. Configuring the VPN Client¶

To access your newly created Virtual machine you need to be inside of University of Tartu network. In the classroom or inside the University of Tartu eduroam network it is possible to access your machine without a VPN, but we do recommend setting up a VPN for remote access outside the University network. You can skip this step if you have already configured a UT VPN.

A virtual private network (VPN) extends a private network across a public network and enables users to send and receive data across shared or public networks as if their computing devices were directly connected to the private network. Applications running across the VPN may therefore benefit from the functionality, security, and management of the private network. VPNs may allow employees to securely access a corporate intranet while located outside the office. They are used to securely connect geographically separated offices of an organization, creating one cohesive network. More about that here.

5. Access machine over SSH¶

Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over a network. The best-known example application is for remote login to computer systems by users.

SSH provides a secure channel over an unsecured network in a client-server architecture, connecting an SSH client application with an SSH server. Common applications include remote command-line login and remote command execution, but any network service can be secured with SSH. More on that here.

Connecting to Cloud resources (VM-s) over SSH is preferred. Therefore SSH is installed in your system by default, as the cloud infrastructure takes care of bootstrapping and installing your CentOS 9 OS. The other option is to use the slow network console from minu.etais.ee, but usually this is reserved for emergency purposes.

6. Adding root password¶

VMs in ETAIS by default come without passwords. Meaning you can only gain access to the VM with the correct public keypair. In this course, the root user should have a password, as it allows for disaster recovery in case something happens to your key/VM through the web console. In general system administration, root passwords are usually not used, or only for disaster recovery purposes. Having a password with full control of your services/server is a security risk.

7. Adding scoring account¶

Now we will add a scoring user which will be used by our lab instructors and an automatic scoring service to log in and check your machine.

Now let's give our lab instructors and automated scoring system access to your VM over SSH using a scoring account. The public key for the scoring user is available for download here, and it works exactly like your own public-private keypair for ssh. Download scoring user's public key.

Now let's add the downloaded public key to the list of authorized keys for scoring account:

What we did was add the scoring server's public key into a special file named authorized_keys, the contents of which are checked by the SSH service in the VM for each login to assess authentication methods for that particular user. This process is identical to the VM setup scripts adding your key under the authorized_keys file under the centos user(you are encouraged to check the contents of /home/centos/.ssh/authorized_keys). The format of the file allows for multiple keys as well, one per line. When manually adding new keys to any user, make sure the formatting is correct and that the key header ssh-rsa is attached to the key.

The last thing to do is to give the scoring user rights to execute commands in root permissions. We need the scoring user to be able to run programs that need root access, but we are not going to give root privileges to the scoring backend (root password is unknown and root user cannot log in over SSH). To give a regular user the ability to execute a particular command in superuser rights there is a tool called sudo. sudo allows running programs with the security privileges of another user, which, by default is the root user. For more information on sudo read a short review on here.

scoring@host:~$ sudo ls -l /root

8. Perform backups¶

Whenever you are about to introduce some portion of changes to your system it might be wise to back up the current state first. Configuration mistakes might result in locking the network access. Once network access is lost - you can't control your VM over SSH anymore, and it might be useful to restore from backup (not always). There is a recovery console (Action button in ETAIS next to your VM has Open console option), but that only works if you have set a root user password.

ETAIS infrastructure does allow you to perform the snapshots of your VM image. By creating a snapshot you are saving the state of the whole hard drive, and once the snapshot is created you can proceed with dangerous actions knowing that you can always recover to the last snapshot's state in case you misconfigure something. But this should not happen often, and keeping multiple snapshots is not necessary. Another way of backing your VM state is to automate VM creating with Ansible, something we will be covering in the next lab. Ansible scripts allow you to automate the steps you do in this course, and in the case of VM corruption, easily re-setup your machine to the last state. Using Ansible is also encouraged during the exam and a properly configured Ansible can automate the whole exam, allowing easy pass of the course sometimes in minutes.

9. Security groups.¶

Computers and especially servers usually utilize their firewalls for security reasons. This allows the administrator of the machine to dictate how network connections can be made to or from the server. The most usual use-case for this is opening ports for services, so they could be reached from the outside world, but in the same mindset limiting service availability from different networks.

Usually, with any sensible cloud provider, you have their provided extra (second) layer of firewall, which has to be configured from outside the machine. This is to make sure, that even if your machine becomes compromised, network security policies (firewall rules) could not be changed easily.

From this lab onward we need to sometimes open ports for our VMs, to allow config of the different services we set up. Some of these security groups should be preconfigured in the course project already, but configuring the firewall of your VM is entirely up to You. Below is a small guide on how to configure firewall rules if the guides ask for them.

10. Updating DNF:¶

DNF (Dandified YUM) is a new package manager for the CentOS platform. This can be used to install, update, remove software and handle dependencies.

* sudo dnf update
* Use DNF to install your favorite text editor and a package named "sl"

11. Linking your VM to Matrix number¶

Due to the fact that we allowed you to use any VM name possible, we now have to make sure your machine belongs to who claims it belongs to. For this reason we ask you to do the following task:

VM name: <your_VM_name>
Matrix number: <your_matrix_number>

This lab is done.