While there are many cloud providers (e.g.: AWS, Microsoft Azure, DigitalOcean, etc.), today we are going to use Google Cloud. By signing up here with your university email (${YOUR_ID}@stud.acs.upb.ro most likely), you will get $50 in credits to play around with their infrastructure up until the 10^th of April. In case you aren't forwarding your UPB emails to/from your main account via IMAP/POP, you can access them in outlook.

Normally, cloud provides give you the option to access a web dashboard. Using this is fine for starting up one virtual machine, or checking your billing settings. However, if you want to do some automation work, you will want to utilize the gcloud SDK. By following the instructions here, you should be able to install the gcloud CLI application. If the steps for Ubuntu don't work (very likely on WSL), try the more generic approach for Linux (i.e.: download a .tar.gz and run the install script). Remember: Ubuntu is a Linux distribution! Finally, you will be asked to run:

# create default configuration for usage with gcloud
$ gcloud init

CLI tools like ip and gcloud work based on a more modern paradigm. If older programs mainly use flags (i.e.: --this, -t) to specify what functionality should be invoked at runtime, these use commands and subcommands for a more intuitive classification. For example:

# <tool_name> <subject> <action>
$ gcloud projects list              
PROJECT_ID      NAME            PROJECT_NUMBER
lab-radumantu   lab-radumantu   1234567890

$ gcloud compute networks <TAB>
create                   get-effective-firewalls  subnets                                         
delete                   list                     update                                          
describe                 peerings                 vpc-access 

Note that sometimes, the feature that you want to access is in fact hidden behind the alpha or beta commands. These commands indicate that the development version of regular commands should be used in stead.

# try to list your configured billing accounts
$ gcloud billing accounts list
ERROR: (gcloud.billing) Invalid choice: 'accounts'.
This command is available in one or more alternate release tracks.  Try:
  gcloud alpha billing accounts
  gcloud beta billing accounts
 
# now try the same thing with the alpha variant of the command
$ gcloud alpha billing accounts list
ACCOUNT_ID            NAME                           OPEN   MASTER_ACCOUNT_ID
XXXXXX-XXXXXX-XXXXXX  Billing Account for Education  True

Now knowing your project ID and your billing account ID, it's time to link the two. This way, when you request resource allocation from the gcloud compute engine, Google will know to use the $50 credit account (charges are usually made at the end of the month). While there's also an alpha version of the following command, we'll be using the recommended beta variant:

# link billing account to gcloud project
$ gcloud beta billing projects link ${PROJECT_ID} --billing-account ${BILLING_ACC_ID}

Before we proceed to actually starting instances in different locations, here's one final config that we should do.

# set default project id
$ gcloud config set core/project ${PROJECT_ID}
 
# check that new value was saved
$ gcloud config list
[core]
...
project = ${PROJECT_ID}

Setting the core/project propriety is optional. However, not setting it would have meant that every time you invoked a gcloud compute command, you would have been required to also pass a --project=${PROJECT_ID} flag. Which is annoying…

In this exercise, we will instantiate a virtual machine using the gcloud compute engine. This may not be as straightforward as you expect. The reason for this is that there are many aspects to consider. For example, in what datacenter do we want our instance to reside. Do we want a public IP address assigned to it? Looking at the gcloud compute instances create command, it may first appear intimidating. Let's take it step-by-step and discover what we need to create a VM. With each step, make sure to write down the parameters that you'll need later.

Google Cloud offers a number of services, none of which are enabled by default. One of them is the compute service (i.e.: compute.googleapis.com) that lets us create VM instances. When running a command that requires a certain service that was not previously enabled, you get a prompt asking you if you want to enable it then and there. In this case, we'll do it manually. Note that this may take a bit of time, up to a couple of minutes.

# get full list of available services
$ gcloud services list --available
 
# enable the compute service
$ gcloud services enable compute.googleapis.com

Once your VM is up and running (at Task G), you will want to be able to SSH into it. For this to happen, you will have to configure a public SSH key. This key will be automatically copied into ~/.ssh/authorized_keys at creation. If you still don't have a SSH keypair generated, now's a good a time as any (see ssh-keygen).

# upload your public SSH key to gcloud
# --ttl 0 means that the key does not have an expiration date
$ gcloud compute os-login ssh-keys add --ttl 0 --key-file ~/.ssh/id_rsa.pub

First things first. What OS do we want to run on our machine? A Windows server? Maybe CentOS? Nay – let's look for something familiar, namely Ubuntu. Make sure to take note of the PROJECT and FAMILY columns:

# list available base VM images
$ gcloud compute images list

All cloud providers worth their salt will offer you a number of physical locations (datacenters) where to deploy your instance. Locality is very important when offering web services. Normally, this is a difficult task. Can you imagine YouTube running on a single server somewhere in the US and you accessing it from SEA? Many people use Content Delivery Networks (CDN) for this task. Even DigitalOcean, a rather important cloud provider uses CloudFlare as a proxy for their HTTP servers.

