Handling hybrid environments in AWS with the Systems Manager’s Agent

Looking for consistent and secure remote access to on-premise servers or VM, while having centralized access to IAM, CloudWatch and SNS? BlueChipTek Professional Service Engineer, Kyle Newton, covers AWS System’s Manager’s agent as well as the steps to set the agent up.

We learned from the last blog post how simple and convenient System’s Manager is. We can also take advantage of the Systems Manager’s agent to allow our on-premise servers and VMs to be managed instances on AWS. This will allow us to perform actions on them via the AWS Console, CLI, or API as if it were an AWS EC2 instance.

 

Benefits

  • Consistent and secure remote access to on-premise servers or VMs
  • Ability to use the same tooling and scripts you already use on AWS native instances
  • Centralized access control through IAM
  • Centralized monitoring through CloudWatch and SNS
  • Centralized auditing via CloudTrail

 

Set-up

Prerequisites

As in previous blogs, we need a user or a role we can assume that has SSM access.

Windows users will require Windows PowerShell 2.0 or later, and Windows XP or later. PowerShell is installed by default for Windows 7 and later as well as Windows Server 2008 R2 and later. You’ll also need AWS Tools for Windows PowerShell, found here.

 

Installing SSM Agent

Installing SSM agent onto your Windows or Linux server/VM is a two-part process. The first part is the act of creating an Activation in amazon, which generates a code used to register the agent on your server/VM. The second part will be to actually install the SSM agent with the activation code. We can visit the Systems Manager Service. Under Shared Resources, click Activations, then Create an Activation. We’ll go through both Windows and Linux below, feel free to read the one that is relevant for you.


Windows

We can fill out a name, how many instances we’d like this activation to work for, and an expiry date anytime within the next 30 days. We’ll just describe the activation, allow up to 12 Servers/VMs on this activation, and let it default for expiry (24 hours). 

When it’s done, we’ll be met with a confirmation screen here, where we’ll need to copy down our Activation Code and Activation ID. We can see how many instances are registered, and the limit, as well as when the activation will expire. 

Now we take the Activation code and ID from earlier, as well as the region we want the server/VM to be managed in and replace the red text where appropriate.

$code = "activation-code"
$id = "activation-id"
$region = "region"
$dir = $env:TEMP + "\ssm"
New-Item -ItemType directory -Path $dir -Force
cd $dir
(New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.amazonaws.com/latest/windows_amd64/AmazonSSMAgentSetup.exe", $dir + "\AmazonSSMAgentSetup.exe")
Start-Process .\AmazonSSMAgentSetup.exe -ArgumentList @("/q", "/log", "install.log", "CODE=$code", "ID=$id", "REGION=$region") -Wait
Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")
Get-Service -Name "AmazonSSMAgent"

We can open an elevated Windows PowerShell for AWS and input this information. We needed to input credentials as we didn’t have a credentials file in Windows. After some time, it will finish by outputting the Managed Instance ID. 

We can also go check back in the Systems Manager Console under Shared Resources and make sure the instance IDs match. It will also provide a name, show us that it’s reachable, and what OS we are running on that machine. 

At this point we can now use the Systems Manager features on this Managed instance. Unfortunately, since this is relatively new, Run-Command is the only fully working feature right now. Session manager is being worked on as noted on an AWS blog in Sept 2018. Let’s check out Run-Command found under Actions. Let’s select AWS-InstallMissingWindowsUpdates. We’ll choose Important for our Update Level, and select our target as our new Managed Instance. 

After lettings this run for a little bit, we should notice that the VM has rebooted and applied the relevant updates. We can also check the Step 1 output once we have a successful run.

Here we see that KB2267602 has successfully installed. It was the only one marked as Important in the list of available updates. There’s some other run commands you can select from the documents as well, such as AWS-RunPowerShellScript. We’ll jump into set-up for Linux-based systems next.

 

Linux

We can fill out a name, how many instances we’d like this activation to work for, and an expiry date anytime within the next 30 days. We’ll just describe the activation, allow up to 12 Servers/VMs on this activation, and let it default for expiry (24 hours). 

When it’s done, we’ll be met with a confirmation screen here, where we need to copy down our Activation Code and Activation ID. We can see how many instances are registered, and the limit, as well as when the activation will expire. 

Now that we have an activation ready, we will find what command block to run here. We’re using Ubuntu, so our commands will be as follows. Make sure to replace the red text with your activation code, id, and the region you want to manage these in.

mkdir /tmp/ssm
curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/
amazon-ssm-agent.deb -o /tmp/ssm/amazon-ssm-agent.deb
sudo dpkg -i /tmp/ssm/amazon-ssm-agent.deb
sudo service amazon-ssm-agent stop
sudo amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region" 
sudo service amazon-ssm-agent start

We can see that the service is installed and we are given a managed instance ID. We should now be able to go back to Shared Resources > Managed Instances in Amazon and see our new linux instance. 

 

Let’s go to Run Command and try something out on this new AWS managed instance. We can select the AWS-RunShellScript document and do a very basic sudo apt-get update -y.

Let’s select our managed on-premise linux VM we just set up and click on run, leaving default settings. After a short bit we can see it succeed, we can click on the instance ID and view the output under Step 1. 

There we have it, control of our on-premise servers and VMs from the ease of the Amazon Console. Now with SSM agent on your on-premise machines, you can use Console, AWSCLI, and API to keep your hybrid environment in check! Tune into our next blog to learn about how to keep your Systems Manager instances up to spec with Package Manager.


If you would like assistance with AWS Systems Manager agent, feel free to reach out to BlueChipTek Cloud Services team