Remove port 22 from your Security Groups for good: Systems Manager’s Session Manager and Run Command features

Are you looking for an alternative to the typical SSH access into an instance? Kyle Newton, Professional Services Engineer, walks through the benefits of AWS System Manager's Session Manager and its ability to allow ease and automation.

In our last blog we walked through the process of recovering your lost SSH key for an instance. Today, we’ll discuss why we prefer the Session Manager and Run Command features that Systems Manager offer over SSH access.


  • No need to open inbound ports
  • Ditch user accounts, passwords, or SSH keys
  • No bastion host, as SSM Agent connects via an encrypted, instance-originated tunnel
  • Better access control via IAM including Date Condition Operators
  • Everything can be logged in S3, and a new session can trigger SNS
  • Can be used easily via AWS CLI or APIs for use in code and scripts
  • Can be used with instances in private VPCs with the use of PrivateLink


OS compatibility with Session Manager

  • Windows Server 2008 R2 – 2016
Linux 32 or 64-Bit
  • Amazon Linux 2012.03 - 2017.03
  • Red Hat Enterprise Linux (RHEL) 6.5 - 6.9
  • CentOS 6.5 and later
  • Ubuntu Server 14.04 LTS and 16.04 LTS
Linux 64-Bit Only
  • Amazon Linux 2015.03 - 2018.03
  • Amazon Linux 2 2 - 2.0
  • Red Hat Enterprise Linux (RHEL) 7.00 - 7.4
  • CentOS 7.1 and later
  • SUSE Linux Enterprise Server (SLES) 12

OS compatibility with Run Command

  • Windows Server 2003-2016 Inc. R2 versions
  • Linux 32 or 64-Bit
  • Amazon Linux base AMIs 2014.09, 2014.03 or later
  • Ubuntu Server 18.04 LTS, 16.04 LTS, 14.04 LTS, or 12.04 LTS
  • Red Hat Enterprise Linux (RHEL) 6.5
  • CentOS 6.3 or later
Linux 32-Bit Only
  • Raspbian Jessie and Stretch
Linux 64-Bit Only
  • Amazon Linux 2015.09, 2015.03 or later
  • Amazon Linux 2
  • Red Hat Enterprise Linux (RHEL) 6.0, 7.4, or 7.5
  • CentOS 7.1 or later
  • SUSE Linux Enterprise Server (SLES) 12 or higher

Please make sure to take a look at the Getting Started section of our previous blog to make sure you have the correct User Policy and Instance Profile. If you’re also on the default SSM agent list, great, if not you’ll need to check Here for Windows or Here for Linux to get the SSM agent installed.

What is Session Manager?

Session Manager is a replacement of the typical SSH access into an instance. It provides you a browser-based terminal window in which you can send standard operating system based commands. You can also send SSM commands via the AWSCLI or API. Session Manager is best for single instance use, where you need live feedback from the instance. Good use cases might include finding and editing certain files for your web-server, or working with some custom Python scripts where you have to perform several configuration changes—perfect for situations in which you are unfamiliar with what base OS commands and packages are available. It can be very useful for testing a set of commands before deciding to send them to a fleet using Run Command. 

What is Run Command?

The run command is best used for sending commands to multiple instances at once. You can send the commands by selecting instances manually, or by tags. It’s best for simple shell/PowerShell commands you are familiar with, such as running updates or changing some small configurations. There’s no live feedback, however, after you perform a run command you can go and view up to 2500 characters of output from the console, or access the full logs via S3. There are several pre-written documents available to select in the Run Command interface, such as running OS or SSM updates, configuring docker, applying patches and more. You can also just select the AWS-RunPowerShell or AWS-RunShellScript documents and input your own commands.

Using Session Manager

We can start using session manager back at the Systems Manager AWS Service page. Under Actions, we see both Session Manager and Run Command. Let’s select Sessions Manager and click on Start Session. Then simply select the instance you want a terminal for and click Start Session again.

A new browser window will open and you’ll find yourself in a live terminal to the selected instance. From here we can run the commands we need to. It can be useful to run PS1='\w\$ ' as your first command, as connection through Session Manager doesn’t load any ~/.profile files. 

Let’s try a few commands in this session, to make sure we know which commands to run later for a multi-instance Run Command. Let’s do something really simple. We’ll create a new user, switch to that new user and create a new folder, with a .txt file that says Hello BlueChipTek.

So we’ve successfully added a new user, Tom, created a folder for him, and create a .txt file in his new folder. We were able to make sure the commands we were typing were working correctly, test different commands out and figure out what works best without error.

sudo adduser Tom

sudo su Tom

mkdir TomsStuff

echo “Hello BlueChipTek” >> TomsStuff/Important.txt

Obviously this is a very rudimentary example, but we can see how useful it could be to have live feedback to make sure you if you want to perform a set of commands on multiple instances that there won’t be any problems.

Using Run Command

Let’s take the simple example we created in Session Manger and send this to multiple instances. Tom needs this important file on all 4 instances he owns, and also wants to make sure all the instances are up to date. Let’s jump back to the Sessions Manager page and under Actions go to Run Command this time, and select Run Command

On page 3 of the documents list, you’ll find AWS-RunShellScript. Select this. You’ll now see a section below titled Command Parameters, we’ll use the commands above to make the simple shell script, and first add the standard update command, with a -y switch so it do­­­esn’t require user input. 

We can also select the directory where this runs and when the execution times out. For these sections, we will leave both blank. We will manually select the 4 Amazon Linux 2 instances Tom needs to work on. Under rate control we could select how many instances we want to run this command on concurrently and an error threshold before it stops and marks itself as failed—a useful feature but we’ll skip it for our example. We can select which S3 bucket we’d like to have the output our command logs to, and/or send it to CloudWatch Logs. We’ll select a bucket so you can see what we get from this feature. 

We’ll skip SNS notifications, but let’s look at the AWS command line interface command. This will show you what will happen when it’s run. We can see the commands we typed above in here. This can be used to input into the AWS CLI. Click Run Command.

You’ll see this screen, we should only need to wait a few seconds to refresh and should be met with this. 

We can also check the output by clicking on an instance ID and clicking Step 1 – Output. We’ll notice that the output is truncated as it will only show 2500 characters. For a lot of simple commands this view is fine, but our yum update produced a lot of output. Let’s navigate to S3, and find our Command ID Key in our bucket, to get our stderr.txt and stdout.txt files. Our stdout shows the full yum update output. Our strerr in this case for this instance lets us know that the user Tom and folder TomsStuff already exists, as we had created it with Session Manager already. This is the go-to spot to troubleshoot execution failures and other problems. If you go into any of the instances, you’ll see a new user Tom, with a new folder and file as we created.

Congratulations, you’ve just used and learned two more features of the AWS Systems Manager! 

In the next post, we’ll be talking about adding on-premise hardware to the System’s Manager console. See you there. 

If you would like assistance or have questions on setting up AWS Systems Manager Session Manager, feel free to reach out to our Cloud Services team.