Connecting two EC2 instances via SSH

One interesting problem that have crossed me recently is connecting two EC2 instances within the same Security Group using SSH.

For you to be able to do this tutorial, you must have had read my two previous tutorials about setting up AWS Security Groups and creating rules on AWS Security Groups

Creating a rule: Allowing instances within the same SG to access each other.

Using this tutorial, I would create an SG with the name jamby_talking_servers. And I would add a rule that allows “all traffic” as type and make the source “custom IP” and type the current SG’s SG Number and also add an SSH access rule to my local machine (similar to the one I did above) so I can access an instance.

This would allow all forms of traffic between two instances belonging to this SG.

Demonstrating SSH access via an EC2 instance to another EC2 instance belonging to the same SG

The demonstration would compose of 4 parts. This is to properly allow the first server to access the second server.

I. Creating the instances and SSH to 1st Server

For this purpose, I would create 2 t2-micro Ubuntu instances all associated with the security group “jamby_talking_servers”.

First, I would SSH to the first server “ubuntu@ec2-52-90-93-254″ using my keypair file.

ssh -i n-virginia-kp.pem ubuntu@ec2-52-90-93-254.compute-1.amazonaws.com

II. Generate public key for the first server (if there isn’t any)

First we have to check if there are ssh keys for this instance using

sudo find / -name "id_rsa.pub"

Then, if there isnt, we generate one using the command

ssh-keygen -t rsa -b 4096 -C "instance-1"

We press enter three times to use the default filename (id_rsa.pub) and no passphrases.

Then, we find the SSH file using the command

sudo find / -name "id_rsa.pub"

In my case, it lies on /home/ubuntu/.ssh/id_rsa.pub so I use sudo vi to access that.

sudo vi /home/ubuntu/.ssh/id_rsa.pub

I then copied the contents of the file to a textfile and store it for section III.

III. Authorizing Server 1 to access Server 2 without the .pem file

In the environment, we would not be able to upload the .pem file as easily (except ofcourse if we use FTP to make the .pem available to server 1). So instead, we add the public SSH key of server 1 (that we generated from section II) to the authorized_hosts of server 2.

To do that, we first SSH using our local machine to server 2 (in my case ubuntu@ec2-52-90-57-156) and find the authorized_keys file. To do that,

sudo find / -name '*authorize*'

For my case, it is in ./.ssh/authorized_keys. And then we open that using sudo vi.

sudo vi ./.ssh/authorized_keys

Then, we append a new line to place the SSH public key of server 1 (that we derived from part II) into this file.

The authorized_keys files should look like this

Now, we are ready for the final moment, accessing server 2 via ssh in the console of server 1.

IV. Accessing Server 2 using Server 1’s console using SSH.

Going back to server 1, we then use the SSH command without the -i and the .pem file.

ssh ubuntu@ec2-52-90-57-156.compute-1.amazonaws.com

Now, we find ourselves into the console of server 2 using the console of server 1.

Notice that when we exit from server 2’s console, we find ourselves back to the server 1.

And that is how to connect two EC2 instances via SSH.

Sources for all three tutorials:

https://help.github.com/articles/generating-ssh-keys/

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html?console_help=true

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance_linux.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html#using-ssh-client

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair

 

AWS Security Groups: Setup

 

 

This blogpost is the beginning of a three-part tutorial in order for us to demonstrate the power of AWS Security Groups (SG). In this blogpost, we would create an AWS instance using the default SG (that disallows all inbound traffic) for us to appreciate the use of studying security groups and then we would create a security group.

In the next blogpost, we would place rules into the SG and demonstrate how we can connect our local machine to the EC2 instance that is associated with the EC2.

In the final blogpost, we would take this a step further and connect two EC2 instances within the same SG using SSH.

Now, let us get started on the tutorial by creating a AWS Instance.

Creating an AWS Instance with a default SG

Since the scope of this blog post is to demo how security group works, I will pass very quickly over how I launched the EC2 instance.

Using the IAM user I created from here, I go to my EC2 dashboard. I choose an Ubuntu 14.04 Amazon Image so that my EC2 would come preinstalled with Ubuntu 14.04. I then chose an t2.micro instance to minimise costs. And I associated the AWS instance with the default security group.

For our purposes, I intentionally set the default SG to have no inbound traffic rules so that we can demonstrate the server I just created is useless and inaccessible. AWS is even smart enough to detect the lack of SSH access thru port 22 and would warn you thru a popup.

Rule of Thumb: There usually is one default security group in Amazon. And the default SG if unchanged, does not allow inbound traffic but allows all forms of outbound traffic. Also, if you do not put any customized security group in the EC2 instance you are creating, you will be forced to take the Default Security Group.

Accessing your AWS Instance

To be able to access AWS instances you need a key-pair file and would need to refer to that file every time you do an SSH to your server.

ssh -i <keypairfile> <username>@<public_dns_name>

Username is ubuntu for Ubuntu servers, ec2-user for Amazon Linux, Fedora (or fedora) and RHEL5 & SUSE Linux (or root).

Hence, when I tried to access my server using my keypair file, it resulted in a connection time-out.

This is where the importance of a security group comes in. It is actually like a firewall that allows you to define which kinds of traffic can enter, from where and thru what ports. Pretty much like a higher-level iptables.

So now that we have an appreciation of the importance of security groups (henceforth referred interchangeably with the acronym SG), let us know create an SG.

Creating a Security Group

Go to the Ec2 console page of AWS and under the Network and Security Panel at the left side of the screen, choose ‘Security Groups’.

Once clicked, you will be redirected to a table that contains the Security Groups that you already have. If you are just getting started in AWS, you will see that you already have one SG in place. This is the default SG and when creating an EC2 instance without specifying an SG. To continue creating an SG, click ‘Create Security Group’.

You will then be directed to the screen below and will be asked to place the name of the SG, its description, the VPC it is associated with and finally, the inbound and outbound traffic. So fill up the Security Group Name. For the purposes of this tutorial, we would name our SG “jamby_cool_servers”

Best Practice Tip: When creating an SG, make sure that you make it as concise as possible, as AWS resolves conflicts between rules by allowing the most permissive rule possible. Meaning when you create a rule that allows SSH access thru port 22 and another rule that allows access thru all ports, the latter (which is more permissive) will be chosen and implemented.

As you can see, by default the SG has no rules for inbound traffic (meaning it denies all inbound traffic). Outbound traffic however, is allowed across all ports and all protocols.

From this panel, we can already add/delete rules easily. But for this demo, we will not create rules from here, but would instead create it in the next section.

Now, we press create and watch AWS create our Security group.

 

To continue on with creating rules for the tutorial, go here

AWS Security Groups: Creating Rules

 

We would now place rules into the SG that we created from here and demonstrate how we can connect our local machine to the EC2 instance that is associated with the EC2.

Updating the rules of a Security Group

To create a rule, go to Network & Security Panel then click on the SG you want to create a rule on. Below, you would see four tabs: Description, Inbound, Outbound, and Tags. Click on either Inbound or Outbound (for our case, let’s click on Inbound). After that, you will see all Inbound rules listed.

For now, we have none, so let’s go ahead and starting rules by clicking on the “Edit” button.

Rule of thumb: In firewall terms, AWS Security Groups is a default-deny policy. Meaning if there are no rules to allow packets into the instances, you will see that no packet can get thru. This also means that you can’t create rules that deny access from a server, only ones that allow.

Creating a rule: Allow SSH Access

One of the first points of access to a newly started server is thru SSH, so it is crucial that we learn how to allow SSH access. To create a rule that allows SSH access, we choose “SSH” as type, TCP as protocol and port as 22. We can choose the source from which to allow SSH access. There are three times of sources we can specify: Anywhere, My IP and Custom IP.

Anywhere sets the Source IP to 0.0.0.0/0, hence applying the inbound rule across all servers that try to access the server. My IP will call a method that will find the IP address of the network you are currently in.

Finally custom IP can either (1) specify a custom IP address you want to grant access to or (2) specify a Security Group ID as the source. The first option allows you to specify IP address in CIDR notation, meaning if you have a single IP address, simply append “/32” to the end of the IP . However, if you want to allow a range of ip addresses connected to a single network, then you can  specify the entire range (i.e 203.0.113.0/24.)

The second option allows instances under that SG to be able to avail of the inbound rule.

To demonstrate that we can allow SSH access, we will set the source to My IP so I can directly access SSH via the computer I’m using right now. Going back to the Security Groups panel, we would see

Demonstrating SSH access via my local machine by creating an AWS Instance that is associated with an SG that allows SSH access to my local machine.

I would create a new EC2 t2.mirco instance using the instructions at the “Creating and Accessing an AWS Instance with a default SG” section of this tutorial only that i would associate the instance with the ‘jamby_cool_servers’ SG at Step 6.

Accessing thru my local machine (via the office wifi) using the syntax presented in the Accessing your AWS Instance section of this tutorial, I was able to enter the console of the server.

ssh -i n-virginia-kp.pem ubuntu@ec2-54-174-66-204.compute-1.amazonaws.com

Demonstrating denial of SSH access via my unauthorised machine by using another AWS Instance.

However, when I changed my internet connection, I wasn’t able to access the console because the SG associated with the instance I am trying to access specifies the IP Address of my office internet connection. The attempt gives me a connection time-out.

ssh -i n-virginia-kp.pem ubuntu@ec2-54-174-66-204.compute-1.amazonaws.com

Creating a rule: Allowing instances within the same SG to access each other and demonstrate how to connect two EC2 instances with each other

 

See this blogpost about connecting two EC2 instances via SSH