You can read up on Google's regions and zones. When working with your own funds and not with free tier accounts or education credits, you will want to consult their regional pricing model. Usually, US-based datacenters are much cheaper.

# show available regions
$ gcloud compute regions list
 
# show zones in selected region
$ gcloud compute zones list --filter ${REGION}

When selecting the number of Virtual CPUs (vCPU) and RAM for your VM, you will have to choose from a list of presets. These presets may vary depending on the region.

# show available flavors for your selected zone
$ gcloud compute machine-types list --zones "${YOUR_ZONE}"

Storage options refer to HDDs/SSDs and can be separated from the instance you create. Meaning that you can delete the instance and still keep your storage image intact, in case you may want to mount it to another instance in the future (think moving a USB stick between PCs). For this exercise, we won't dive into this specific use-case and delete the virtual storage device together with the instance (at the end of the lab). A 10G disk should be more than sufficient. Again, the storage device selection is specific to each zone.

# select storage type for selected zone
$ gcloud compute disk-types list --zones "${YOUR_ZONE}"

Finally, it's time to start up our VM. In addition to all the parameters that you've selected until now, you will also have to give the instance a name.

# create the instance
$ gcloud compute instances create ${INSTANCE_NAME} \
        --image-family   ${IMAGE_FAMILY}           \
        --image-project  ${IMAGE_PROJECT}          \
        --zone           ${ZONE}                   \
        --machine-type   ${FLAVOR}                 \
        --boot-disk-type ${DISK_TYPE}              \
        --boot-disk-size ${DISK_SIZE}              \
        --metadata enable-oslogin=TRUE
 
# show active instances
$ gcloud compute instances list

Using the username that was generated for you (see Task B) and the Public (External) IP address of your VM, connect to it via SSH. The Ubuntu image comes with a pre-configured SSH server. But remember that after you created the instance, it still requires ~1m to boot and start up the services.

# connect to your instance
$ ssh ${USERNAME}@${PUBLIC_IP}

Google Cloud implements a software firewall with a few default rules that allow, for example, incoming SSH connections. If you want to run a server on your VM and contact it from a public network, you will need to add a new rule, whitelisting it.

Without getting into too much detail regarding networking stuff, IP addresses represent a network interface on your machine. In contrast to an IP address, a port does not have a hardware correspondent. It's a 16-bit number that represents an endpoint on your machine. This endpoint can be used by a single process at a time to either listen for incoming connections or establish outgoing connections. Some port numbers have consecrated meanings (e.g.: 22 - SSH, 80 - HTTP, 443 - HTTPS) and are reserved for servers. Why servers and not clients? Because the clients initiate connections and need to know where to find the servers. The servers don't care what port the clients are running on; anything will do. Port numbers are split into three categories:

• 0 - 1023 : system / well-known ports – don't fuck with these!
• 1024 - 49151 : reserved ports – usually used for servers of any kind
• 49152 - 65535 : ephemeral ports – used for dynamic connections

Next, we want to start a netcat server on the gcloud instance and send a text message from our localhost. The netcat server will run on port 8989, so we want to whitelist it. The tcp part in the commands below refers to the TCP protocol. You don't need to understand what protocols are. These will be covered in the 3^rd year Local Networks course. For the sake of this task, mentioning it is unavoidable. If you want to know more, ask your assistant.

# display current firewall rules
[localhost]$ gcloud compute firewall-rules list
 
# add a new firewall rule
[localhost]$ gcloud compute firewall-rules create ${SOME_RULE_NAME} --allow tcp:8989
 
# start a netcat server in listening mode (-l)
[gcloud]$ nc -l 8989
 
# send some data to the server
[localhost]$ echo "Hello world!" | nc ${PUBLIC_IP} 8989

Loosely speaking, there are two types of IP addresses:

• Public: what your Google Cloud instance has, and what allows you to contact it from anywhere over the Internet.
• Private: what your router allocates to your devices (laptop, phone, etc.) in your local network.

Public addresses can be uniquely identified in the Internet. Private addresses can't. Why not, you ask? Well… can you find the IP address assigned to your machine's network interface? Hint: ip addr show. That exact IP address is shared by millions of other devices, all across the world, in their respective local networks. When you initiate connections from your private network, the router performs a process called Network Address Translation (NAT) which uses a single Public IP to represent multiple Private IPs. Unless you have administrative access to said router (too add some custom configurations), clients outside your network will be unable to initiate contact with individual machines inside your network. And most times you don't…

In this exercise, we will set up what is called a reverse SSH tunnel. This tunnel is a persistent two-way communication channel between your computer and the gcloud instance. While this connection is initiated by you (from your private network, to a public server), someone on the other side can piggy back on this channel to initiate connections with you, in your private network. The reason for this is that it doesn't target your IP, specifically, in its request. In stead, it sends its request into the gcloud endpoint of the channel and it just so happens that the other endpoint is located on your machine.

