Foundations - Setting Up Networks and Servers

Introduction:

This lab is intended for beginners - those who want to acquire initial knowledge and experience in operating Google’s cloud environment.

The lab is intended for those who already have at least a basic Help-Desk level of knowledge in operating computers and servers, IP addresses and network structure.

To start this lab, you need to register for at least a trial period in the GCP cloud environment. GCP allows people a 3-month trial period for learning and experimentation, during which they receive $300 in their account, which they can use to build a cloud environment with various components - without worry about budget overruns and unexpected bills.

Some things will not be available to the learner - such as Windows servers, for example, which involve Microsoft license payments. But every time an attempt is made to perform such an operation, a message will pop up to the user indicating that this operation is blocked in trial mode, and to enable such operations, billing needs to be enabled.

As long as the user doesn’t enable billing, they can work without worry until the end of the period or until they exhaust those $300 allocated for the trial period.

In this lab you can acquire knowledge and practice the following topics:

1. Creating a project in the GCP environment.

2. Creating internal communication networks in the cloud environment.

3. Sharing and routing between networks.

4. Firewall rules.

5. Setting up servers and editing server settings.

6. Connecting to systems and SSH keys.

7. Creating an Image of a machine with certain properties.

8. Creating machines from that Image.

Creating Projects:

In the GCP management panel, next to where it says Google Cloud (top left), there is a dropdown menu button that selects which project the user is in. Clicking it opens a window where you select “NEW PROJECT” in the upper right corner. Choose a name, then add the number 1. For example - yos-project-1.

Create a second project with the number 2.

Creating a VPC:

Select project number 1.

In the side menu (if not visible, click the three lines to the left of Google Cloud) click VPC network. You’ll see there is a Default network. Enter it and click delete at the top.

Then on the page that opens, click CREATE VPC NETWORK at the top.

Create 3 VPCs - VPC-1, VPC-2, VPC-3.

Within each VPC, create a Subnet in custom mode - not automatic (Custom, not Auto-mode). At the end we’ll have 3 Subnets - one Subnet in each VPC. These will be Subnet-1, Subnet-2 and Subnet-3, with ranges 10.0.10.0, 10.0.20.0, 10.0.30.0. All with Prefix 24. Enable Private Google Access for all of them.

For demonstration purposes I’m placing all of them in Israel, Region me-west1.

Delete the Default VPC in the second project as well.

Creating Sharing and Routing Between Networks - Mesh Configuration:

Still in the VPC network menu, select VPC network peering. Click CREATE CONNECTION there.

Alternatively, in the same menu go to VPC networks, select vpc-1, and inside there in the lower third of the window is a tab menu. The second tab from the right is VPC NETWORK PEERING. There you can click ADD PEERING.

In the window that opens, give the sharing a name - say, vpc1-to-vpc2.

Select the sharing network - vpc-1.

Verify that it’s marked that the receiving network is in the first project.

Select the vpc-2 network as the one receiving the sharing.

Mark import and export of Custom routes.

Then click Create.

You’ll immediately move to the window showing the sharing, but it’s in Inactive status - because you need to share back from the vpc-2 network. Only then will the sharing become active - it takes two to tango.

So perform the same operation in reverse - sharing vpc-2 network to vpc-1. Once the operation completes, the sharing will become active on both networks.

This double operation can also be performed between vpc-1 and vpc-3, and between vpc-2 and vpc-3. So we have a Mesh structure where all networks share connections and routing.

Important to remember:

Working in a Mesh configuration in a live organization is far more complex. In an environment with dozens of networks, connecting every new network to dozens of existing ones, and then every existing network to the new one, is a complex operation.

Moreover, GCP’s default is up to 25 Peering Connections per single VPC.

What’s typically done is dividing each VPC into many Subnets. This provides internal routing at the VPC level.

If many VPCs must be connected, it’s done in a star topology (in one of the following labs).

