Introduction
This post is the second in a series about alternatives to bastion hosts in each of the major cloud providers. The first post covered an introduction to bastion hosts, the SSH multiplexing attack, some disadvantages to managing your own bastions, and an alternative solution in GCP. In this post, we’ll cover the Session Manager service provided by AWS. Although there are other methods for accessing EC2 instances in AWS, Session Manager is the best match for our requirements, which are:
- Does not require public IP addresses for the VMs.
- Eliminates the possibility of SSH multiplexing attacks.
- Consolidates access (such as SSH or RDP) to IAM credentials.
- Captures metadata and full session logs (when possible) for remote access.
The Session Manager service is provided as a component of AWS Systems Manager. To use Session Manager, you must set up AWS Systems Manager. While Session Manager supports Linux and Windows instances, we will focus on using it with Elastic Compute Cloud (EC2) Linux instances running in AWS. If you have a hybrid environment, which also contains VMs in your own facility, then you can still use this solution with some additional steps that we do not cover in this post.
Why AWS Session Manager?
Session Manager can be used to access instances within private subnets that allow no ingress from the internet. This is made possible by the Systems Manager (SSM) agent running on the EC2 instances, which pushes traffic to the Session Manager service. The configuration shown in the diagram below provides an example of how it can be configured, which will be explained in more detail in the sections below.
The figure shows that the EC2 instances are not at all accessible from the internet, even by our authorized client. The SSM agent starts the session for us, and pushes traffic to the interface endpoints we’ve created in the VPC for the SSM services. The Session Manager service acts as the intermediary, providing the client with a shell for an EC2 instance.