- Windows 10 Fall Creators Update installation and features - Thu, Nov 2 2017
- Install Microsoft SQL Server on Ubuntu Linux - Thu, Jan 5 2017
- Use PowerShell with Google Cloud Platform - Thu, Dec 8 2016
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:
Subnet: Bastion is in Public-Subnet
Auto-assign Public IP: Enable (because we want a public IP address for the Bastion instance)
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.
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.
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:
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.
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:
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:
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!
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:
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.”