If insisting on Mesh, the Peering can be done each time using a script (in one of the following labs).

Creating the First Machine:

Go to the left menu (three lines) and select Compute Engine, then go to VM instances and click CREATE INSTANCE at the top.

Give the machine the name instance-1. Select the Tel Aviv region - me-west1, zone me-west1-a.

Now let’s pause a bit on machine settings - Machine configuration:

There are four families, with the default being General purpose, which takes a relative balance between processing power and memory. There are also families where the ratio of processors to memory is higher or lower, and ones that need GPUs.

Within each family there are different types, relating to the types and configuration of processors and memory. There are cheaper types for standard use, and other types in cases where better performance is needed in a certain area.

We’ll leave the machine type at its default - this will be from the E2 series, and select type e2-micro.

Scroll down a bit until you find the Boot disk settings.

For the operating system and disk, leave at default. A Debian server with a 10GB disk is sufficient for what’s needed.

• Note that based on the machine type, operating system and disk size selected, on the right side there is a summary of the machine’s cost.

Always account for costs when choosing machine settings!

Mark allow http traffic.

Scroll down to Advanced Options and open Networking.

Scrolling down a bit more, you see Network interfaces. Clicking the arrow that opens the row there (which probably says vpc-1), you see that you can choose which network and which subnet to place the machine in.

Place it in VPC-1 within Subnet-1, and then under primary internal ipv4 address you’ll see the default is Ephemeral (Automatic) - meaning an address received from the Subnet’s DHCP. We want to set an address of our choosing.

Click the small arrow there, and you’ll see an option of Ephemeral (Custom). Selecting it opens a row where you can write the address you choose - 10.0.10.10.

Leave the external address as is, and mark Network Service Tier - Standard below.

Then click Create.

Try to connect via SSH through the console button:

• Can’t connect via SSH because there are no firewall rules allowing it.

Creating Firewall Rules:

By default, a VPC Firewall blocks all incoming traffic and allows all outgoing traffic. To be able to reach any machine in a VPC, we need to create Firewall rules that allow that type of traffic.

To start, we want to allow SSH connection to the machine. Since a machine created from a GCP Image only receives SSH connections authenticated via asymmetric keys, we want to connect initially through the management console which inserts such keys itself and connects the user automatically.

This connection method doesn’t come from the computer you’re browsing from, but through the console, via GCP’s servers. Therefore the traffic comes from the address range 35.235.240.0/20.

Return to the VPC networks menu and go to Firewall there.

You’ll see there is one rule - vpc-1-allow-http. The rule allows traffic entering the network from range 0.0.0.0/0 (which means all addresses) on port 80. This is opened when wanting to allow access to a Web service from anywhere in the world. If not from everywhere, instead of 0.0.0.0/0 you define a specific range appropriate for what’s needed.

• Important to remember - in Firewall, only open what’s needed, and exactly what’s needed. The more unnecessary ports are opened from more places, the more opportunities an attacker has to access our addresses.

At the top of the page is a CREATE FIREWALL RULE button. Click it to create a new rule.

Give it the name - build-in-ssh.

Set the network - VPC-1.

Traffic direction - Ingress. Meaning - incoming traffic. And the action to apply in this rule - Allow.

Then there are Targets. We can allow this traffic to all addresses in the network, to targets bearing a certain tag, or for a certain service account.

We’ll select by tag, and the tag will be - external.

Now choose how to filter the traffic source. We’ll filter by IPv4 address range and write the range 35.235.240.0/20, from which the console’s built-in SSH connections come.

At the bottom when choosing which protocols or ports to open, select Specified protocols and ports, and mark TCP port 22.

Now click CREATE and the rule is created.

Associating a Machine with a Firewall Rule:

Now we need to return to Compute Engine, go to VM Instances and enter instance-1. Click EDIT at the top, and when the edit window opens, scroll down to the Networking area. Under the network card settings is Network tags. Note that because Allow HTTP traffic is marked, there’s already an http-server tag.

