Difference between revisions of "OSL840 Lab 1"

From CDOT Wiki
Jump to: navigation, search
(Created page with "== OBJECTIVE & PREPARATION== In OSL740, you learned how to configure a virtual private network for your '''vm1''', '''vm2''' and '''vm3''' virtual machines. You were required...")
 
Line 1: Line 1:
== OBJECTIVE & PREPARATION==
+
= Accessing your AWS account =
In OSL740, you learned how to configure a virtual private network for your '''vm1''', '''vm2''' and '''vm3''' virtual machines. You were required to configure a static network connection for your VMs. In OSL840, you will also be setting up a static network connection for all of your VMs (which all VMs will be text-based). All of the services that we install and configure for this course '''require a working network connection'''; therefore, it is very important that you know how to configure a network connection for your VMs, whether via command line for trouble-shooting purposes, or to create a persistent (permanent) network connection that uses static IP address (as opposed to DHCP).
 
  
This lab is a <u>review</u> of the material from  labs 6 ( [http://zenit.senecac.on.ca/wiki/index.php/OPS235_Lab_6_-_CentOS7#Part_4:_Configuring_VM_Network_Setup_via_Command_Line_.28centos3.29 CLI Network Configuration] ), but will also additional topics.
+
At the beginning of the semester your professor will create a Leaner Lab in AWS Academy. The professor will add all the students enrolled in their OPS345 sections as students in that Learner Lab. You should automatically receive an email that looks like this in the beginning of the course:
  
=== Online Resources===
+
[[File:AWSAcademyInvitation.png|800px|border|center]]
  
*[https://www.tty1.net/blog/2010/ifconfig-ip-comparison_en.html ip vs ifconfig]
+
If you haven't received such an email: you need to let your professor know.
*[https://www.digitalocean.com/community/tutorials/how-to-use-rsync-to-sync-local-and-remote-directories-on-a-vps rsync Howto]
 
*[https://help.ubuntu.com/community/CronHowto Cron HowTo]
 
  
== INVESTIGATION 1: BASIC NETWORK CONFIGURATION (REVISITED) ==
+
Once you complete setting up your account: you might want to bookmark this page, or even make it your home page: https://awsacademy.instructure.com
  
Remember how you set up the network interfaces in your virtual machines in OPS235?
+
Browse around the interface. To do your work for OPS345 you only ever need to navigate to "Courses" > "AWS Academy Learner Lab - Foundation Services" > "Modules" >  "Learner Lab - Foundational Services", which looks like this:
You are expected to be familiar with how to configure and test out a VM's network connectivity at this point.
 
  
=== Checking Your Current Network Settings ===
+
[[File:AWSAcademyLearnerLabHomeScreen.png|800px|border|center]]
  
In OPS235, you have used the '''ifconfig''' and '''route''' commands. In this course we'll use the '''ip''' command instead, so that you'll be familiar with both sets of commands.
+
The links you'll use most often are highlighted in green:
  
 +
# This is the amount of credits you have used out of your allocated 100$. Unlike the screenshot yours will start at zero.
 +
# Most of your AWS resources are turned off unless your lab is started. Click this button to start the lab. There is only one lab for the entire OPS345 course, you will start it many times.
 +
# The amount of time the current session of the lab has been running. After the 4 hours runs out the lab will be stopped and the associated resources will be shut down.
 +
# Click here to get to the AWS web interface where you'll do most of your work.
  
'''Perform the following steps:'''
+
Your work which you save inside your virtual machines is not deleted once the lab stops. AWS Academy simply shuts down your virtual machines. Your virtual machines and the rest of your Learner Lab resources '''will''' be deleted automatically at the end of OPS345.
  
# View the table below comparing  ''older'' vs ''newer'' methods of obtaining network setting information for a Linux machine.
+
The first time you start the lab it may take a few minutes, much longer than usual.
  
 +
= AWS cost monitoring =
  
::'''Comparison of Older and Newer Methods of Obtaining Network Settings'''
+
Normally using resources from AWS costs money. AWS costs are very competitive, but their resources are not free. In an AWS Academy Learner Lab you get a 100$ credit which will be more than enough to cover all your resources until the end of the course if you're not reckless.
  
<table border="1" cellspacing="0" cellpadding="5" style="margin-left:51px;">
+
{{Admon/important|You are responsible for your AWS usage!|If you run out of credits: you will have to find another way to finance completing the required hands-on parts of OPS345.}}
<tr><td>'''Purpose'''</td><td>'''Older Method'''<br>''(command)''</td><td>'''Newer Method'''<br>''(command)''</td></tr>
 
<tr>  <td>Obtain IP ADDRESS and Subnet Mask</td><th>ifconfig</th><th>ip address</th></tr>
 
  
<tr>  <td>Obtain Default Gateway</td><th>route -n</th><th>ip route</th></tr>
+
Take this as an opportunity during OPS345 to learn what costs how much money in the cloud. The skills of managing cloud costs are very valuable. Unfortunately AWS Academy doesn't make it easy for you. On the unrestricted AWS you have access to AWS Budgets, Amazon CloudWatch Billing Alarms, and other tools to help you monitor and control your costs. But due to the way AWS Academy was designed: you won't have access to those tools. That's in return for the free 100$, which most students don't complain about.
  
<tr>  <td>Obtain DNS Server</td><th>nslookup</th><th>more resolv.conf</th></tr>
+
Even without the budget restrictions in AWS Academy: AWS costs are not easy to manage. Here are some examples of what you'll run into:
  
<tr>  <td>Obtain Hostname</td><th>uname -n</th><th>uname -n</th></tr>
+
* Resources that say "Free" on the label, but will only be free in a specific configuration.
 +
* Resources that are free unless you exceed some threshold of usage (CPU usage, bandwidth, etc.)
 +
* Resources that cost money only when they are ''not'' used. That was not a typo.
 +
* And the most common of all: resources that don't have a cost listed next to them at all.
  
<tr>  <td>See MAC cache</td><th>arp -n</th><th>ip neighbour</th></tr>
+
So in order to learn anything about costs on AWS: pay attention whenever you see a note about the cost of anything, even though it will be a distraction from what you're trying to accomplish at that time. There are many places where such notes are scattered. Always keep cost in the back of your mind when doing ''anything'' on AWS. Then hopefully you'll get a general idea, so that when you're done with OPS345 you can have an intelligent conversation about it.
  
</table>
+
= Basic security on a public-facing server =
  
 +
Security is a topic most people aren't qualified to address. That's because it's complicated on its own, but in order to set it up properly: it also requires a solid understanding of the fundamentals of the systems which need to be secured.
  
<ol><li value="2">Run the '''ifconfig''' command on your '''host''' machine. Check and record the IPADDR for your default (dhcp) network interface card (possibly eno1) and the virtual bridge.</li><li>Issue the '''ip''' command on your '''host''' machine to determine the IPADDR and GATEWAY information (refer to above chart). How are the result similar or different than the ifconfig command?</li><li>Issue the ifconfig command on your VMs. what happened?</li><li>Use the '''ip''' command for your VMs to list the IPADDR and GATEWAY information.</li><li>Refer to the man pages or refer to following article [http://www.tecmint.com/ip-command-examples/ 10 Useful ip Commands] to see how to issue the above commands to create a <u>temporary</u> connection to your existing network.</ol>
+
That doesn't mean you can't learn it. As with most technologies, the recipe for success is simple. The more time you spend on it: the better you get. Every bit of learning you do related to security will make you more qualified. The more qualified you are to speak about security issues: the more valuable you are as a technician or engineer. Even if you're not directly responsible for security of a system: you will always have to work with security measures, and sometimes around them.
  
=== Making Persistent (Permanent) Network Setting Changes ===
+
{{Admon/tip|Your attitude matters|Usually if you follow the rules of the organization you work for: security breaches are somebody else's problem. But not always. For example if you get your AWS Academy account suspended by Amazon because your password was "123" - I won't feel bad for you, and ''you'' will have to find a way to complete the requirements of the course. And whether it's your problem or not: wouldn't you rather be a part of the solution?}}
  
In your OPS235 course, you used a series of commands (ifconfig, route, and nameserver) to setup a temporary network connection. You can use the ip command (a another command) in a similar way to create a temporary network connection. The problem with this network connection method is that those changes will be lost if you restart your Linux machine, although you may want to do that to create a temporary network connection for troubleshooting purposes.
+
So as with AWS costs there are some steps I can tell you to follow, but overall you should take some time to think of security whenever you do anything. Who has access to a specific machine? Network? Service? Storage device? Is it hard to steal/crack a password and impersonate one of your users? Is your system vulnerable to off-the-shelf attacks? Keep those questions in the back of your mind, and as a minimum follow the following guidelines:
 
In order to have your network settings become permanent, you need to edit and save the settings changes in a file.
 
For the IP address, subnet mask, default gateway, and DNS server you edit that file is contained in a directory called '''network-scripts'''.
 
  
'''Perform the following steps:'''
+
* Set a good password for your AWS account, and don't use that password for '''any''' resources inside AWS. Your AWS account password is like a super-root password. It gives you full access not only to a specific machine, but to all machines, networks, storage devices, and billing. You can end up running someone else's botnet, and paying for it too.
 +
* Possibly the most common attack on a Linux machine is the brute-force SSH login attack. It takes very little setup to mitigate almost all these attacks:
 +
** Delete all default usernames, except root which you can't delete.
 +
** Make sure that root is never allowed to log in remotely.
 +
** Whenever possible: don't use passwords at all, use SSH keys for logging in. You've learned how to use them in OPS245.
 +
* Learn how to use sudo and how to configure it.
 +
* Get in the habit of organising your SSH keys so you don't accidentally lose them.
  
# Change to the ''network-scripts'' directory (see your ''OPS335''/''OPS235''/''ULI101'' notes).
+
Remember that unlike ULI101/OPS245 your servers are on the real internet, and depending on how you configure them: they might be accessible by any attacker on the planet. You need to pay much more attention to security in this course than was required in ULI101/OPS245.
# The name of the file that contains your persistent network settings has the following name format:<br>'''ifcfg-''interfacename'''''
 
# Which file-name in your network-scripts directory do you think contains your current network settings?
 
# View the contents of the file to see if it contains the IP address, subnet mask, and default gateway.
 
# What is the MAC address if your current machine?
 
# Does this file contain the hostname of your machine? If not, what command can allow you to change your machine's hostname?
 
  
 +
= First AWS VM =
  
Except for your host machine, all the Virtual Machines in this course will have '''static network configuration''' (as opposed to Automatic or DHCP). Sometimes, you will be required to debug networking problems quickly by changing the network configuration of your VMs.
+
We're going to set up a virtual machine in AWS now so you can start to get used to the process. You'll be repeating this several times during the course, try to learn a little more about it each time you do it.
  
 +
== Security group ops345first ==
  
<ol>
+
A '''security group''' is a fundamental concept in AWS. It's not completely clear what it is. The closest thing you would have seen that's similar is a set of iptables rules. You can assign the security group (this set of rules) to one or more virtual machines.
<li value="7">Edit  the '''ifcfg-''interfacename''''' (most likely ifcfg-eth0) file for each of your VMs to use a static IP address (refer to previous OPS235 lab on networking: [ [https://wiki.cdot.senecacollege.ca/wiki/OPS235_Lab_6#Part_3:_Configuring_VM_Network_Setup_via_Command_Line_.28centos3_and_centos2.29 Network Config - CLI] ].<br> You should be configuring the BOOTPROTO ('''static''' instead of dhcp), IPADDR, PREFIX (or NETMASK), GATEWAY, HWADDR, and DNS1 for this file. Note the following information for this setup:<ul><li>Set your IPADDR for each VM with the following rules:<ol type="a"><li>Your IPADDR's third octet will use the last 2 digits in your student number.</li><li> Make certain that the 4th octet for your VMs does not start with '''1''' since that is reserved by your host machine.<br>Use the recommended fourth octets: '''2 for vm1''', '''3 for vm2''', and '''4 for vm3'''.</li></ol></li><li>Don't forget to set the default gateway and DNS server for your VMs. You can use your host's IP address as a gateway and DNS server<br>(''libvirt'' will proxy the requests to the real DNS server).</li><li> You can refer to your previous lab to obtain information for setup of these options: [ [https://wiki.cdot.senecacollege.ca/wiki/OPS335_Installation_Lab#Configuring_a_VM_host Configuring a VM Host] ]<br><br></li></ul><li>Make note of the files used and entries required and note them in your lab log-book.</li><li>Save your editing session, and then restart each VM and run the following command to ensure they still have the network configuration you set:<ul><li>'''ping''' (what is the purpose of this command?). Try to ping google from your host machine.<br>Try to ping google from each of your VM's to ensure you can reach the outside world.</li><li>'''ssh''' (into another server, like Matrix) </li></ul></li><li>After setting the network configuration for EACH VM, then either the the ifdown and ifup commands or reboot each VM, to verify that you can connect to the Internet with the new static IP network configuration. If you cannot connect to the Internet, then check the network configuration file and make corrections until you have a workable network connection for each VM from boot-up.</ol>
 
  
 +
A security group with no rules does not allow any traffic to pass through.
  
If you are uncertain how to perform those above-listed operations by member, take time to practice them.
+
* Create a new security group "ops345first" with only the SSH port open to the world in the incoming rules. Familiarize yourself with the interface. You'll use this security group for your first VM you'll soon create.
If everything works and you are comfortable with these operations then you may proceed to the next section.
 
  
=== Linux Network Connection Configuration Troubleshooting ===
+
[[File:AWSCreateSecurityGroup.png|800px|border|center]]
  
If the network works in your host, but not in your Virtual Machine, you should perform the following routine steps to troubleshoot the network connection:
+
== Create ops435-first VM ==
  
# '''IS THE NETWORK ON VM PLUGGED IN?''' On a physical network you would check whether the cable is plugged in and the link light is on on your network card. In a virtual network environment, you don't have a physical network adapter. Instead, you will need to check the NIC settings in the <u>'''virtual'''</u> machine details to view and confirm the appropriate network connection.
+
In AWS language an '''instance''' is what you've called a '''virtual machine''' in OPS245. An '''AMI''' is a '''pre-built disk image''' of an operating system, provided so that you don't need to install an operating system from scratch. The AMIs are typically provided by Amazon or the AWS community.
# '''IS THE NETWORK ENABLED?''' This is a problem more common with virtual networks than physical networks. Check in:<br> '''VirtManager'''-> '''ConnectionDetails'''-> '''VirtualNetworks''' that your network is active.
 
# '''DO YOU HAVE AN IP ADDRESS?''' Run '''ip address''' to check.
 
# '''CAN YOU PING THE HOST BY IP?''' (by its internal IP address). If not - check all of the above, check if you have an IP address conflict, and check that your subnet mask is correct.
 
# '''CAN YOU PING 8.8.8.8?''' If all of the above work - check that your default gateway is set correctly with '''ip route''' and that you can ping the default gateway.
 
# '''CAN YOU RESOLVE google.ca?''' Run '''host google.ca'''. If the output doesn't provide an IP address, check that your DNS server is configured correctly and that you can ping that address.
 
  
There  are a number of other problems that could prevent your network connection from functioning but the above are the most common problems.
+
An AMI is only the initial disk image your VM will start with. As soon as the VM is booted for the first time: your disk image will begin to deviate from the original. That means for example that you have to keep up with security updates on it even though the AMI you used had all the security updates installed when you used it to bootstrap your instance.
  
==== Run Script to Break Network Connection for Troubleshooting ====
+
With an AWS Academy account you can see what AMIs are available on AWS, but your selection is severely limited. We'll only be using the '''Amazon Linux''' AMI. You'll find it quite familiar as it was originally based on CentOS.
  
You will now download, set execute permissions and run a Bash shell script to try to "break" the network connection for your vm1. This will provide troubleshooting practice to check your network configuration file, look and correct errors and restart your network interface connection.
+
* To create a new virtual machine you need to go to "Instances" and click "Launch Instances". An unfortunate choice of words by Amazon. It sounds like that button should start an existing instance. It should have been called "Create Instance".
  
 +
The first time you go through this process try to concentrate on not getting overwhelmed by the available options and the unintelligible AWS lingo. You'll have lots of opportunities to better understand the available options.
  
Perform the Following Steps:
+
* Select the "Amazon Linux 2 AMI (HVM), SSD" AMI.
 +
* Don't use the "Review and Launch" button instead go through each of the 7 steps.
 +
* Leave the t2.micro default checked and click Next.
 +
* Leave all the defaults under '''Instance Details'''.
 +
* Don't change the storage configuration under '''Add Storage'''
 +
* Don't add any tags under '''Add Tags'''.
 +
* At the '''Configure Security Group''' step: select the security group "ops345first" which you just created.
  
#Move to your '''vm1''' machine and make certain that you are logged in as '''root'''.
+
After you review your configuration and click "Launch" a popup will come up asking you for a key pair. It's important for you to understand what it's asking for. It is the same type of SSH key pair that you've created and used in the [[OPS245 Lab 7]]. Remember that your private key is yours, it's private to you, and not for anyone else to see. AWS is asking you to give them the public key which is the pair of the private key which you wish to use to log in to your new VM. In this case your private key is the effective equivalent of the root password.
#Make certain that the '''wget''' command is available on your VM. If not, install the wget application. Make certain to do for ALL of your VMs.
 
#Use the '''wget''' command (with option "--no-check-certificate" ) to download and run the following shell script:<br>http://scs.senecacollege.ca/~murray.saul/ops335/break-network.bash
 
#When you have run that shell script, it should automatically restart your vm1.
 
#Login to your vm1.
 
#Use the commands taught in this lab to confirm if your network connection is broken.
 
#Carefully check your configuration to see if there is a change to your settings
 
#Try to temporarily connect to the Internet
 
#Edit your network settings file to make the changes permanent
 
#Test your connectivity (including after a reboot of your vm1)
 
  
'''Note:''' You should be able to go through that troubleshooting process pretty quickly. Setting up the network in this course is never a primary task, but it's almost always a prerequisite for anything else we're going to do. You can't have a working web server (or any other kind of server) if you don't have a working network connection.
+
* Create a new RSA key pair named ops345-first-key, and download it as ops345-first-key.pem on your workstation under a new directory ~/ops345/keys/ssh/
  
 +
Yes, that means AWS generated your private key and theoreticaly they could keep it, but they promise that they don't and that's almost certainly true. Once you donwload the private key and click "Launch Instances" - the only way to log into your new virtual machine is using the private key you saved. AWS does not provide the equivalent option of "reset your password" for instances that were already created.
  
'''Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log-book'''
+
[[File:AWSFirstInstanceCreated.png|800px|border|center]]
  
== INVESTIGATION 2: Configuring SSH ==
+
* After your instance is created: you will see it listed under "Instances". Set its name to "ops435-first". Get used to naming things in AWS because otherwise you'll have a hard time distinguishing your instances from each other, unless you're unusually good at remembering long random strings of characters.
  
The default (and often the only way) to administer a Linux server is via SSH. Even if you work in a graphical Linux environment, it is very useful to open a terminal and use SSH to monitor and manage your VMs (you can resize the terminal window). Using SSH to connect to remote servers on a network helps to protect your Linux machine from being penetrated. You can also generate a private and public encryption key for the root user, and copy that public key from your host to your VMs in order to allow certain backup programs to run via a scheduling daemon (called cron) without having to be required to enter the password for the remote machine. You will be doing those operations later in this lab.
+
== Explore your new VM ==
  
=== Managing Services ===
+
You're not going to find a button in the AWS to "view the screen" of your virtual machine. The only way to control it is via an SSH connection.
  
The SSH server should already be installed and running in your VMs. If it's not installed, you can install '''openssh-server''' using yum.
+
Look at your ops435-first instance details and find its automatically-assigned public IP address. Connect to it with SSH. Note that you need to user your private key to connect, and since it doesn't have a default name nor is it in the default location for SSH keys: you need to specify the path to it manually.
It is essential for CNS/CTY students to become comfortable managing services since you will need to constantly stop services, change their configuration, and start them for the configuration changes to take effect in nearly every topic this semester, and for other courses involving Linux network management.
 
  
 +
The default username on Amazon Linux is '''ec2-user'''.
  
'''Perform the following steps:'''
+
[[File:AWSFirstSSH.png|800px|border|center]]
  
# Note the following [http://zenit.senecac.on.ca/wiki/index.php/Init_vs_systemd#systemd_Command_Usage systemctl] commands (refer to man pages or the Internet) and become comfortable using them:
+
You have at least one semester's worth of experience of CentOS, so look around to see if anything looks different from what you're used to. For example:
  
::* '''systemctl list-units --all'''
+
* Many packages not installed by default in the Minimal installation of CentOS (e.g. net-tools) ''are'' installed by default in Amazon Linux. I like to also install telnet and nmap.
::* '''systemctl start/stop'''
+
** Note that Amazon Linux has its own package repositories: '''/etc/yum.repos.d/''', but the yum/rpm commands work the same as in CentOS.
::* '''systemctl enable/disable'''
+
* The systemctl command to control your services works the same way as in CentOS.
::* '''systemctl status'''
+
* Note neither iptables nor any other firewall is installed by default. It is in CentOS.
 +
* You user information files ('''/etc/passwd''', '''/etc/shadow''', '''/etc/group''') are used in a completely standard way.
 +
* Have a look at the output of '''netstat -atnp''' and '''netstat -aunp''' to see what ports services are listening on in a default installation.
  
<ol><li value="2">Launch your '''vm2''' machine, login to the machine, and open a shell terminal.</li><li>Use one of the commands above to check the status of your SSH server (i.e. service: ''sshd'').</li><li>Issue one of the above commands to stop of the ssh server and run a command to verify that the ssh server is no longer running.</li><li>Issue another one of the above commands to start the SSH server and to verify that it is running.</li><li>Issue a command to confirm that the ssh service will run upon when the vm2 server restarts (i.e. "enabled").</li></ol>
+
It's not completely clear what Amazon's policies are for supporting Amazon Linux. From people's experience it appears to be quite stable, but as a rolling release you might not want to depend on it for production use. For our learning purposes it's plenty stable and consistent. One nice thing about Amazon Linux is that it is not linked to RedHat/IBM support cycles and policies which have changed significantly after IBM's acquisition of RedHat.
  
===Configuring the SSH Service===
+
== Change the default username ==
  
A common (if somewhat blatant) way to try to hack into a machine is to try to ssh as '''root''' and brute-force root's 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 will edit the configuration file for the ssh service to prevent root from ssh'ing into your host machine.
+
For security purposes we're going to remove the default ec2-user. That would be simple if you were sitting in front of the machine, but since you can only connect to it via SSH and the only user you can SSH as is ec2-user: it takes some extra work. You're going to do this for every machine you create in OPS345, so get used to the steps. It's good practice:
  
 +
* Use the useradd command to create a new user. To make your life easier: set the username to be the same as your myseneca username, with the same capitalization.
 +
You do not need to set a password for this user. Passwords can be guessed using a brute-force attack. SSH keys are practically immune to such attacks.
 +
* Make sure your new user can run sudo without a password, same as ec2-user. Create '''/etc/sudoers.d/10-ops345-users''' with these contents:
 +
<pre>yoursenecaid ALL=(ALL) NOPASSWD:ALL</pre>
 +
* Allow your new user to log in using the SSH key you already have. You could create a new key pair instead, but you don't have to. Remember that your username is not asmith15:
  
'''Perform the following steps:'''
+
[[File:AWSCopySSHKey.png|border|center]]
  
#Login to your Centos '''host''' machine for the following steps.
+
* Confirm ssh into your VM as yoursenecaid and successfully sudo su -
#Use the more command to display '''/etc/ssh/sshd_config''' on your host. This file contains the configuration parameters for the ssh service.
+
* ''After you're sure that you can'': delete ec2-user including the home directory. Use the userdel command.
#Take a few moments to view this file. 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 a text editor to edit the file '''/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 '''PermitRootLogin''', and change the value to '''no'''.
 
#Try to use ssh from one of your VMs to log into your host as root. What happened?
 
#This is because (for most services) the '''changes you make to the configuration file will 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 option '''PermitRootLogin''' for '''all of your VMs''' for both labs and assignments MUST be set to '''yes'''. The reason for this is that you have created a virtual network, so you have protected the host from root login, so you don't have to do the same for your VMs. Also, by allowing root login for your VM's will allow you to automatically backup your VMs to your host machine (via a crontab entry) without being prompted for a root password for each VM.
 
  
'''Note:''' 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.
+
== Set the hostname ==
  
=== SSH Key Concepts===
+
For reasons that are hard to explain quickly the hostname on your AWS VM is not static by default, but we'll make it static so it's more familiar to you.
  
After performing lab7 in OPS235, you should have a basic understanding of ssh and public/private key cryptography to create secure connections between servers.<br>
+
* Update the hostname to '''first.yoursenecaid.ops345.ca''' and make sure it doesn't get reset when your VM reboots. Follow the relevant parts in https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-hostname.html
The public key can be "shared" with other server accounts, and can be used in conjunction with your private key in order to help encrypt/de-crypt data.  
+
* Also change the instance "Name" in the EC2 management console to "first". This is not necessarily the same as the hostname. It's the equivalent of the VM's name you've used in Vmware in OPS245.
  
The diagram below  is shared from [http://sebastien.saunier.me/blog/2015/05/10/github-public-key-authentication.html Sébastien Saunier's blog].
+
[[File:AWSSetHostname.png|800px|border|center]]
It demonstrates how SSH key authentication works. It's not a complete diagram, but it helps see all the parts of ssh key authentication in one place.
 
  
[[Image:ssh_connection_explained.png|thumb|center|600px|A diagram explaining how public / Private keys work. Another term to represent this process is called '''PKI''' (Public/Private Key Infrastructure) ]]
+
= Submit evidence of your work =
<br />
 
Put this book on your "must-read" list. You can borrow a copy from the Toronto Public Library. I have yet to see a better introduction to encryption. It's not a reqirement for OPS335 - but if you want to not be clueless about security fundamentals online - read that book and understand it.
 
  
[[Image:crypto.jpeg|center|"crypto" by Steven Levy]]
+
For this lab, please submit screenshots that show you've completed the work, unless your professor has given you different instructions.
  
=== Generating a Public/Private Key Pair &amp; Sharing the Public Key ===
+
[[Category:OSL840]]
 
 
The public/private key pair needs to be generated on and used on your '''host''' machine (i.e. the user/machine you're connecting '''from'''). The private key is the equivalent of a <u>''password''</u> (that is why it is considered to be <u>''private''</u> - only to be used by ''<u>one</u>'' owner). That is why the private key is stored in the owner's  '''~/.ssh/''' directory.
 
 
 
One very common mistake that students make is to either generate the key pair for the wrong account, or copy the public key to the wrong account on the intended remote machine.
 
 
 
'''Perform the following Steps:'''
 
 
 
# Make certain you are in your '''host''' machine.
 
# You will be creating a '''key-pair on your host machine with no password''' (i.e. when generating keypair press enter for all prompts including the password).
 
#Make certain you are logged on as '''root''' on your host machine.
 
# Generate the key-pair by issuing the command:<br><source>ssh-keygen -t rsa</source>
 
 
 
'''NOTE:''' When issuing this command, you will end up with the files: '''~/.ssh/id_rsa''' and '''~/.ssh/id_rsa.pub''' (private and public keys). So far, this topic is generally a repeat of OPS235 lab7. What you may '''<u>not</u>''' know is that by using a '''"trick"''' (the ''magic'' of public key cryptography), you can SSH to a Linux machine without using a password! Learning to perform this trick is <u>'''essential'''</u> in this course and in the industry in general. SSH keys are used everywhere that Linux servers are used.
 
 
 
If you have the private key, you can prove to someone who has your public key that you are indeed the '''actual owner of that public key'''. That is how ssh key authentication works. You are then only required to transfer your public key to a remote server.
 
 
 
<ol><li value="5">You are going to share the public key from the '''root user in your host machine''' with the '''root user of your vm1 machine'''.</li><li>Copy the contents of your '''~/.ssh/id_rsa.pub''' from your host machine and append to '''~/.ssh/authorized_keys''' on each of your Virtual Machines. In your case, you will issue the following command 3 times (for each vm IPADDR):<br><source>ssh-copy-id -i ~/.ssh/id_rsa.pub root@IPADDR_for_vm</source>'''NOTE:''' Press ENTER for all prompted information including the password (although this may seen counter-intuitive!).<br><br></li><li>Use the ssh command to test each ssh connection between your host and each virtual machine that you can connect to the VMs without having to use a password. This is essential to create backups from VMs to your hostmachine without being prompted for password.</li></ol>
 
 
 
 
 
{{Admon/important|Errors in Copying Public Key from Host to VM|If you experience an error when copying the public key from your hostmachine to your VM, it is most likely caused from not permitting root login that you performed in the previous section. Set to allow login from root for each vm, restart your sshd service and then re-run the above command.}}
 
 
 
 
 
After you perform either of those operations, you can then ssh into a remote vm without a password.
 
 
 
'''NOTE:''' Always remember that these keys are '''per-user, <u>not</u> per machine'''. This means that sharing a user's public key will only work for that specific user.
 
 
 
== INVESTIGATION 3: PERFORMING &amp; AUTOMATING BACKUPS ==
 
 
 
Data  backups are considered to be an insurance policy. Running backup can be tedious, but they MUST be performed in an accurate and consistent basis, since loss of data can be expensive (For example: cost of hiring staff to re-enter data).
 
 
 
When performing labs or assignments in this class, if you fail to make backups and something bad occurs and there is loss of data, it only affects you. On the other hand, if you are supporting a client, or working for a company and fail to adequately perform backups and there is loss of data, then other users are affected by failure to backup essential data.
 
 
 
=== Performing Full Backups ===
 
 
 
A full backup represents backing up of all of the files of a computer machine (in our case, a VM). A full backup should be performed at the end of each lab or assignment working session.
 
 
 
In OPS235, you learned to use the command '''gzip''', '''gunzip''' (plus'''virsh dumpxml''' / '''virsh define''' if backing up to external storage device like a usb key) to backup your virtual machines. We will use the same method to perform a full backup for these labs and assignments.
 
 
 
'''Perform the following steps:'''
 
 
 
#Make certain that your virtual machines are NOT running.
 
#Make certain that you are logged in as '''root''' user on your host machine.
 
#Refer to OPS235 lab2 on backing up your VMs using the '''gzip''' command [https://wiki.cdot.senecacollege.ca/wiki/OPS235_Lab_2_-_CentOS7_-_HD2#Part_1:_Backing_Up_Virtual_Machines OPS235 Lab2 - Backing up VMs]
 
#Make certain that you have performed a full backup for '''vm1''', '''vm2''', and '''vm3'''.
 
 
 
It is recommended to create a Bash shell script to automate the backing up of ALL your VMs in sequence. You can do this by running a for loop using a list for vm1, vm2, and vm3 image file pathnames.
 
 
 
<ol><li value="5">Create the sub-directory '''/root/bin/'''</li>
 
<li>You should know how to create full backups of your VMs in your OPS235 course. Create a Bash shell script called:<br>'''/root/bin/fullbackup.bash''' that will backup all of your other vms (i.e. vm1, vm2, and vm3) one at a time using the '''gzip''' command to your host machine into the directory path-name: '''/backup/full/'''</li>
 
<li>Set execute permissions, and run the shell script to verify that you shell script works.</li>
 
<li>It is also recommended to backup to your USB key as well (qcow2 images and xml config files).</li></ol>
 
 
 
 
 
It will be your responsibility as an administrator of your own Linux system, to backup all of your VMs for labs and assignments at the end of your lab session. Learning to create shell scripts to automate routine tasks (such as backups) will be EXTREMELY useful for your NDD430 course.
 
 
 
=== Performing Incremental Backups ===
 
 
 
An incremental backup is a backup of only files that have changed since the last backup. In your case, it may be a good idea to perform incremental backups of your '''/etc/''' directory for your VMs upon startup. We will be using the '''rsync''' command to perform incremental backups for all of your VMs.
 
 
 
'''Rsync''' is a very versatile backup tool. As the name suggests, rsync is used for <u>synchronizing</u> files typically across a network. It works over the '''SSH''' protocol, which is useful in our situation since we are running ssh on our server and VMs. You are going to use your ''host machine'' to backup files from the ''virtual machines''.
 
 
 
'''Perform the following steps:'''
 
 
 
 
 
{{Admon/important|Rsync Needs to be Installed on ALL VMs |Since you select minimum install on your VMs, the rsync command was not installed by default. You need the rsync command to be available on your host machine and all of your VMs.  Make certain that the '''rsync''' command is installed on all your vms. }}
 
 
 
 
 
# Make certain that your '''vm1''' machine is running.
 
# Make certain that you are logged in as '''root''' user on your host machine.
 
# On your '''host machine''', run the following commands:
 
 
 
<source>mkdir -p /backup/incremental/vm1
 
rsync -avz 192.168.x.x:/etc /backup/incremental/vm1/    # where 192.168.x.x is the IPADDR of your vm1</source>
 
 
 
'''NOTE:''' This command will '''NOT''' work if '''permit root access is denied for your VMs''' for your sshd service configuration, so keep it off for now...
 
 
 
<ol><li value="4">If rsync prompts for a password, make certain that you completed the '''SSH key''' section above, and that you assigned the keys for the <u>appropriate user</u><br>(in this case, for the '''root user for both the hostname and vm1'''!)</li><li>When the rsync command runs correctly, you should see all the files from vm1 being copied over to your host machine.</li><li>Run the rsync command again. Notice that the second time nothing is copied over to your host machine since none of the files have changed on your vm1 machine.</li><li>Create a new file in vm1's '''/etc/''' directory, and rerun '''rsync'''. Confirm on your '''host machine''' that only that file that was created on your vm1 machine actually got backed up to your host machine.</li><li>Repeat the above steps to create backups for your '''vm2''' and '''vm3''' machines on your host machine as well (for the respective directories: '''/backup/incremental/vm2''' and '''/backup/incremental/vm3''').</li></ol>
 
 
 
=== Automating Backups (cron) ===
 
 
 
Since your host machine and VMs are '''not continuously running''', '''you are not required to schedule to perform your FULL BACKUPS periodically''' (eg. every week at 2:00 AM). Instead, it will be YOUR responsibility to run your full backup script when you complete each of your OPS335 labs, or when you finish your OPS335 assignment working session. On the other hand, '''you will use cron to perform incremental backups''' (eg. copy updated files from the VMs/ /etc/ directory)
 
 
 
 
 
'''Cron''' is a ''daemon'' (i.e. a program that runs in the background). The term ''"Cron"'' is short for '''Chronograph''' which was an old fashioned term for a '''stop watch''' or '''timer'''. The role of '''Cron''' is to run tasks periodically. It can run tasks for the system (as root) or for a user (including regular users). Every user has a crontab (Cron Table) which is a list of tasks they want to run periodically. You do not edit this file manually: instead, you edit this table using the command '''crontab -e'''. Once you run the command, you will get an empty file where you have to insert a line like this:
 
 
 
'''Perform the following steps:'''
 
 
 
# Refer to the following WIKI to learn how to use cron: [[crontab tutorial]]
 
# In your host machine as root, modify the setting so it will run that echo command every minute by creating a crontab (via '''crontab -e''') entry with the following line:<br><source>* * * * * echo "Cron ran this job at: "`date` >> /tmp/cron.log</source>
 
# Save and exit your crontab edit session.
 
# Wait for one minute to pass, and check the '''/tmp/cron.log''' file to see if it was created with the expected contents.<br>(You can also check '''/var/log/cron''' file to see what jobs were run).
 
# Perform a Net-search to see how to configure that crontab entry to run every two minutes instead of every minute.
 
# Edit your crontab entry to run same command every two minutes, save and exit, and then confirm by viewing '''/tmp/cron.log''' and '''/var/log/cron''' files.
 
# Perform a Net-search to see how to run a cron for a command for every hour.
 
# Edit your crontab to '''make automatic backups using the rsync command''' of the '''/etc''' directory from '''vm1''', '''vm2''', and '''vm3''' into '''/backup/incremental/vm1''', '''/backup/incremental/vm2''', and '''/backup/incremental/vm3''' every hour and overwrite the previous backup.
 
 
 
 
 
{{Admon/important |Backup your VMs!|You MUST perform a '''full backup''' of ALL of your VMs whenever you complete your '''OPS335 labs''' or when working on your '''OPS335 assignments'''. You should be using the gzip command, and you should use  the Bash shell script that you were adviced to create in order to backup all of your VMs.}}
 
 
 
 
 
'''Record steps, commands, and your observations in INVESTIGATION 2 in your OPS335 lab log-book'''
 
 
 
== COMPLETING THE LAB ==
 
 
 
===Online Submission===
 
 
 
Follow the instructions for lab 1 on blackboard.
 
 
 
<!--
 
===Andrew's sections===
 
 
 
You may choose to:
 
* Submit screenshots of your work on Blackboard, in which case you don't need to come to the lab.
 
* Or come to the lab, show me your work, and talk to me about it. I want to hear what you've learned and answer any questions you have.
 
 
 
You'll get the same grade regardless of how you choose to submit your work.
 
 
 
Expected results of this lab are:
 
 
 
::<span style="color:green;font-size:1.5em;">&#x2713;</span> Each of your VMs should now boot to a command prompt (no graphical interface), and should be using a static IP address.
 
::<span style="color:green;font-size:1.5em;">&#x2713;</span> Each of your VMs should have a working network connection and a static IP address.
 
::<span style="color:green;font-size:1.5em;">&#x2713;</span> Each of your VMs should have an SSH server running.
 
::<span style="color:green;font-size:1.5em;">&#x2713;</span> should be able to ssh from your host to each VM as the root user without a password.
 
::<span style="color:green;font-size:1.5em;">&#x2713;</span> Display contents of backup script called: '''/root/bin/fullbackup.bash'''
 
::<span style="color:green;font-size:1.5em;">&#x2713;</span> Full and incremental backups of your 3 VMs.
 
::<span style="color:green;font-size:1.5em;">&#x2713;</span> You have notes in your lab-book about what you've learned in this lab.
 
::<span style="color:green;font-size:1.5em;">&#x2713;</span> Run a shell script : http://matrix.senecac.on.ca/~murray.saul/ops335/labcheck_network_backup.sh
 
-->
 
 
 
== EXPLORATION QUESTIONS ==
 
 
 
# Explain the major different between the '''ip''' and '''ifconfig''' commands.
 
# List the steps to create a '''temporary static IP network connection''' for your vm1 machine to connect to your host machine.
 
# List the steps to create a '''persistent static IP network connection''' for your vm1 machine to connect to your host machine.
 
# List at least '''3 trouble-shooting techniques''' to check or verify a network connection from a vm to a host machine.
 
# List at least '''5 reasons''' (from networking trouble-shooting) that can break a network connection.
 
# List the tools (commands) how to configure / stop / start the ssh service.
 
# Explain why it is important to know how to manage network services if you intend to configure ("tweak") the service.
 
# Briefly explain the purpose of the '''tar''', '''cpio''', '''dump''', '''restore''' commands.
 
# Explain how the '''rsync''' command differs from the ''tar'', ''cpio'', ''dump'', and ''restore'' commands.
 
# List the steps to create a '''crontab''' entry to run the program '''/bin/clean-out.bash''' every half day.
 
# What is the purpose of using '''crontabs''' for backing up your virtual machines' data to your host machine?
 

Revision as of 09:54, 3 September 2022

Accessing your AWS account

At the beginning of the semester your professor will create a Leaner Lab in AWS Academy. The professor will add all the students enrolled in their OPS345 sections as students in that Learner Lab. You should automatically receive an email that looks like this in the beginning of the course:

AWSAcademyInvitation.png

If you haven't received such an email: you need to let your professor know.

Once you complete setting up your account: you might want to bookmark this page, or even make it your home page: https://awsacademy.instructure.com

Browse around the interface. To do your work for OPS345 you only ever need to navigate to "Courses" > "AWS Academy Learner Lab - Foundation Services" > "Modules" > "Learner Lab - Foundational Services", which looks like this:

AWSAcademyLearnerLabHomeScreen.png

The links you'll use most often are highlighted in green:

  1. This is the amount of credits you have used out of your allocated 100$. Unlike the screenshot yours will start at zero.
  2. Most of your AWS resources are turned off unless your lab is started. Click this button to start the lab. There is only one lab for the entire OPS345 course, you will start it many times.
  3. The amount of time the current session of the lab has been running. After the 4 hours runs out the lab will be stopped and the associated resources will be shut down.
  4. Click here to get to the AWS web interface where you'll do most of your work.

Your work which you save inside your virtual machines is not deleted once the lab stops. AWS Academy simply shuts down your virtual machines. Your virtual machines and the rest of your Learner Lab resources will be deleted automatically at the end of OPS345.

The first time you start the lab it may take a few minutes, much longer than usual.

AWS cost monitoring

Normally using resources from AWS costs money. AWS costs are very competitive, but their resources are not free. In an AWS Academy Learner Lab you get a 100$ credit which will be more than enough to cover all your resources until the end of the course if you're not reckless.

Important.png
You are responsible for your AWS usage!
If you run out of credits: you will have to find another way to finance completing the required hands-on parts of OPS345.

Take this as an opportunity during OPS345 to learn what costs how much money in the cloud. The skills of managing cloud costs are very valuable. Unfortunately AWS Academy doesn't make it easy for you. On the unrestricted AWS you have access to AWS Budgets, Amazon CloudWatch Billing Alarms, and other tools to help you monitor and control your costs. But due to the way AWS Academy was designed: you won't have access to those tools. That's in return for the free 100$, which most students don't complain about.

Even without the budget restrictions in AWS Academy: AWS costs are not easy to manage. Here are some examples of what you'll run into:

  • Resources that say "Free" on the label, but will only be free in a specific configuration.
  • Resources that are free unless you exceed some threshold of usage (CPU usage, bandwidth, etc.)
  • Resources that cost money only when they are not used. That was not a typo.
  • And the most common of all: resources that don't have a cost listed next to them at all.

So in order to learn anything about costs on AWS: pay attention whenever you see a note about the cost of anything, even though it will be a distraction from what you're trying to accomplish at that time. There are many places where such notes are scattered. Always keep cost in the back of your mind when doing anything on AWS. Then hopefully you'll get a general idea, so that when you're done with OPS345 you can have an intelligent conversation about it.

Basic security on a public-facing server

Security is a topic most people aren't qualified to address. That's because it's complicated on its own, but in order to set it up properly: it also requires a solid understanding of the fundamentals of the systems which need to be secured.

That doesn't mean you can't learn it. As with most technologies, the recipe for success is simple. The more time you spend on it: the better you get. Every bit of learning you do related to security will make you more qualified. The more qualified you are to speak about security issues: the more valuable you are as a technician or engineer. Even if you're not directly responsible for security of a system: you will always have to work with security measures, and sometimes around them.

Idea.png
Your attitude matters
Usually if you follow the rules of the organization you work for: security breaches are somebody else's problem. But not always. For example if you get your AWS Academy account suspended by Amazon because your password was "123" - I won't feel bad for you, and you will have to find a way to complete the requirements of the course. And whether it's your problem or not: wouldn't you rather be a part of the solution?

So as with AWS costs there are some steps I can tell you to follow, but overall you should take some time to think of security whenever you do anything. Who has access to a specific machine? Network? Service? Storage device? Is it hard to steal/crack a password and impersonate one of your users? Is your system vulnerable to off-the-shelf attacks? Keep those questions in the back of your mind, and as a minimum follow the following guidelines:

  • Set a good password for your AWS account, and don't use that password for any resources inside AWS. Your AWS account password is like a super-root password. It gives you full access not only to a specific machine, but to all machines, networks, storage devices, and billing. You can end up running someone else's botnet, and paying for it too.
  • Possibly the most common attack on a Linux machine is the brute-force SSH login attack. It takes very little setup to mitigate almost all these attacks:
    • Delete all default usernames, except root which you can't delete.
    • Make sure that root is never allowed to log in remotely.
    • Whenever possible: don't use passwords at all, use SSH keys for logging in. You've learned how to use them in OPS245.
  • Learn how to use sudo and how to configure it.
  • Get in the habit of organising your SSH keys so you don't accidentally lose them.

Remember that unlike ULI101/OPS245 your servers are on the real internet, and depending on how you configure them: they might be accessible by any attacker on the planet. You need to pay much more attention to security in this course than was required in ULI101/OPS245.

First AWS VM

We're going to set up a virtual machine in AWS now so you can start to get used to the process. You'll be repeating this several times during the course, try to learn a little more about it each time you do it.

Security group ops345first

A security group is a fundamental concept in AWS. It's not completely clear what it is. The closest thing you would have seen that's similar is a set of iptables rules. You can assign the security group (this set of rules) to one or more virtual machines.

A security group with no rules does not allow any traffic to pass through.

  • Create a new security group "ops345first" with only the SSH port open to the world in the incoming rules. Familiarize yourself with the interface. You'll use this security group for your first VM you'll soon create.
AWSCreateSecurityGroup.png

Create ops435-first VM

In AWS language an instance is what you've called a virtual machine in OPS245. An AMI is a pre-built disk image of an operating system, provided so that you don't need to install an operating system from scratch. The AMIs are typically provided by Amazon or the AWS community.

An AMI is only the initial disk image your VM will start with. As soon as the VM is booted for the first time: your disk image will begin to deviate from the original. That means for example that you have to keep up with security updates on it even though the AMI you used had all the security updates installed when you used it to bootstrap your instance.

With an AWS Academy account you can see what AMIs are available on AWS, but your selection is severely limited. We'll only be using the Amazon Linux AMI. You'll find it quite familiar as it was originally based on CentOS.

  • To create a new virtual machine you need to go to "Instances" and click "Launch Instances". An unfortunate choice of words by Amazon. It sounds like that button should start an existing instance. It should have been called "Create Instance".

The first time you go through this process try to concentrate on not getting overwhelmed by the available options and the unintelligible AWS lingo. You'll have lots of opportunities to better understand the available options.

  • Select the "Amazon Linux 2 AMI (HVM), SSD" AMI.
  • Don't use the "Review and Launch" button instead go through each of the 7 steps.
  • Leave the t2.micro default checked and click Next.
  • Leave all the defaults under Instance Details.
  • Don't change the storage configuration under Add Storage
  • Don't add any tags under Add Tags.
  • At the Configure Security Group step: select the security group "ops345first" which you just created.

After you review your configuration and click "Launch" a popup will come up asking you for a key pair. It's important for you to understand what it's asking for. It is the same type of SSH key pair that you've created and used in the OPS245 Lab 7. Remember that your private key is yours, it's private to you, and not for anyone else to see. AWS is asking you to give them the public key which is the pair of the private key which you wish to use to log in to your new VM. In this case your private key is the effective equivalent of the root password.

  • Create a new RSA key pair named ops345-first-key, and download it as ops345-first-key.pem on your workstation under a new directory ~/ops345/keys/ssh/

Yes, that means AWS generated your private key and theoreticaly they could keep it, but they promise that they don't and that's almost certainly true. Once you donwload the private key and click "Launch Instances" - the only way to log into your new virtual machine is using the private key you saved. AWS does not provide the equivalent option of "reset your password" for instances that were already created.

AWSFirstInstanceCreated.png
  • After your instance is created: you will see it listed under "Instances". Set its name to "ops435-first". Get used to naming things in AWS because otherwise you'll have a hard time distinguishing your instances from each other, unless you're unusually good at remembering long random strings of characters.

Explore your new VM

You're not going to find a button in the AWS to "view the screen" of your virtual machine. The only way to control it is via an SSH connection.

Look at your ops435-first instance details and find its automatically-assigned public IP address. Connect to it with SSH. Note that you need to user your private key to connect, and since it doesn't have a default name nor is it in the default location for SSH keys: you need to specify the path to it manually.

The default username on Amazon Linux is ec2-user.

AWSFirstSSH.png

You have at least one semester's worth of experience of CentOS, so look around to see if anything looks different from what you're used to. For example:

  • Many packages not installed by default in the Minimal installation of CentOS (e.g. net-tools) are installed by default in Amazon Linux. I like to also install telnet and nmap.
    • Note that Amazon Linux has its own package repositories: /etc/yum.repos.d/, but the yum/rpm commands work the same as in CentOS.
  • The systemctl command to control your services works the same way as in CentOS.
  • Note neither iptables nor any other firewall is installed by default. It is in CentOS.
  • You user information files (/etc/passwd, /etc/shadow, /etc/group) are used in a completely standard way.
  • Have a look at the output of netstat -atnp and netstat -aunp to see what ports services are listening on in a default installation.

It's not completely clear what Amazon's policies are for supporting Amazon Linux. From people's experience it appears to be quite stable, but as a rolling release you might not want to depend on it for production use. For our learning purposes it's plenty stable and consistent. One nice thing about Amazon Linux is that it is not linked to RedHat/IBM support cycles and policies which have changed significantly after IBM's acquisition of RedHat.

Change the default username

For security purposes we're going to remove the default ec2-user. That would be simple if you were sitting in front of the machine, but since you can only connect to it via SSH and the only user you can SSH as is ec2-user: it takes some extra work. You're going to do this for every machine you create in OPS345, so get used to the steps. It's good practice:

  • Use the useradd command to create a new user. To make your life easier: set the username to be the same as your myseneca username, with the same capitalization.

You do not need to set a password for this user. Passwords can be guessed using a brute-force attack. SSH keys are practically immune to such attacks.

  • Make sure your new user can run sudo without a password, same as ec2-user. Create /etc/sudoers.d/10-ops345-users with these contents:
yoursenecaid ALL=(ALL) NOPASSWD:ALL
  • Allow your new user to log in using the SSH key you already have. You could create a new key pair instead, but you don't have to. Remember that your username is not asmith15:
AWSCopySSHKey.png
  • Confirm ssh into your VM as yoursenecaid and successfully sudo su -
  • After you're sure that you can: delete ec2-user including the home directory. Use the userdel command.

Set the hostname

For reasons that are hard to explain quickly the hostname on your AWS VM is not static by default, but we'll make it static so it's more familiar to you.

  • Update the hostname to first.yoursenecaid.ops345.ca and make sure it doesn't get reset when your VM reboots. Follow the relevant parts in https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-hostname.html
  • Also change the instance "Name" in the EC2 management console to "first". This is not necessarily the same as the hostname. It's the equivalent of the VM's name you've used in Vmware in OPS245.
AWSSetHostname.png

Submit evidence of your work

For this lab, please submit screenshots that show you've completed the work, unless your professor has given you different instructions.