- Newest
- Most votes
- Most comments
Thank you for your questions about configuring the Amazon SSM Agent for your on-premises server. I'll address your concerns one by one:
-
Running SSM Agent as a non-root user: By default, the SSM Agent runs as root on Linux systems for maximum functionality. While it's possible to run the agent as a non-root user, this is not officially supported and may limit some of the agent's capabilities. Running as a non-root user, even with sudo privileges, could potentially cause issues with certain Systems Manager operations that require root access. If you decide to proceed, you would need to modify the systemd service file for amazon-ssm-agent and change the user it runs as. However, this is not recommended as it may lead to unexpected behavior or reduced functionality.
-
Changing the location of executed scripts: The SSM Agent uses predefined directories for its operations, including script execution. The directory /var/lib/amazon/ssm/ is the default location for temporary files and scripts. Unfortunately, there isn't a built-in configuration option to change this location. The agent is designed to work with these specific directories for security and consistency reasons.
If you have specific security or compliance requirements that necessitate these changes, you might need to consider alternative solutions or custom implementations. However, modifying the core behavior of the SSM Agent is not recommended as it could lead to instability, reduced functionality, or issues with future updates.
For the most secure and reliable operation, it's generally best to use the SSM Agent with its default configuration. If you have specific security concerns, you might want to explore other AWS security features or consult with AWS Support for guidance on how to meet your specific requirements while maintaining the integrity of the SSM Agent's operations.
Sources
Install SSM Agent on hybrid Linux nodes - AWS Systems Manager
Working with SSM Agent - AWS Systems Manager
