Installing SSM Agent on Managed instance

DevOps
Liron Shemer

Installing SSM Agent on Managed instance

Please review the below. Hope there won't be to much questions about you can try it yourself and give your feedback.

Working with SSM Agent

AWS Systems Manager Agent (SSM Agent) is Amazon software that runs on Amazon Elastic Compute Cloud (Amazon EC2) instances, edge devices, and on-premises servers and virtual machines (VMs). SSM Agent makes it possible for Systems Manager to update, manage, and configure these resources. The agent processes requests from the Systems Manager service in the AWS Cloud, and then runs them as specified in the request. SSM Agent then sends status and execution information back to the Systems Manager service by using the Amazon Message Delivery Service (service prefix: ec2messages).

For more information click here

SSM Agent Installation

AWS Systems Manager Agent (SSM Agent) is preinstalled, by default, on the following Amazon Machine Images (AMIs):

  • Windows Server 2008-2012 R2 AMIs published in November 2016 or later
  • Windows Server 2016 and 2019
  • Amazon Linux
  • Amazon Linux 2
  • Amazon Linux 2 ECS-Optimized Base AMIs
  • SUSE Linux Enterprise Server (SLES) 12 and 15
  • Ubuntu Server 16.04, 18.04, and 20.04

In case you are using a custom image which SSM agent is not preinstalled under, please refer to the following document for guidelines

https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html

Scenarios to start working with AWS SSM

Please refer to the following scenarios to make sure that SSM Agent will be able to communicate with AWS SSM.

  • Adding an IAM policy to an existing EC2 Instance with an existing Role
  • Attaching the AWS managed role for SSM to a running instance
  • Create your own role with required SSM policy

Adding an IAM policy to an existing EC2 Instance with an existing Role

Follow this scenario when you have a running EC2 instance with an existing role attached to it.

  • Go to the desired EC2 Instance and select it.
  • In the Details panel click on your existing IAM Role for EC2 and then click on the IAM Role
  • Verify that you are in Identity and Access Management (IAM) section in AWS console and on the selected role.
  • Click Attach policies and add search for the AmazonSSMManagedInstanceCore policy and add it to your role.

Attaching the AWS managed role for SSM to a running instance

Follow this scenario when you have a running EC2 instance without an attached IAM role.

  • Go to the desired EC2 Instance and select it.
  • Click on Actions > Security > Modify IAM role
  • Click on the drop down and search for AmazonSSMRoleForInstancesQuickSetup
  • Select AmazonSSMRoleForInstancesQuickSetup role and click Save

Create your own role with required SSM policy

Follow this scenario when you want to create your own custom IAM role with support for SSM.

  • Navigate to IAM
  • On the navigation panel click on Roles
  • Click Create role location on the right top section of the screen
  • In the Create role page select EC2 located under Common use cases
  • Click Next: Permissions
  • Search for AmazonSSMManagedInstanceCore policy and selected it.
  • Optional: Add any other required policy in case needed. This is not required for the SSM setup
  • Click Next: Tags
  • Optional: add Key Value tag as you see it feet
    • Example: Key=Email, Value=<Your Siemens Email Address>
  • Click Next: Review
  • Enter a name for your new role, located under the Role name field
  • Click Create role

You have successfully created your new role.

to attached your new role to the running EC2. Make sure you select your role name and not the AmazonSSMRoleForInstancesQuickSetup which mentioned in the section.

Verify SSM Agent is installed on your instance

Once attached the relevant IAM role to the instance you need to go the SSM portal in AWS:

  • Navigate to SSM
  • On the navigation panel under Node Management click on Inventory
  • scroll down to Corresponding managed instances and verify the instance is in the table:

*Troubleshooting SSM Agent

Follow this scenario when after attaching the exact role for relevant instance, the instance itself won't show up under Corresponding managed instances:

  • Connect with RDP session into the instance and check the logs information in the following files:

On Windows

%PROGRAMDATA%\Amazon\SSM\Logs\amazon-ssm-agent.log

%PROGRAMDATA%\Amazon\SSM\Logs\errors.log

On Linux and macOS

/var/log/amazon/ssm/amazon-ssm-agent.log

/var/log/amazon/ssm/errors.log

For Linux managed nodes, you might find more information in the messages file written to the following directory: /var/log.

  • Verify the SSM Agent service is running under services.msc:

           On Linux: sudo systemctl status amazon-ssm-agent

  • If there is an error logs, the service won't run try to install it manually from the instance itself:

