Getting Your Feet Wet with AWS - Part 2: Connect to Amazon EC2 Instance via SSH

In Part 1 of this tutorial, we created an Amazon EC2 instance using a pre-built minimalist AMI. In other words, we created a remote virtual machine from a "disk image" with just enough of Linux operating system (plus some applications) for it to boot up and run, and for us - to be able to remotely administer it over a secure connection.

So, today, we are going to do just that: connect to our Amazon EC2 instance using SSH in order to be able to remotely administer it.

Note:
In simple terms, SSH, which stands for "Secure Shell", is a cryptographic network protocol for secure data communication between an SSH client (on your computer) and SSH server (on the remote computer or, in our case, on the Amazon EC2 instance) over an insecure network (the Internet). Using SSH, user (you) gets secure access to the command-line interface of the remote computer (again, in our case, of the Amazon EC2 instance) and can do anything he/she is authorized to do as if he/she were sitting in front of that remote computer.

In order to use SSH, you don't really need to know anything else about it.

Let's get started.

First, go to the Amazon Web Services site and navigate to AWS Management Console by selecting it from the "My Account / Console" drop-down list in the upper right-hand corner (if you have not signed in, you will be prompted to do so), and then click "EC2". Alternatively, you can go to EC2 Management Console directly (again, if you have not signed in, you will be prompted to do so).

In EC2 Management Console, click "Instances" in the navigation side bar on the left to display the list of your instances. The one we created in Part 1 should be listed there, and its state should be "Stopped" (unless you forgot to stop it at the end of Part 1 of this tutorial).

Obviously, the instance needs to be running. If it is not, start it by ticking the check box next to the instance name and selecting "Start" from the "Instance Actions" drop-down list. Give it a minute or so. If you are impatient, you may click the "Refresh" button (it does not speed up booting - just forces the browser to refresh).

Note:
As I am writing this, Amazon's US-East region appears to be going through yet another rough patch. Unfortunately, these things do happen. Generally, if you see a bunch of errors on Amazon EC2 Console Dashboard (the default view of the console) under "My Resources", it is likely that there is some performance degradation in the availability zone where your instance happens to be physically located. Try refreshing it a couple of times, but, if that doesn't help, give it some time to recover and try again later. There is hardly anything else you can do about it. A lesson to be learned (even though these things are beyond the scope of this tutorial): for real-life mission-critical applications, instances must be distributed across multiple availability zones. If you would like to learn more about regions and availability zones (not required to complete this tutorial), you may read the first section of this article.

Let's continue.

Before attempting to establish a connection to the instance, one last thing you might want to do is check the firewall settings and change them if necessary (there is nothing more frustrating than trying to connect to a computer whose firewall is configured to refuse all connections). Of course, we could have checked/configured the firewall while creating the instance (item #8 in Part 1), but we didn't, so let's do it now.

In EC2 Management Console, click "Security Groups" in the navigation side bar on the left.

You will see just one security group called "default" listed. Select the "default" security group by ticking the check box next to the group's name.

In the lower pane of the "Security Groups" display, click the "Inbound" tab.

On the right side of the lower pane, under "TCP", you should see:

Port (Service)       Source
22 (SSH)             0.0.0.0/0

If there is no such firewall rule listed, you need to create it (follow the steps below).

On the left side of the lower pane, select "SSH" from the "Create a new rule" drop-down list.

Leave the value in the "Source" text box unchanged (0.0.0.0/0).

Click the "Add Rule" button (you should see the new rule appear on the right side) and then - the "Apply Rule Changes" button.

As far as firewall rules go, that is all we need in order to be able to connect to our instance via SSH.

Note:
Without getting too technical, here are some security group basics you might want to get a grasp of (it is actually a bit more than you really need at this point, so there is no reason to get upset if you don't understand everything):
• security groups are essentially firewall "profiles" or, in other words, sets of firewall rules that can be applied to one or more instances (an instance must belong to at least one security group, but can belong to more than one);
• security groups "live" (as in "reside") outside EC2 instances and should not be confused with the "internal" firewalls of individual instances (yes, you can have those as well);
• security group firewall rules apply only to incoming traffic, i.e., if your instance starts spewing spam or attacking other computers (just random examples), security group firewall will be unaware of that;
• all incoming traffic is rejected if not explicitly allowed to be accepted;
• security group firewall rules are combinations of the following three attributes:
  • protocol (TCP, UDP, or ICMP),
  • port (again, without getting into the ultra-technical stuff, simply understand that 192.168.1.3:22 and 192.168.1.3:80 are, kind of, two different addresses; the ":22" and ":80" are "ports" on the same IP address; most services "know" their default ports, e.g. 22 for SSH or 80 for HTTP, and that is enough for now),
  • source (a single IP address, a range of IP addresses, or a security group traffic is coming from).

Getting back to the firewall rule we have just checked/created, the "22 (SSH) 0.0.0.0/0" under the TCP heading means that our instance will accept TCP packets from any IP address on port 22. TCP is the protocol, port 22 is the standard SSH port, and "0.0.0.0/0" is shorthand (in CIDR-based notation) for all the IP addresses in the world.

So, anyone anywhere in the world should be able to establish a secure connection via SSH to your EC2 instance. Since only you have the private key (see item #7 in Part 1), only you should be able to connect. You still remember where you saved your myamazonsecret.pem (or whatever you may have called it) file, don't you?

Now that we have the firewall configured correctly, let's finally connect to our Amazon EC2 instance via SSH.

There are a few ways of doing that.

One is to use the SSH client provided by Amazon as a part of EC2 Management Console. It is a Java applet that runs inside a web browser. It is platform-independent and should run on any operating system as long as the browser itself supports it and, of course, Java is installed. Here is how to use it:

Click "Instances" in the navigation side bar on the left and select the instance you want to connect to by ticking the check box next to its name.

From the "Instance Actions" drop-down list, select "Connect" (it's at the very top of the drop-down list). This will bring up "Connect to an instance" dialog with the "Connect from your browser using the Java SSH Client (Java Required)" option expanded by default. All the fields are pre-populated, except for the one where you need to type in the full path to the private key (i.e. the .pem file you saved to your local disk while creating the instance).

Enter the full path to the private key file saved on your local machine and click the "Launch SSH Client" button.

Java applet that simulates a terminal will start in a browser pop-up window.

When the dialog box pops up, agree to add the host (i.e., your EC2 instance) to the list of known hosts (this only happens when you connect for the first time).

Voila! You are now logged in to your EC2 instance. When finished, log out and close the pop-up browser window.


The second technique works only on Mac OS, Linux or other Unix-like operating systems (Windows users are out of luck). Since you already have at least an SSH client pre-installed, all you have to do is, using command-line interface (terminal), run the following command (without any line breaks, of course):

ssh -i private_key_file_name.pem ec2-user@public_DNS_of_your_instance

In the above command line, replace:

• private_key_file_name.pem with the actual name of your private key file (in this tutorial, we have been using myamazonsecret.pem, but you can call it whatever you want);
• public_DNS_of_your_instance with the actual public DNS of the instance, which can be found in the lower pane of the "Instances" display (it's the long string of numbers and characters that ends with .amazonaws.com).

Everything else should remain unchanged. The -i tells SSH client that a private key (a .pem file) is included into the command line. As you may have guessed, ec2-user is the user name, which is standard for all Linux EC2 instances, except those based on Ubuntu (there it is ubuntu).

Bear in mind that SSH client will refuse to work if it finds that the permissions of the .pem file are not restrictive enough. Make the file readable only by you.

Once the connection is established, your terminal effectively becomes the terminal of the remote machine (in our case, Amazon EC2 instance) until you log out.


Finally, the third option is for Windows users who cannot or prefer not to use the Java applet provided by Amazon (see above).

Download PuTTY and PuTTYgen. The former is the SSH client for Windows, and the latter is a program to generate a .ppk file from your .pem file (PuTTY does not use .pem files). Both programs are stand-alone, so there is nothing to install. They just run from wherever you save them on your computer.

This is not an attempt to replace PuTTY documentation, which is actually very extensive and thorough, but just a very quick walk-through for the busy and/or impatient.

First, run PuTTYgen (the executable is puttygen.exe) to generate a .ppk file from your .pem file. When the program starts, click the "Load" button. In the file browser that pops up, change the filter from "PuTTY Private Key Files (*.ppk)" to "All Files (*.*)". Browse to the .pem file you saved while creating the EC2 instance and select it. A dialog box will pop up telling you that the key has been successfully imported, but it needs to be saved in .ppk format in order to be used by PuTTY. Click the "OK" button. Now, in the main window of PuTTYgen, click the "Save private key" button. PuTTYgen will display a warning message that you are trying to save the key without a passphrase. Click "Yes". A "Save private key as" file browser will pop up. You can call your .ppk file anything you want (as long as it has the correct extension), but, to avoid confusion, it may be a good idea to use the same file name as that of the corresponding .pem file. Close PuTTYgen.

Obviously, you need to perform the above only once.

Now, start PuTTY (the executable is putty.exe). In the left pane called "Category", "Session" is highlighted by default.

On the right side, in the "Host Name (or IP address)" text box, enter the public DNS of your instance (the long string of numbers and characters that ends with .amazonaws.com) prefixed by ec2-user@ (ec2-user is the default user name for all Linux EC2 instances, except those based on Ubuntu). Everything else here should remain unchanged.

Now, in the left pane, click "Auth" (under "Connection/SSH").

On the right, click the "Browse" button. In the file browser that pops up, select the private key in .ppk format.

Finally, click the "Open" button. This will bring up a terminal window. If this is the first time you are connecting to your EC2 instance using PuTTY on this computer, a security alert dialog box will pop up. Click "Yes".

When you see the remote system command prompt, you are logged in.

When you log out, PuTTY will close automatically.


This concludes Part 2 of the tutorial (Part 1 is here).


To be continued... maybe...