Unable to start a new session as ssm-user with runAS option

[gurpalw]

Reopening #217.

Without "run as" option the "ssm-user" is created during the first session. If I configure SSM and set "run as" and as default user use "ssm-user" I'm unable to login into new vm's.
I get an error "Unable to start shell: failed to start pty since RunAs user ssm-user does not exist"

Fix PR here: #394

[yuting-fan]

This is expected behavior. If "run as" feature is not enabled, Session Manager will create ssm-user for you in the first session created; if "run as" feature is used, the "run-as" user is directly used. That said, if you want to "run as" ssm-user or any user, you would need to create that user on the system first.

The default "run as" user is ssm-user. So if you want to run as ssm-user, there is no need to specify it in the preferences.

[gurpalw]

This is expected behavior. If "run as" feature is not enabled, Session Manager will create ssm-user for you in the first session created; if "run as" feature is used, the "run-as" user is directly used. That said, if you want to "run as" ssm-user or any user, you would need to create that user on the system first.

The default "run as" user is ssm-user. So if you want to run as ssm-user, there is no need to specify it in the preferences.

I'm not specifying it in the preferences. it's specified via tags on the IAM user as outlined here: https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html

A non admin user is being set in preferences as the default. If the IAM user however is tagged with runAs = ssm-user then it should create the account.

[yuting-fan]

It's the same. If you use Session Manager to start a session on the same host without RunAs configured for the first time, then Session Manager will create ssm-user on the host on your behalf. If you have not done so, and directly attempt to run as "ssm-user", either through preferences or the IAM user tag, the user must exist first. Hope this clarifies the confusion.

Cheers,
Yuting

[gurpalw]

yes, but why is this the default behaviour? The issue here: #217 is basically that the default behaviour is stupid.

[akulihin]

The workaround for this is to create "ssm-user" yourself in the cloud-init script.
Add the following code to your cloud-init script:

# Creating ssm-user user
sudo useradd -m ssm-user -s /bin/sh;
sudo passwd --delete ssm-user;

#Allow ssm-user user to be root
sudo echo "ssm-user ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/ssm-agent-users;

If you are using terraform this would be in your "user_data_base64"