Refer to the document of: https://fitdevops.in/install-ssm-agent-on-windows-ec2-instances/ https://fitdevops.in/install-ssm-agent-on-linux-ec2-instances/

Windows:

Open PowerShell as administrator an run:

Invoke-WebRequest https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/windows_amd64/AmazonSSMAgentSetup.exe -OutFile $env:USERPROFILE\Desktop\SSMAgent_latest.exe

After that run the command to start the agent:

Start-Process -FilePath $env:USERPROFILE\Desktop\SSMAgent_latest.exe -ArgumentList "/S"

Linux (only for Amazon Linux 2, if there is other OS please refer to the document above:

sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

After that run the command to start the agent:

sudo systemctl start amazon-ssm-agent

Check the status of the running agent:

sudo systemctl status amazon-ssm-agent

Wait for 5 min until checking if its appears in the SSM portal (under inventory)

  • If it still doesn't, most likely is connectivity to SSM endpoints on port 443 (check the local FW is blocking it or on the OS itself) and try the following:

Verify connectivity to Systems Manager endpoints on port 443

The best method to verify connectivity depends on your operating system.

For EC2 Linux instances: You can use either telnet or netcat commands to verify connectivity to endpoints on port 443.

Telnet

telnet ssm.RegionID.amazonaws.com 443
telnet ec2messages.RegionID.amazonaws.com 443
telnet ssmmessages.RegionID.amazonaws.com 443

Example successful connection:

root@111800186:~# telnet ssm.us-east-1.amazonaws.com 443
Trying 52.46.141.158…
Connected to ssm.us-east-1.amazonaws.com.
Escape character is '^]'.

To exit from telnet, hold down the Ctrl key and press the ] key. Enter quit, and then press Enter.

Netcat

nc -vz ssm.RegionID.amazonaws.com 443
nc -vz ec2messages.RegionID.amazonaws.com 443
nc -vz ssmmessages.RegionID.amazonaws.com 443

Note: Netcat isn't preinstalled on Amazon EC2 instances. To manually install Netcat, see Ncat on the Nmap website.

For EC2 Windows instances: You can use the following Windows PowerShell commands to verify connectivity to endpoints on port 443:

Test-NetConnection ssm.RegionID.amazonaws.com -port 443
Test-NetConnection ec2messages.RegionID.amazonaws.com -port 443
Test-NetConnection ssmmessages.RegionID.amazonaws.com -port 443

Important note! If its private machine (without internet connectivity):

For private subnets, your instance must be able to reach the internet using a NAT gateway. Or, you can configure VPC endpoints to reach Systems Manager endpoints for instances in a private subnet. This allows you to privately access Amazon EC2 and Systems Manager APIs using private IP addresses. For more information, see How do I create VPC endpoints so that I can use Systems Manager to manage private EC2 instances without internet access?

Verify connectivity to the instance metadata service

SSM Agent must communicate with the instance metadata service to get necessary information about the instance. Use the Netcat command to test the connection:

nc -vz 169.254.169.254 80

  • If it still doesn't, most troubleshoot I saw is on Windows machine (with old image) that where installed again in different subnet so the machine gateway is different from the actual need and that’s why the agent can't respond to the metadata of its own:
    • Open PowerShell and right the command:
      • Route print

Verify that the Network Destination of address 169.254.169.250(251,254) below is direct to the right Gateway and not to strange address for example 192.168.*.* (the picture is the correct configuration):

  • You can use the script of Amazon in order to fix it:
  • Import-Module "C:\ProgramData\Amazon\EC2-Windows\Launch\Module\Ec2Launch.psm1"; Add-Routes
  • Or Manually:

route -p delete 169.254.169.250

​route -p delete 169.254.169.251

route -p delete 169.254.169.254

route -p ADD 169.254.169.250 MASK 255.255.255.255 10.0.30.65

route -p ADD 169.254.169.251 MASK 255.255.255.255 10.0.30.65

route -p ADD 169.254.169.254 MASK 255.255.255.255 10.0.30.65

Again: Wait for 5 min until checking if its appears in the SSM portal (under inventory)

  • Finally, If it still doesn't appear under managed instances in the SSM portal, open a support ticket under support portal with your AWS account 🙂

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

Related Posts

Back To Top

Terms and Conditions