Place the cursor to the right of the tag, in the row, and type external - as we wrote earlier in the SSH rule. Click SAVE at the bottom.

After saving completes, it returns to the machine window. Now clicking SSH at the top succeeds in connecting.

And if I want to connect to the machine through Putty from my own computer? - We need to add another Firewall rule, allowing connection from the private computer to instance-1.

Repeat the rule creation process in Firewall as before, with one difference. Instead of the source filter given earlier with the address range from which Google sends its console SSH connections, put the external address from which we’re browsing.

This can be obtained by searching for Whatismyip in Google.

Now there is an additional rule allowing traffic on port 22 from our external address to the machine bearing the external tag.

But that’s still not enough to connect from the home computer via Putty.

Configuring the Server Template:

Upon connecting to the server through the console, we see we’re connected with the user we’re connected to the console with - the Google user. Now we want to create a local administrative user, so we can connect with it outside the console and perform operations.

In the SSH terminal window, perform the following operations:

Connect to instance-1 using the SSH button in the GCP management panel.

Switch to admin mode using the command:

 sudo -i

Add a user using the command:

 add user <username>

(Replace '' with the user you want to use.)

Set a strong password and save it aside.

No need to fill in the name and all the other details afterwards.

Then edit the SSH server settings inside the machine using the command:

nano /etc/ssh/sshd_config

Scroll down until you see a line that says PasswordAuthentication no.

Change to yes.

Exit and save (ctrl + x then y). Then restart the SSH service to work with the new setting using the following command:

systemctl restart sshd

Now the machine can be connected to via Putty through its external address, with the user and password created earlier.

Connecting via Putty:

Open a Putty window and connect to the external address of Instance-1. After connecting, nginx can be installed using the command:

sudo apt install nginx -y

Also, we want to install telnet for communication testing later:

apt install telnet

Doesn’t work? Need to add sudo before the command, or connect as the root user (Linux’s admin user) using the command sudo -i.

Open a new browser tab and enter the address of the new Nginx website just created:

http://instance-1-external-ip

Of course, everything after the slashes needs to be deleted and replaced with the machine’s actual external IP address.

When connecting to the Web server by entering the machine’s external IP address in the browser, you receive the basic page with the heading “Welcome to Nginx!”.

Then return to the console and edit the machine’s details.

Editing Machine Details:

In the console, in Compute Engine, go to VM Instances, and click on machine instance-1 to enter its page.

Click EDIT at the top, then scroll down, almost to the end - in the Management area there is an Automation section with a text box for Startup script. These are terminal commands activated by the machine’s system account when it starts up after power-on/restart.

Add the following command there:

sed -i "14s/nginx/$HOSTNAME/g" /var/www/html/index.nginx-debian.html

Then save the changes to the machine.

This command edits line 14 of the basic HTML page of the Web server installed with Nginx.

When the command runs, anyone connecting in a browser to the machine’s address will see in the page title, instead of the word Nginx, the server’s name.

Of course, everything is very basic. We’ve only set up a Web server, and have no interest in putting some elaborate website or application there. Knowing which server we’ve reached will serve us in the following labs.

For now, restart the machine, wait for it to come back up, then reconnect in the browser to its Web server.

You can see that now the page shows all the previous text, but under the heading:

“Welcome to instance-1!”

Creating an Image:

Still in the Instance-1 window, click “CREATE MACHINE IMAGE” at the top.

On the page that opens, give the name - basic-nginx.

The source machine is of course - instance-1.

Mark Regional and select the Tel Aviv region - me-west1.

Then click CREATE.

Note that if we were previously on instance-1’s page from VM instances, we’re now in Machine images.

This shouldn’t take long. It’s possible the status indicator in the machine’s row is still spinning. But if the notifications area (top left between the help question mark and the terminal icon) no longer has a spinning circle around the bell, simply click REFRESH at the top and you’ll immediately see the status turned green.

• This exact same operation of creating a Machine Image can be performed from within the Machine images page in the Compute Engine menu, just as it can be performed from within the page of a specific machine in the VM instances page.

A frozen template of the server has now been created in the state instance-1 was in when we created the Image from it - including the installed nginx server, and the same username and password that allow connecting via Putty.

Creating Machines from an Image:

Click on the Image we just created, which takes us to a page with the machine’s details.

Click CREATE INSTANCE at the top - a page opens for creating a machine based on that Image.

Note the left menu - this is the machine creation menu with 4 options. We could have gotten there from VM instances if we clicked create machine. Then we could have moved to the New VM instance from machine image option.

Choose a name for the new machine - let’s call it instance-2.

Also place it in the Tel Aviv region, the same Zone - zone-a.

• Note that in terms of pricing and costs in the GCP environment, there are no costs for traffic in the same Zone within your network, but there are costs for traffic between different Zones, and of course between different Regions.

Now scroll down and edit the network settings:

Remove the external tag.

Scroll down a little and edit the network card under Network interfaces. There is the existing network card with a small arrow that when clicked opens the options for editing.

Change the network to vpc-2, then to subnet-2.

Then change the IPv4 address from Ephemeral (Automatic) to Ephemeral (Custom). A new row will open where you enter the address you choose - but it must be within the range of the subnet selected above.

Choose address 10.0.20.12.

In the external address field, change to None. This machine doesn’t need an external address.

Scroll down more to Management and add the command to the Startup script:

sed -i "14s/nginx/$HOSTNAME/g" /var/www/html/index.nginx-debian.html

Then click CREATE.

Immediately create two more machines exactly like instance-2. Call them instance-3 and instance-4, place them in the same region but in Zone-b and Zone-c, in the same network and the same subnet, with addresses 10.0.20.13, 10.0.20.14.

Creating a Firewall Policy:

Return to the Putty window of instance-1 (if none, open and connect again), and after connecting to the machine, ping one of the new machines - say, ping 10.0.20.12. No ping.

Perform a telnet on port 80 to the same machine:

telnet 10.0.20.12 80

It immediately tells us it’s connected. Now we can exit using ctrl + ] and then q.

• Note! Unlike other Linux versions, here (Debian server) the command is written as in Windows - with a space between the IP address and the port. Space - not a colon!

Why did telnet on port 80 work but ping didn’t?

Return to the VPC network menu and go to Firewall there.

You’ll see a list of 4 rules. Note the columns - there’s a Network column that tells us which VPC each rule belongs to.

So we have three rules for vpc-1 - two rules we created for SSH and another rule born when instance-1 was created and the allow HTTP traffic box was checked.

And there’s another such rule for HTTP belonging to vpc-2. This rule was created when instance-2 was born from instance-1’s template. As we said - in instance-1 this option was checked, so it also passes to machines created from the same template.

That’s why telnet worked on port 80 - because vpc-2 allows entry on port 80 from any address. But there’s no rule allowing ping, so ping didn’t pass.

Apart from ping, there are other things we want to allow on the internal network we created here via peering. It would be a shame to have to create the same rules again for every vpc. For this purpose there is a Firewall Policy.

Creating the Profile:

At the top of the page click CREATE FIREWALL POLICY.

On the page that opens give the name general.

Mark Regional for the Tel Aviv region and click CREATE.

This takes us to the Firewall page. Individual rules are at the top, and Policies are at the bottom. So we scroll down to Network firewall policies and click general to enter and edit this policy.

We’ve entered the policy and see there are already some rules there. Let’s go through the columns again to understand the structure:

Priority

The higher the number, the lower the rule’s priority. A rule with a lower Priority number applies before a rule with a higher number. If there is a match to the source and target in a rule that applies first, the rule with later priority won’t take effect.

Direction of traffic

Shows whether the rule applies to incoming or outgoing traffic. Ingress is traffic entering the network (or machine), and Egress is traffic leaving a network Gateway, or a machine.

• In Firewall policy this is called Direction of traffic. But if we return to the main page, in rules it’s simply called Type.

Targets

Determines who the rule applies to. Whether to all machines in the network, or only those with a certain tag, or those running on a certain Service Account.

Source

This is the part of the rule that determines what traffic it applies to. The rule will only apply to traffic coming from an address or address range set as Source. For example - if 10.10.10.1 is written as Source, the rule doesn’t apply to traffic coming from a machine with address 10.10.10.2. If 10.10.10.0/24 is written as Source, this applies to all traffic coming from the 10.10.10.0 network - including traffic from the address 10.10.10.2 mentioned above. But won’t include traffic coming from address 10.10.20.2 for example.

Destination

This is the part of the rule that filters applicability by destination - the rule will only apply if the traffic is destined for an address that is in Destination, either as a single address or included in the range (or ranges) defined as Destination.

Protocols and ports

The rule will only apply to protocols and ports listed here. If TCP port 22 is defined here, the rule doesn’t apply to RDP which runs on TCP port 3389. Even if the traffic on that port comes from the same address defined as Source and arrives at the same address defined as Destination. For the rule to apply, all conditions and settings must be met and match.

Action

The rule’s action.

This setting determines whether the rule will allow this traffic to pass, or block it. There is also a third, neutral option - Go to next. This option says - do nothing. Every time there is a connection, the connection goes through all the firewall rules in order. In a traditional firewall this is top to bottom, here in GCP it’s by Priority. If rule 1 matches, it will apply to the traffic and all subsequent rules are not relevant. If rule 1 doesn’t match in terms of source/destination/port filters, it moves to the next rules. Once a rule applies, everything after it is not relevant.

So essentially, Go to next says that even if the connection matches all the filtering criteria, move to the next rules in line, and look for a match there - and an action resulting from that match.

We’ll create a new rule in the Policy.

Directly above the rule list, aligned to the left, is a CREATE button. Clicking it opens a rule creation page.

Give the rule a Priority of 1000.

Traffic direction - Ingress. Meaning - incoming traffic.

Action - Allow.

Logs - enable.

Target - leave default - all addresses in the network.

Source - give it the range 10.0.0.0/16. This means only traffic coming from internal addresses starting with 10.0. All the networks we’ve created are already in this range, and this will suit them.

• Multiple different ranges can be entered as Source. Simply enter a range, press space and you’ll see the first range is marked as a sort of tag. Then you can enter another range or address.

There are more advanced filtering settings we won’t choose - such as filtering by Geolocation, by address groups that can be set up in GCP, by certain DNS addresses, etc.

We’ll continue to select the destination address range the rule applies to.

Select IPv4 type with the range we chose earlier - 10.0.0.0/16.

For ports, choose to open ports 22 and 3389 in TCP protocol, which are the protocols used for SSH and RDP. Enter them separated by a comma like this: 22,3389. Also under Other, add the ICMP protocol - to allow ping.

Click CREATE.

A rule has been added to the policy that allows SSH, RDP, or ping communication between all machines in the internal networks we created.

Now we’ll add another rule that allows all machines to receive the GCP console’s built-in SSH.

Click CREATE again and on the page that opens:

Priority - 1001

Traffic direction - Ingress

Action - Allow

Logs - On

Target - Everything.

Source - the address range from which the console’s built-in SSH connections originate - 35.235.240.0/20.

Destination - select IPv4 type with the range of all our networks - 10.0.0.0/16.

Protocols and ports - select TCP 22.

Then CREATE.

Associating Networks with the Profile:

Just above the CREATE button that creates a new rule, there is FIREWALL RULES. Next to it is ASSOCIATIONS. This means until now we were in the part that defines the policy’s rules, and now we’ll move to the part that determines where the policy is linked and who it applies to. Click ASSOCIATIONS.

The list is empty.

Click ADD ASSOCIATION, and a side panel pops up where you can choose which VPC from those in our project we want to associate with the policy.

• Important to remember that at a large scale, when working with an Organization, it’s possible to create a policy that applies to the entire Organization. Here we’re working at the project level, which is a lower and more granular level.

Select all three VPCs in the list and click ASSOCIATE.

Now, if we return to the Instance-1 terminal window and try to ping address 10.0.20.12 again, we’ll see there is a ping.

Creating an Additional Test Server:

Return to VM instances and click CREATE INSTANCE again.

Select the name instance-5.

Tel Aviv region, Zone - a.

Machine type e2-micro.

Now change the Boot disk settings. Click CHANGE there.

You’ll see a wide side panel for Boot disk pop up. It has several tabs allowing you to choose how to bring up the machine.

You can bring up a machine from a Boot disk Snapshot or from a Boot disk that was disconnected from another machine and is now waiting to be connected to a new machine. But what interests us are Images that exist at GCP - available operating systems you choose from which a new machine starts.

Here instead of Debian, select the third option from the bottom - Ubuntu. You can leave the default version - it doesn’t matter for the lab.

For Boot disk type you can choose from the following options:

• Standard - lowest performance level, this is an HDD disk.

• Balanced - a middle level between Standard and SSD.

• SSD - good performance level.

• Extreme - for machines requiring especially high-performance disks.

Balanced is sufficient for us now.

No need to change the disk size.

Click SELECT.

A good test would be the option to install a Windows server and try RDP connections from it, browsing to the pages of the servers we created and SSH connections to the servers we created. But creating a Windows machine will add the license price to the machine resources and storage cost.

While the price Google charges for using its resources is willing to be given free for experimentation, this doesn’t include payments for third-party vendor products - like Microsoft. Therefore such products are not available as Free Tier and are not allowed without enabling billing for Google usage charges in the settings.

• Always important to look at the calculation and know how much a machine will cost before creating.

On the machine creation settings page, continue a little further down, under Advanced options, Networking.

Place the machine in vpc-3 in subnet-3.

Give it an internal address in Ephemeral (Custom) format, and select address 10.0.30.15.

No external address.

Click CREATE.

SSH Connections:

SSH connection using an asymmetric key allows a connection format resistant to brute force attacks.

Creating a Key:

Return to instance-1. There, enter the following command:

ssh-keygen -t rsa -f ~/.ssh/key-file-name -C username -b 2048

This command creates an asymmetric key - meaning a private key and a public key. The public key resides on the machine you want to connect to, and the private key is used to authenticate identity when coming to connect.

You can think of (in this case only) the public key as the lock, and the private key as the key.

When a user comes to connect to a machine and enters the private key - if the private key matches the public one, the machine opens to the user without needing a password. The key is the authentication means.

Note the command syntax:

The first part activates a key generator. Then there’s the -t flag, meaning Type - the encryption type by which we’ll create the key. Then there’s the -f flag, meaning File. Here we specify the path and filename where the key will be created and saved - in two files. The public key will bear the specified name with the .pub extension, and the private key will bear the specified name alone. So if we use this command as is without change, the file containing the private key will be called key-file-name and will sit in a hidden folder (in Linux, folders starting with a dot are hidden) named ssh, located in the home folder of the user who ran the command.

Then there’s capital C meaning Comment - a note or label attached to the key. We attach some username as a label. Finally there’s the -b flag meaning bits - how many bits in length to create the key. In our case - 2048.

So when creating a key - in a lab or in reality, it’s advisable to change the filename part (the path is fairly fine, especially if it’s the root’s home folder), and the username. Note that the username you set here will be the user with which you connect to machines in this way.

…So the command was entered after editing, and two files were created at the requested location - the private key and the public key.

Setting a Public Key for a Machine:

Now we want to allow ourselves to connect in this way to a specific machine, or perhaps even allow ourselves to connect to all machines in the project in this way.

To enable this, add the public key to a specific machine’s Metadata, or to the project’s Metadata.

First we need the key in the right format:

Here - on instance-1 where we created the key, enter the following command:

cat ~/.ssh/key-file-name.pub

All the content of the public key will appear in the terminal - including the encryption type and the Comment containing the username.

Copy everything and save it aside. Don’t omit anything.

Setting a key at the machine level:

Enter the machine’s page and click EDIT at the top to edit the machine’s settings.

Right after the disk settings is Security and access. There is a small heading - SSH Keys.

You can mark there to block keys defined at the project level, so that only a key defined for that specific machine can be used to connect.

If not marked, it simply doesn’t conflict. You can add a key there that will be specific to the machine, and equally you can use the key defined at the project level.

Click the ADD ITEM button there, and in the row that opens paste the public key content - all of it, including the encryption type at the beginning and the username at the end.

Then save the changes.

Setting a key at the project level:

In the console menu under Compute Engine, the very bottom part of this menu is called Settings. At its top are the Metadata settings.

When entering there, there are two tabs - METADATA and SSH KEYS. Switch to the SSH KEYS tab.

If there’s nothing there, an add key button will appear in the middle of the page. If there are already keys, click EDIT at the top, then an ADD ITEM button will appear that when clicked opens a box where you can paste the public key and save the settings.

Now you can connect in this way to the machine where the key was defined, and if defined at the project level, to every Linux machine.

For the lab, we’ll define the key at the project level.

SSH Connection Using an Asymmetric Key:

Now we can connect to machine instance-5, for which we didn’t set a username and password:

From instance-1, enter an SSH connection command:

ssh -i f ~/.ssh/key-file-name username@10.0.30.15

Walk through the syntax:

First is the command that activates an SSH connection. Then there’s the -i flag, meaning identity-file. We’re telling the command to authenticate our identity from a file instead of a password. Finally, enter the username and the machine we want to connect to, with the @ symbol connecting them.

Of course, in our case replace key-file-name with the name you chose for the key files, and username with the username you chose to enter as Comment earlier.

And there - wonder of wonders! We connected to the machine without having to set a user in it. The machine took the user from the Metadata, and when we authenticated its identity using the private key, we were granted access.

• Note that a user who connects in this way receives sudo permissions.

Connecting via Putty:

If we want to use the same method to connect via Putty to instance-1, we’ll need to convert the private key to the ppk format that Putty recognizes.

Inside the machine where we created the keys - in our case instance-1, run the following command:

cat ~/.ssh/key-file-name

The private key file content will appear on screen. Copy all of it and save in a text file on the desktop.

Open PuTTygen - you can search in Windows search, find it in the applications menu in the Putty folder, or right-click on the Putty tab in the taskbar and select Run PuTTygen from the menu there.

In the PuTTygen window on the right is a Load button. A file explorer will open where you go to where you saved the text file earlier. Currently it shows only ppk files. Tell it to show all files, select the file containing the key and confirm. It will ask to confirm importing a foreign key, then load it.

You can then save the key in ppk format using the Save private key button located fairly far down on the right in the window.

Now when wanting to connect to instance-1, open a Putty window, and in the left part of the window is an options menu. In the lower part of Connection is a category that can be expanded - SSH. There, Auth needs to be expanded and you enter Credentials.

Click Browse in the upper field - Private key file for authentication, and select the ppk file we just created using PuTTygen.

Now in the left part click the very top - Session, which returns to the tab with the basic connection details.

At the top in the Host Name section, put the external address of instance-1, and you’ll see you’re asked to enter a user. Once you enter the user you chose as Comment, you successfully connect to the machine.

This concludes this lab.

If you want to continue further, don’t delete the resources. At most, shut down all the servers that were created, so they don’t draw from the budget for computation resource usage (only storage costs for the disk sizes defined for the machines).

The next lab will use everything we’ve defined here.