Interactive shell access to cloud or data center environments is a must in many corporate businesses. It must also be supported in a secure, auditable manner, often programmatic or via scripting, and with strong access controls.
The AWS public cloud began with Amazon EC2-Classic and networking was much simpler back then, since you could only launch an Amazon EC2 instance with a public IP. Many things have changed since then and more specifically VPCs have become the default and recommended way to use cloud resources, all using private IPs. For years, users relied on firewalls and bastion hosts to securely access cloud assets, but these options had security and management overhead tradeoffs. Typically, you’d have a bastion host to connect to your servers to do some manual operations tasks. It’s not something you’re supposed to do too often because most of the system configuration and maintenance must happen automatically.
If your bastion host is unavailable, then you cannot access your machines easily. And if it’s compromised, then you’re in real trouble. Besides that, you usually want to have more than one bastion host, each with a different network and user access.
But bastion host management is only part of the problem. You also need to control who can access which machines over those bastions and log commands executed on the machines during SSH (Secure Shell) sessions for simple audit and debugging purposes. You either need to integrate it with central identity management or automate the management of authorized SSH keys by some other means.
While having a bastion host is a valid approach, cloud technologies have evolved, and so have the requirements for cloud networking. Now, it’s time for an entirely new architecture for networking in the public cloud.
Let’s take AWS Systems Manager Session Manager (Session Manager), for example. Session Manager facilitates secure, audited console access to cloud resources without the need for external ingress points.
What is Session Manager?
AWS Systems Manager is a service for managing your cloud and on-premise workloads. It’s not just a single tool but also a collection of various utilities that you can use independently. You can automate patching, use simple and secure key-value storage for parameters, run various scripts with popular configuration management tools, and so on. Session Manager is a fully managed AWS Systems Manager capability to manage Amazon Elastic Compute Cloud (Amazon EC2) instances, on-premises instances, and virtual machines (VMs) through an interactive, one-click browser-based shell or the AWS Command Line Interface (AWS CLI).
You don’t need to manage any bastion hosts with Session Manager. As a matter of fact, you don’t even need to use bastion hosts anymore. All the connections happen over the secure channel between AWS Systems Manager Agent (SSM Agent) and the AWS data center.
Thanks to the following qualities, I recommend that you consider replacing SSH with Session Manager.
For authentication and authorization, Session Manager uses Identity and Access Management (IAM). Therefore, when logging into Amazon EC2 instances, you can reuse IAM users and IAM permissions to authenticate and authorize engineers’ access.
Multi-factor authentication (MFA) is built into IAM. Therefore, it is easy to enable administrators to authenticate with a second factor — e.g., a one-time password (OTP) app — before setting up a remote session with an Amazon EC2 instance.
Built-in audit log
A common security and enforcement requirement is monitoring each command an administrator executes on an Amazon EC2 case. With Linux default tools, I do not know of an easy-to-implement and tamper-proof way to do so.
Session Manager does, however, deliver audit logs by default. Each command is captured by Amazon CloudWatch Logs or Amazon Simple Storage Service (Amazon S3) and processed.
How to use it
- Install the SSM Agent on each Amazon EC2 instance. (Some AMIs like Amazon Linux already have it installed by default).
- Create an IAM role for the Amazon EC2 instance, which grants access to the AWS Systems Manager.
- Use IAM policies to restrict which IAM user or role can start a session with an Amazon EC2 instance.
- Configure audit logs.
- Use an IAM user that has permission to use Session Manager for the instance.
As of July 2019, users can now tunnel SSH and SCP (Secure Copy) connections directly from a local client without the need for the AWS Management Console.
Port forwarding in Session Manager lets you securely create tunnels between your instances deployed in private subnets, without any need to start the SSH service on the server, use a bastion host, or open the SSH port in the security group. Similar to SSH tunnels, port forwarding enables you to forward traffic between your PC and open ports on your instance.
Starting a session (AWS CLI)
If you haven’t already done so, install and configure the AWS CLI.
Run the following command to start a session using the AWS CLI:
aws ssm start-session \ --target instance-id
instance-id represents the ID of an instance configured for use with AWS Systems Manager and its Session Manager capability, such as
Starting a session with SSH and SCP
You will typically find your SSH config file at ~/.ssh/config
Add the following to the SSH config file:
# SSH over Session Manager host i-* mi-* ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
The OpenSSH client is available as an installable component in newer versions of Windows.
Typically, you will find your SSH config file at C:\Users\username\.ssh\config though the .ssh directory will not exist until SSH has been used.
Add the following to the SSH config file:
# SSH over Session Manager host i-* mi-* ProxyCommand C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p"
You will be ready to initiate SSH and SCP connections to your cloud assets directly from your local machine once these measures are completed.
Here are some things to keep in mind when working with Session Manager:
- Make sure that IAM permissions allow the minimum permissions needed. You don’t want to allow any IAM user full root access into all instances.
- Also, be mindful that the SSM commands might be logged, so don’t output any sensitive information in them.
For secure, audited, shell-level access to AWS resources without the hassle that comes with running bastion hosts, use the Session Manager capability of AWS Systems Manager instead of SSH. You can use an interactive, one-click browser-based shell or the AWS CLI to access Amazon EC2 instances, on-premises instances, and VMs.
Need help securing your AWS infrastructure? The nClouds team is here to help with that and all your AWS infrastructure requirements.