Session Manager is a fully managed AWS Systems Manager capability that lets you manage your EC2 instances, on-premises instances, and virtual machines (VMs) through an interactive one-click browser-based shell or through the AWS CLI. Session Manager provides secure and auditable instance management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys. Session Manager also makes it easy to comply with corporate policies that require controlled access to instances, strict security practices, and fully auditable logs with instance access details, while still providing end users with simple one-click cross-platform access to your managed instances.
In order to establish a session, the IAM user or role must have Session Manager permissions as well as access to the target managed instances. At minimum, SSM Agent version 184.108.40.206 or later must be installed on the instances you want to connect to through sessions.
About the ssm-user account
Starting with version 220.127.116.11 of SSM Agent, the agent creates a local user account called
ssm-user and adds it to
/etc/sudoers (Linux) or to the Administrators group (Windows). On agent versions before 2.3.612.0, the account is created the first time SSM Agent starts or restarts after installation. On version 2.3.612.0 and later, the ssm-user account is created the first time a session is started on an instance. This
ssm-user is the default OS user when a Session Manager session is started.
If you want to prevent Session Manager users from running administrative commands on an instance, you can update the ssm-user account permissions. You can also restore these permissions after they have been removed. For more information, see Step 7: (Optional) disable or enable ssm-user account administrative permissions.
ssm-user on Windows Server domain controllers
Beginning with SSM Agent version 2.3.612.0, the
ssm-user account is not created automatically on managed instances that are used as Windows Server domain controllers. To use Session Manager on a Windows Server machine being used as a domain controller, you must create the
ssm-user account manually if it isn’t already present. On Windows Server, SSM Agent sets a new password for the
ssm-user account each time a session starts, so you do not need to specify a password when you create the account.
In this lab we will utilize Session Manager to connect to our Web instances that we ran our Command document against.
Switch back to the tab with your active session and type following commands:
cd /app ls
You can see our text file
hello.txt created by the Run Command document in the previous section.
systemctl status httpd
Apache is now running per our document instructions.
Select Terminate to close the session.
Go back to Session Manager and select refresh. You can see the session was ended and there are no running sessions.
Select the Session History tab.
You will see your previous session in a
We will now configure session logging for CloudWatch Logs.
Systems-Manager-Workshopand choose Create.
For Send Session output to CloudWatch Logs, select
CloudWatch logs to enable writting session output to CloudWatch Logs.
Now that we have enabled writting session output to CloudWatch Logs, repeat steps 4-8 to see the session output within CloudWatch Logs.
Select the Session History tab.
Terminatingstate for 1-3 minutes as the history is sent to CloudWatch Logs for storage.
Once the status is
Terminated, select the output location CloudWatch Logs.
In CloudWatch Logs you will see that inside your Systems Manager Log Group a new Log Stream was created and utilized the ID of the Session Manager session you just ended.
Expand the messages and you will see a full output of the terminal session.
This is a powerful integration because now you have an easy interface to: