Still Using SSH On AWS Check Out Session Manager Instead! __HOT__

Using the AWS Systems Manager console or Amazon EC2 console, you can start a session with a single click. Using the AWS CLI, you can also start a session that runs a single command or a sequence of commands. Because permissions to managed nodes are provided through IAM policies instead of SSH keys or other mechanisms, the connection time is greatly reduced.

Still using SSH on AWS Check out Session Manager instead!

The AWS Systems Manager console includes access to all the Session Manager capabilities for both administrators and end users. You can perform any task that is related to your sessions by using the Systems Manager console.

To use the AWS CLI to run session commands, you must be using version 1.16.12 of the CLI (or later), and you must have installed the Session Manager plugin on your local machine. For information, see (Optional) Install the Session Manager plugin for the AWS CLI.

You can also set up VPC Endpoints for Systems Manager using AWS PrivateLink to further secure your sessions. AWS PrivateLink limits all network traffic between your managed nodes, Systems Manager, and Amazon EC2 to the Amazon network. For more information, see Create VPC endpoints.

A session is a connection made to a managed node using Session Manager. Sessions are based on a secure bi-directional communication channel between the client (you) and the remote managed node that streams inputs and outputs for commands. Traffic between a client and a managed node is encrypted using TLS 1.2, and requests to create the connection are signed using Sigv4. This two-way communication allows interactive bash and PowerShell access to managed nodes. You can also use an AWS Key Management Service (AWS KMS) key to further encrypt data beyond the default TLS encryption.

When John sends that first command to start the session, the Session Manager service authenticates his ID, verifies the permissions granted to him by an IAM policy, checks configuration settings (such as verifying allowed limits for the sessions), and sends a message to SSM Agent to open the two-way connection. After the connection is established and John types the next command, the command output from SSM Agent is uploaded to this communication channel and sent back to his local machine.

For example, for an Amazon Elastic Compute Cloud (Amazon EC2) instance, the key pair file you created or selected when you created the instance. (You specify the path to the certificate or key as part of the command to start a session. For information about starting a session using SSH, see Starting a session (SSH).)

You must connect using the managed node account associated with the Privacy Enhanced Mail (PEM) certificate, not the ssm-user account that is used for other types of session connections. For example, on EC2 instances for Linux and macOS, the default user is ec2-user. For information about identifying the default user for each instance type, see Get Information About Your Instance in the Amazon EC2 User Guide for Linux Instances.

Ideally, you install the agent when the instance is bootstrapped; however, you can install it on a running EC2 instance or on a non-AWS host to which you already have access. For example, to bootstrap the agent on an Amazon Linux EC2 instance, install it using the package manager in the instance user data:

As written, the first rule will never match because the TCP protocol is the first protocol that will appear in the initial flow, starting with the TCP handshake. Therefore, when the flow starts, while the first rule will be evaluated, there will be no TLS protocol to match, so the drop rule will match instead and drop all of the traffic to aws.amazon.com. To avoid this, you should write rules that only evaluate after a session has been established using the flow keyword, for example:

For the rule that allows inbound traffic, check the Source field. If the value is a single IP address, and if the IP address is not static, a new IP address will be assigned each time you restart your computer. This will result in the rule not including your computer's IP address traffic. The IP address might not be static if your computer is on a corporate network, or you're connecting through an internet service provider (ISP), or your computer IP address is dynamic and changes each time you restart your computer. To ensure that your security group rule allows inbound traffic from your local computer, instead of specifying a single IP address for Source, rather specify the range of IP addresses used by your client computers.

(Optional) Otherwise, if you don't have permission to edit files in /mnt/tempvol, you must update the file using sudo and then check the permissions on the file to verify that you are able to log into the original instance. Use the following command to check the permissions on the file.

You can instead launch sessions using the credentials of an operating system account. You can do this either by tagging an IAM user or role or by specifying an OS user name in Session Manager preferences.

