AWS SSM connection user is always root #853
Comments
|
I've run into this as well -- it appears that ssm is invoking python with sudo every single time, which is not ideal. I've tried: become: falseand become: true
become_user: someone_elseand they appear to have no affect. Of course if I remove ssm-user's ability to |
ansibullbot
added
bug
|
(edit) By default, the user always does seem to be become: true
become_user: someone_elseIf buser != ruserFor ansible-core < 2.13, Thus, with AWS SSM, avoid using Documentation below is my prior findings. However, using become: true
become_user: someone_elseI'm not sure where the change is in the upstream ansible project, but I suspect it must have to do with either the Using the following: On 2.12.7, I see: But with 2.13.0, I see: |
|
I came across this issue today as well. I'm pretty sure is the same case since I'm running ansible as "runner" user and the target host I'm trying to access also has a become_user statement as the "runner" user. Running latest ansible core and latest community.aws |
|
https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html With SSM the user you connect as is controlled by the SSM agent as installed on the target host. This is simply how the SSM agent works. By default this initial user will be the Once connected, Ansible defaults to running sudo to become the I'm going to keep this issue open as a documentation bug. However, I don't think it's correct to change the behaviour from today's behaviour. |
I use SSM on the command line daily and it uses the user I specify on command line. As previously mentioned it looks like this was also working as desired in a previous version. That doesn't sound like a documentation bug to me. But if that is the decision going forwards then I will work around it. |
|
If you've got it working then feel free to supply example commands. I'll concede that the AWS documentation isn't the greatest and it's possible I've overlooked something. The only documentation I can find that refers to managing which user you connect as talks about needing to apply the "SSMSessionRunAs" tag to IAM Users/Roles and doesn't talk about selecting the user on the fly. Please note: that the plugin is using SSM sessions, not SSM commands. |
|
I ran across this problem when experimenting with the aws_ssm connection plugin. I am running ansible v2.9.25 and noticed that many of my playbooks that run fine over SSH were failing with errors when run with aws_ssm. I dug into the source of aws_ssm and to me it seems aws_ssm is incorrectly prepending sudo when sudoable=True is being passed. From my testing, sudoable=True is sent even when become is not being used. For example the facts modules will send sudoable=True even though become is not used. This causes facts to come back for "root" instead of the login user. Removing the if statement in _wrap_command that prepends sudo has fixed the issue for me completely. My tasks that run with become still run sudo appropriately, and all my others do not. While reading over the docs in ansible 2.9.25 for ConnectionBase it mentions that sudoable is a flag to tell the connection plugin that become is being used. I interpret that to mean become is being handled elsewhere, and should not be done in the connection plugin. All of that said I am running aws_ssm (5.2.0) on an old version of ansible (2.9.25) so this fix may not be appropriate for general use. |
fixes: ansible-collections#853 The aws_ssm connection plugin was prepending additional `sudo` calls to most commands executed. This resulted in commands generally being executed as the `root` user, even when `become` was set to `False`.
fixes: ansible-collections#853 The aws_ssm connection plugin was prepending additional `sudo` calls to most commands executed. This resulted in commands generally being executed as the `root` user, even when `become` was set to `False`.
fixes: ansible-collections#853 The aws_ssm connection plugin was prepending additional `sudo` calls to most commands executed. This resulted in commands generally being executed as the `root` user, even when `become` was set to `False`.
aws_ssm - Drop extra sudo call on most commands. fixes: #853 SUMMARY The aws_ssm connection plugin was prepending additional sudo calls to most commands executed. This resulted in commands generally being executed as the root user, even when become was set to False. ISSUE TYPE Bugfix Pull Request COMPONENT NAME aws_ssm ADDITIONAL INFORMATION Reviewed-by: Alina Buzachis <None>
Summary
When using the
aws_ssmconnection plugin the user always seems to be root. When running commands that create files (such ascommunity.general.bundler) they become owned as root. The executed commands appear to be run using sudo as opposed to a regular connection.Issue Type
Bug Report
Component Name
aws_ssm
Ansible Version
Collection Versions
AWS SDK versions
Configuration
OS / Environment
Controller: Ubuntu 20.04
Host: Ubuntu 20.04
Steps to Reproduce
ansible -i inventory/inventory_public_aws_ec2.yml -u myuser -m shell -a "env" -vvv i-050cea982611bb1e3Expected Results
Environment should have the user I connect with as
USER:Actual Results
User is
rootwith sudo tomyuser.Code of Conduct
The text was updated successfully, but these errors were encountered: