In parts one and two of this three-part series, we demonstrated the creation of a VPC, IGW, Route Tables, NACLs, and Security Groups, coupled with associations and rules. In this third article, we demonstrate how to set up an instance in each of our networks (Public and Private), test connectivity, and ensure only our Bastion instance has the ability and keys necessary to connect to our Private instance via SSH and Pageant. We also utilize our existing Subnets and Security Groups when building our instances.

Create AWS Public and Private Instances ^

Instances are, of course, Amazon Machine Images (servers) that are part of the EC2 section of AWS. We’ll start with creating the Bastion host. Go to the AWS Dashboard > EC2 > Create Instance > Launch Instance > Choose Amazon Machine Image: (Free Tier Eligible) Amazon Linux AMI HVM > Select > Instance Type: Free Tier t2.micro > Configure Instance Details:

Network: 4sysopsVPC

Subnet: Bastion is in Public-Subnet

Auto-assign Public IP: Enable (because we want a public IP address for the Bastion instance)

Configure Bastion instance details

Configure Bastion instance details

Next: Add Storage (leave defaults here) > Next: Tag Instance > Name = Bastion > Next: Configure Security Group.

Step 6: Configure Security Group > Assign SG > Select an existing SG > Public-SG > Review and Launch.

Configure Bastion instance with Public SG

Configure Bastion instance with Public SG

Review and Launch > Launch

As with most AMI Linux instances, we’ll now need to either use an existing key pair or create a new key pair. Select Create a new key pair, and then provide a key pair name: such as bastion4sysopskp > Download Key Pair > Launch Instances.

We’ve now created the Bastion instance, as displayed in the following diagram, which is nested inside our Public Subnet, the Public Security Group, the Availability Zone US-West 1a, and our VPC.

Bastion instance diagram

Bastion instance diagram

Next, we’ll create the private instance. Go to the AWS Dashboard > EC2 > Create Instance > Launch Instance > Choose Amazon Machine Image: (Free Tier Eligible) Amazon Linux AMI HVM > Select > Instance Type: Free Tier t2.micro > Configure Instance Details:

Network: 4sysopsVPC

Subnet: The PrivateInstance will live in the Private-Subnet. When we select this subnet, our instance is automatically created within the Availability Zone US-West 1c

Auto-assign Public IP: Use subnet setting (Disable) (because we do not want a public IP address for the PrivateInstance)

Next: Add Storage (leave defaults here) > Next: Tag Instance > Name = PrivateInstance > Next: Configure Security Group.

Step 6: Configure Security Group > Assign SG > Select an existing SG > Private-SG (this will allow SSH from the Public Security Group) > Review and Launch.

Private instance Security Group

Private instance Security Group

Note: If you receive a warning here that 0.0.0.0 allows all IP addresses to access your instance, it’s okay to proceed, because our subnet and NACL rules contain security, and our PrivateInstance will not have a Public IP.

We’re almost finished with our PrivateInstance host, so click Review and Launch > Launch > Choose an existing key pair > Select a key pair: bastion4sysopskp > Acknowledge > Launch Instances > View Instances.

With both of our instances built, we can see that our Bastion has a public IP address, and our PrivateInstance (selected in the following screenshot) only has a Private IP address:

Bastion and Private instances

Bastion and Private instances

Remote SSH Console Connections with PuTTY ^

Now we can test logging in to our Bastion remotely with PuTTY and, secondly, connect to the Private instance. First, we want to ensure that we can at least connect to the Bastion from our home IP, and then we can move on to agent forwarding to connect to our Private instance.

Hopefully, you’re familiar with connecting to an AWS Linux instance with PuTTY. If not, you can review the procedure by right-clicking on the Bastion instance, then click Connect. Further information about how to connect to an instance with PuTTY can be found here. Convert the key you previously downloaded into a .ppk file with PuTTYGen, and add that private key to PuTTY for your Bastion session. For the Bastion hostname or IP, get the public IP address from your list of running AWS Instances, and also save the hostname or public IP into the session settings within PuTTY:

Bastion PuTTY settings

Bastion PuTTY settings

When connecting for the first time, you may receive a warning about the key, and then you’ll be prompted to log in with a username. The default username for an Amazon Linux AMI is ec2-user.

If you’re greeted with the following session, you’re in!

Successful AWS PuTTY session connection

Successful AWS PuTTY session connection

Now that we’ve been authenticated into our Bastion host, we want to connect via SSH into our PrivateInstance. To do this, first we need to close our connection and then use PuTTYGen, Pageant, and PuTTY to allow agent forwarding. Essentially, Pageant runs as a service in Windows and forwards our key over to our PrivateInstance without having to set up a new key with SSH-keygen (never keep your private key for your Private Instances on your Bastion Host). If you’re unfamiliar with connecting to Linux instances running in a private Amazon VPC with PuTTY, there is a good AWS Security Blog post explaining the concepts and procedure here.

After you’ve imported and converted your key with a passphrase, re-connect back to your Bastion host. You can now issue the following command to SSH into your PrivateInstance:

ssh ec2-user@<PrivateInstance-IP-address or DNS-entry>

Once connected, you should be greeted with the PrivateInstance’s shell prompt:

Successful Private Instance SSH session from Bastion

Successful Private Instance SSH session from Bastion

Final Considerations ^

With our connection to our PrivateInstance complete, we may want to create an Elastic IP address for our Bastion host, which currently only has an AWS-issued DHCP address. An Elastic IP will ease the pain by protecting a single IP address for us (the first one is free, I believe,) and, no matter which address our Bastion host receives upon reboot, we can still get to the Bastion by connecting to our Elastic IP. I won’t go over the Elastic IP procedure here, but it’s a great feature to be aware of in case you want a consistent connection experience.

Lastly, our Linux instances could just as easily have been replaced with Windows Server hosts and, as such, we would have opened things up for RDP traffic as well as decrypt Administrator passwords.

Hopefully, with the instructions in this series, you’ve gained a better understanding of the encompassing concepts and components of an AWS VPC, in addition to a fortification of your AWS “security in the cloud.”

0
0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account