Any action performed over the session manager API is logged in CloudTrail. API actions such as StartSession can easily generate security alerts by SNS or trigger another action on AWS as the result of sessions activity (lambda functions or SSM run command are good examples).

You can create Session Manager preferences for your account in the selected AWS Region via AWS Cli. Session manager preferences can be created using a JSON file and running a SSM document SSM-SessionManagerRunShell. Check out the steps in below.

Required to use the AWS CLI to start sessions (instead of using AWS Manager console), version 1.16.12 or later of the CLI must be installed on the local machine (Instructions to install AWS CLI for all supported systems).

On top of that, it is advisable to extend the IAM policy from the previous section to only allow users, groups, roles to start a new session when using the document containing your audit log configuration. Replace with the region you are operating in and with your AWS account ID.

This article describes an AWS innovation introduced in 2019 called the session manager. Yes, you really can improve that mouse trap. The session manager adds to ssh a layer of authentication and authorization based on IAM and only requires HTTPS outbound on the server end. SSH rides on top of the Session Manager via SSH's proxy capability.

AWS offers session manager clients as part of the AWS CLI (with an add on) and the Console (Browser interface). The client and server communicate over HTTPS and secure web sockets, via the AWS Systems Manager (SSM) gateway:

Note that the above allows a user to list all current and historical sessions. Last I checked (Nov 2019), you cannot restrict DescribeInstances to those started by the user, but it does fortunately restrict entry termination to those the user has started.

What about access to data stores, like private RDS or Elasticsearch/Kibana instance? You can use your client tools, like a MySQL Workbench in the case of RDS MySQL, or a browser in the case of Kibana. You connect them to a local port, e.g. 3306 or 8443, that is an open ssh tunnel riding on the session manager.

Thanks for your response. I tried connecting using Session Manager Console instead of EC2 console and didn't work. Actually I get the red warning only the first time I try to connect without the SSH port opened. Then I assign a security group with inbound access to port 22 and can connect. Now, when I remove the security group and try connecting again, I don't get the red warning in the console but a blank screen, nothing happens and I can't get in.

To make it possible to access your container, you need to install the session manager plugin, add SSM permissions to the ECS task IAM role, and then update your ECS service or task with --enable-execute-command to enable ECS Exec.

With all this configured, you can use the session manager to connect to the instances. This can all happen through the AWS Console! Given that we have met the previous requirements, the instances will show up under the Managed Instances tab in Systems Manager.

Another method AWS provides for gaining shell access to an EC2 instance is via EC2 Instance Connect. EC2 Instance Connect does two things. First, it can provide a terminal experience in your browser for connecting to EC2 instances. In this case the AWS EC2 Instance Connect backend proxies your connection to the instance. For browser based access to work the EC2 instance must allow incoming connections from the EC2 Instance Connect IP addresses1. Second (and most importantly), EC2 Instance Connect provides the EC2 instance a temporary public key on-demand via the EC2 instance metadata service. This allows a user to connect using any keypair. The way this works is the SSH daemon is set up with a helper script that will check the EC2 instance metadata for public keys when authenticating incoming connections. The EC2 Instance Connect api call send-ssh-public-key provides your public key to the instance for 60 seconds. The keypair is only used to establish the connection so sessions are not limited to 60 seconds.

In my opinion the best part of EC2 Instance Connect is the ability to manage SSH access to your instances via IAM policies, instead of adding and removing public keys from the instances. Unfortunately you still need a direct networking connection from your local machine to the instance (public IP, VPN, etc).

Explanation of the script: First the instance's availability zone is queried, then the public key is uploaded. Finally a connection is made to the instance via sessions manager with port forwarding for SSH.

The next question I have with this - I *think we should be able to connect using SSH from an outside SSH client. Meaning, I have a client on my desktop (The client I use is called Putty). So, is it possible to connect from desktop through session manager instead of having to login to the console?

AWS CLI supports session manager, if you install the session manager plugin for CLI. You can start a session from your command line with aws ssm start-session --target [instanceid]. This does not require the SSH key for the instance, but you do need IAM permissions to start a session. 041b061a72