“SSH” Alternative in AWS

Keep your instances private and still be able to manage them.

Architectural diagram made by the author

One of the things I see a lot, from companies using AWS, or devs playing with it, to tutorials and documentation, is the creation of public EC2 instances (with IP addresses reachable from the Internet) for the sole purpose of managing them. I’m mainly talking about SSH, but other protocols like RDP are in the same boat.

Yes, some do the sane thing of using proper security group rules to narrow done the allowed traffic to their instances, but you still need to manage users on the instance and SSH keys. You’d say there are ways to work around that too, like configuring instances with Ansible and using LDAP for connecting users to solutions like Microsoft Active Directory.

But! What if there’s an easier way?

That’s where the Session Manager capability of AWS Systems Manager comes in. It is good enough for big enterprises, and exceptional for small companies, or playground environments, where you don’t want to deal with some of the things I’ve mentioned above. You don’t even need a private connection to the AWS network, like a VPN or any other direct link.

What does it do?

In a nutshell, it allows you to connect to instances (those not reachable from the Internet too) using your AWS session via AWS Management Console (ie. web browser) or AWS CLI.

It is integrated with AWS Identity & Access Management (IAM) service, so you can decide who has access to which instance, and using SSM documents you can also restrict the commands they use (more on this later). This of course comes with an audit of session activity in AWS CloudTrail.

It also supports logging the commands executed on each session so you can audit who did what. It can log to an Amazon CloudWatch log group or Amazon S3 bucket.

How does it work?

As shown in the diagram from the beginning of the article, it leverages the SSM agent installed on the instance, which nowadays comes with most AWS-owned AMIs. The agent connects to the Systems Manager service (you can make that connection private too by using AWS Private Link) and that connection is the “private” tunnel between you (outside the AWS network) and your instance (inside the AWS network).

Mentions and caveats

• It is very easy to set this up in its most basic configuration**, so I encourage even new users of AWS to use it and avoid making EC2 instances public unless absolutely necessary*
  * you rarely need an EC2 instance public, depending on your requirements you probably want a load balancer in front of it
  ** all you need is to use an AMI that has an SSM agent already installed***;
  create your EC2 instance using that AMI;
  in the instance’s security group only 443 TCP (HTTPS) outbound is required;
  associate AmazonSSMRoleForInstancesQuickSetup IAM instance profile to the instance (AWS creates this IAM role in your account)
  *** popular AMIs with SSM agent already installed: amzn2-ami-hvm-2.0* and ubuntu/images/*
• EC2 instances must have an IAM instance profile associated.
  The IAM role gives permission to the EC2 instances, and as such to the SSM agent running on it, to connect to Systems Manager services and to CloudWatch or S3 for sending the logs (and to KMS service too if you enable encryption).
  AWS provides an IAM policy for the basic requirements (connecting to Systems Manager services), called AmazonSSMManagedInstanceCore.
  They also create an IAM role (and an IAM instance profile for it) so it is very fast to bootstrap this setup. The role is AmazonSSMRoleForInstancesQuickSetup.
• Session Manager can be used to get an interactive session into the instances (shell or PowerShell console), but it can also be used just to tunnel other protocols like SSH & RDP.
  Doing that comes with some downsides:
  1. You lose logging capability since protocols like SSH encrypt all data sent in the session that Session Manager just tunnels at this point.
  2. You get back to managing users and SSH keys.
• Using SSM documents to limit commands used in the sessions works by enforcing IAM identities (your users) to be able to start sessions while only using the SSM documents you create & manage (in which you specify what commands they can run in the interactive sessions).
  The last 2 words point out a limitation too: if you just use Session Manager to tunnel other protocols, you cannot rely on SSM documents & IAM policies to make enforcements on what users can do once inside the instance.
• Amazon ECS Exec is also implemented with AWS Systems Manager Session Manager. This is a feature of the Elastic Container Service to help debug running containers by running commands inside them.

If you want to get in-depth with Session Manager, check out AWS documentation.

Feel free to reach out to me if you want to discuss possible setups using Session Manager. Or other AWS services for that matter.