To be more specific, the scenario is as follows:

1. You create a SSH channel from your machine to the google cloud instance
2. Then, you connect to fep.grid.pub.ro. SSH-ing from fep back to your computer should be impossible. Imagine your fep instance being you on vacation, trying to access your home computer.
3. To sidestep this problem, you will SSH from fep to your Google Cloud instance, and from Google Cloud to your localhost via the SSH channel.

# create a public keypair on fep, if you don't already have one
 
# create the .ssh directory (if not already there)
[gcloud]$ mkdir -p ~/.ssh
 
# print out your fep.grid.pub.ro public key and copy it
[fep]$ cat ~/.ssh/id_rsa.pub
 
# configure your fep.grid.pub.ro public key on gcloud instance
[gcloud]$ vim ~/.ssh/authorized_keys
 
# install a ssh server on your computer
[localhost]$ sudo apt install openssh-server
 
# check if the ssh server is running; if not, start it
[localhost]$ systemctl status sshd
[localhost]$ sudo systemctl start sshd

And now for the main part:

# create a reverse ssh tunnel from your computer to the cloud instance
[localhost]$ ssh -T -N -R 43210:localhost:22 ${GCLOUD_USERNAME}@${GCLOUD_IP}
 
# show tcp listeners (bound ports, processes, etc.)
[gcloud]$ netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:43210         0.0.0.0:*               LISTEN      1931/sshd: ........ 
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      448/systemd-resolve 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      893/sshd: /usr/sbin
 
# test that the reverse ssh tunnel works
[gcloud]$ ssh ${LOCALHOST_USERNAME}@localhost -p 43210
 
# connect from fep.grid.pub.ro to your localhost via gcloud instance
[fep]$ ssh -J ${GCLOUD_USERNAME}@${GCLOUD_IP} ${LOCALHOST_USERNAME}@localhost -p 43210

Let's take a look at some of the arguments used in these commands:

• ssh -T -N -R 43210:localhost:22 …
  • -T: do not start a shell on the remote computer (we're not using the connection for that, remember?)
  • -N: do not execute one-shot commands either (combined with -T, this makes ssh do nothing)
  • -R 43210:localhost:22: when logged in on the gcloud instance, writing data to port 43210 with itself (i.e.: localhost) intended as the destination, will ensure that the data actually ends up on whoever initiated the tunnel, on port 22 (the SSH server port).
• netstat -tlpn
  • t: filter for TCP protocol (SSH actually runs over TCP)
  • l: show ports where processes are listening for new connections
  • p: show the PID and name of the program that is listening
  • n: use numeric IP addresses in the output
• ssh -J ${GCLOUD_USERNAME}@${GCLOUD_IP} ${LOCALHOST_USERNAME}@localhost -p 43210
  • -J ${GCLOUD_USERNAME}@${GCLOUD_IP}: create a SSH connection with google cloud as an intermediary hop; it acts like you'd SSH to google cloud, and there you would write another SSH command to your final destination.
  • ${LOCALHOST_USERNAME}@localhost: “localhost” here is relative to the jump point (i.e.: google cloud instance), not to fep.
  • -p 43210: in stead of using the default SSH server port 22, pretend that it's in fact running on 43210.

Regarding the output from netstat:

• 127.0.0.1:43210: on port 43210 there is a process listening for connections towards IP 127.0.0.1. This is synonymous with localhost, denoting a loopback interface. In other words, this IP always refers to the current machine.
• 127.0.0.53:53: this IP also corresponds to a loopback interface. The process listening on port 53 for connections to 127.0.0.53 is a DNS caching server that comes pre-installed on Ubuntu. This is not relevant for this exercise.
• 0.0.0.0:22: on port 22, there is a SSH server called sshd, listening for incoming connection requests. The 0.0.0.0 IP signifies a catch-all. In other words, it doesn't matter if the request's destination IP is that of your Ethernet interface, or your WiFi interface, or your loopback interface (127.0.0.*). This server will take on all of them.

Reiterating over the last command, since it might still be a bit unclear:

• You are on fep.grid.pub.ro and you SSH to the Google Cloud instance (the -J part)
• Once on the Google Cloud instance, it may appear that you're trying to do something utterly insane: you are trying to log in via SSH with your personal computer's username, on the very same Google Cloud instance (that's your localhost at that moment in time), using a SSH server that doesn't run on port 22 (like a normal SSH server) but on port 43210…
• When you initiate that connection you realize that localhost:43210 is in fact a… wormhole. localhost is not in fact the Google Cloud instance, but your personal computer. Port 43210 is not in fact port 43210, but port 22. But you already know that, didn't you?

Since we're done with the VM, we might as well terminate it. Unless we want it to keep running and eating up our funds, needlessly.

# terminate instance and delete attached disks
$ gcloud compute instances delete ${INSTANCE_NAME} \
        --zone ${ZONE}                             \
        --delete-disks all

Please take a minute to fill in the feedback form for this lab.