New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New become_method option: sudo su - <user> #12686

Closed
lucymhdavies opened this Issue Oct 8, 2015 · 36 comments

Comments

Projects
None yet
@lucymhdavies

lucymhdavies commented Oct 8, 2015

ISSUE TYPE
  • Feature Idea
COMPONENT NAME

core

ANSIBLE VERSION
2.1
CONFIGURATION
OS / ENVIRONMENT
SUMMARY

Found #8650, which was rejected as Possible Misunderstanding

We have this same issue too.

We want to use Ansible to control a system, but the system we wish to log in to is not controlled by us, and has very strict permissions.

Specifically, the only way we can run commands on the system is with

sudo su - <user>

or

sudo su - <user> -c <command>

Alas, this is not an available become_method.

Is there any chance of getting this option added?

STEPS TO REPRODUCE
EXPECTED RESULTS
ACTUAL RESULTS
@taspotts

This comment has been minimized.

Show comment
Hide comment
@taspotts

taspotts Oct 15, 2015

I've got the same issue on systems with very tight security. The only way to run some commands is sudo su -

Is there any work around available for this?

taspotts commented Oct 15, 2015

I've got the same issue on systems with very tight security. The only way to run some commands is sudo su -

Is there any work around available for this?

@barleyj

This comment has been minimized.

Show comment
Hide comment
@barleyj

barleyj Oct 23, 2015

I also have the same issue. I need to run a command as a specific user but I can only become that user with 'sudo su - user'

barleyj commented Oct 23, 2015

I also have the same issue. I need to run a command as a specific user but I can only become that user with 'sudo su - user'

@abevoelker

This comment has been minimized.

Show comment
Hide comment
@abevoelker

abevoelker Nov 2, 2015

The default sudoers file on Google Compute Engine requires a password for sudo -u (it doesn't for plain sudo), so this would be pretty useful for me as well.

abevoelker commented Nov 2, 2015

The default sudoers file on Google Compute Engine requires a password for sudo -u (it doesn't for plain sudo), so this would be pretty useful for me as well.

@naktinis

This comment has been minimized.

Show comment
Hide comment
@naktinis

naktinis Dec 3, 2015

Yup, useful here as well. In our current configuration running with sudo: yes together with shell: su username -c command works fine and doesn't ask for a password. However, running this with become: yes, become_user: username with shell: command, on the other hand, asks for a password.

naktinis commented Dec 3, 2015

Yup, useful here as well. In our current configuration running with sudo: yes together with shell: su username -c command works fine and doesn't ask for a password. However, running this with become: yes, become_user: username with shell: command, on the other hand, asks for a password.

@naktinis

This comment has been minimized.

Show comment
Hide comment
@naktinis

naktinis Dec 4, 2015

To explain a little better, why sudo su user -c command might work without a password while sudo -u user command won't, could have to do with sudoers configuration. If you have something like ALL=NOPASSWD:ALL, become: yes will use sudo -u root and this will work fine, but become_user: user will run sudo -u user and that will require a password. If you have access to your sudoers file, you can change it to allow using sudo to become any user, but if you don't, then sudo su option does sound reasonable.

naktinis commented Dec 4, 2015

To explain a little better, why sudo su user -c command might work without a password while sudo -u user command won't, could have to do with sudoers configuration. If you have something like ALL=NOPASSWD:ALL, become: yes will use sudo -u root and this will work fine, but become_user: user will run sudo -u user and that will require a password. If you have access to your sudoers file, you can change it to allow using sudo to become any user, but if you don't, then sudo su option does sound reasonable.

@bcoca

This comment has been minimized.

Show comment
Hide comment
@bcoca

bcoca Dec 5, 2015

Member

you can configure sudo to do the same:

ALL=(user) NOPASSWD:ALL

and this will work with ansible as it will do:
sudo -u user command
which effectively is
sudo su - user -c command

Member

bcoca commented Dec 5, 2015

you can configure sudo to do the same:

ALL=(user) NOPASSWD:ALL

and this will work with ansible as it will do:
sudo -u user command
which effectively is
sudo su - user -c command

@naktinis

This comment has been minimized.

Show comment
Hide comment
@naktinis

naktinis Dec 5, 2015

Yes, that is exactly what I'm referring to in my previous comment. The problem, as I've said, however, still remains for users that don't have access to the sudoers file.

naktinis commented Dec 5, 2015

Yes, that is exactly what I'm referring to in my previous comment. The problem, as I've said, however, still remains for users that don't have access to the sudoers file.

@jimi-c jimi-c removed the P3 label Dec 7, 2015

@cpaulraj

This comment has been minimized.

Show comment
Hide comment
@cpaulraj

cpaulraj Jan 6, 2016

Has anyone got sudo su together working? I am not an admin, don't have access to sudoers file. Not able to sudo with su option is a major road block for me to use ansible. I am trying to use ansible for middleware patch maintenance and house keeping. Any advise to get this working would be a great help.

cpaulraj commented Jan 6, 2016

Has anyone got sudo su together working? I am not an admin, don't have access to sudoers file. Not able to sudo with su option is a major road block for me to use ansible. I am trying to use ansible for middleware patch maintenance and house keeping. Any advise to get this working would be a great help.

@ntkoopman

This comment has been minimized.

Show comment
Hide comment
@ntkoopman

ntkoopman Jan 8, 2016

I created a very simple patch at #13764

ntkoopman commented Jan 8, 2016

I created a very simple patch at #13764

@margielm

This comment has been minimized.

Show comment
Hide comment
@margielm

margielm Jan 22, 2016

Same problem here. And I just wasted 2 hours on figuring out what is going on.

margielm commented Jan 22, 2016

Same problem here. And I just wasted 2 hours on figuring out what is going on.

@belooussov

This comment has been minimized.

Show comment
Hide comment
@belooussov

belooussov Feb 27, 2016

This would certainly help in some situations.

belooussov commented Feb 27, 2016

This would certainly help in some situations.

@ntkoopman

This comment has been minimized.

Show comment
Hide comment
@ntkoopman

ntkoopman Feb 27, 2016

You can work around this by setting become_method="su" and become_exe="sudo su"

ntkoopman commented Feb 27, 2016

You can work around this by setting become_method="su" and become_exe="sudo su"

@bbaassssiiee

This comment has been minimized.

Show comment
Hide comment
@bbaassssiiee

bbaassssiiee Feb 29, 2016

Member

How about suexec su -u user -c command [args ...]?

Member

bbaassssiiee commented Feb 29, 2016

How about suexec su -u user -c command [args ...]?

@ntkoopman

This comment has been minimized.

Show comment
Hide comment
@ntkoopman

ntkoopman Feb 29, 2016

Probably
become_method="su"
become_exe="suexec su"
become_flags="-u"

ntkoopman commented Feb 29, 2016

Probably
become_method="su"
become_exe="suexec su"
become_flags="-u"

@lucymhdavies

This comment has been minimized.

Show comment
Hide comment
@lucymhdavies

lucymhdavies Mar 1, 2016

Following advice in #13764

[jumpbox]
<HOSTNAME> ansible_ssh_host=<IP ADDRESS> ansible_become_method=su ansible_become_exe="sudo su -" 

into our hosts file...

Worked first time.

Thanks to @ntkoopman who suggested this. :)

So unless anybody else is interested in a dedicated Ansible config for this, I'm fine with this issue being resolved.

lucymhdavies commented Mar 1, 2016

Following advice in #13764

[jumpbox]
<HOSTNAME> ansible_ssh_host=<IP ADDRESS> ansible_become_method=su ansible_become_exe="sudo su -" 

into our hosts file...

Worked first time.

Thanks to @ntkoopman who suggested this. :)

So unless anybody else is interested in a dedicated Ansible config for this, I'm fine with this issue being resolved.

@idzuwan

This comment has been minimized.

Show comment
Hide comment
@idzuwan

idzuwan Mar 2, 2016

@ntkoopman
the work around only work if sudoers files are set to

ALL=(user) NOPASSWD:ALL

but if the sudoers are set to this as an example:

ALL=(user) NOPASSWD: /bin/su -

the workaround will no longer works, as ansible normally will try to run

sudo /bin/su - '/bin/sh -c '

although it will work if you set sudoers to

ALL=(user) NOPASSWD: /bin/su - *

but most cases normal user are not allowed to change the defaults config

idzuwan commented Mar 2, 2016

@ntkoopman
the work around only work if sudoers files are set to

ALL=(user) NOPASSWD:ALL

but if the sudoers are set to this as an example:

ALL=(user) NOPASSWD: /bin/su -

the workaround will no longer works, as ansible normally will try to run

sudo /bin/su - '/bin/sh -c '

although it will work if you set sudoers to

ALL=(user) NOPASSWD: /bin/su - *

but most cases normal user are not allowed to change the defaults config

@zielik

This comment has been minimized.

Show comment
Hide comment
@zielik

zielik May 12, 2016

In sudoers file I have only
%user ALL=(ALL) NOPASSWD: /bin/su - jboss

How can I sudo to jboss and then run some command?
I tried something like
- become: yes
become_user: "jboss"
raw: "touch test"
or
raw: "sudo su - jboss -c ls"
but always ended:
Sorry, user is not allowed to execute 'command' as jboss

zielik commented May 12, 2016

In sudoers file I have only
%user ALL=(ALL) NOPASSWD: /bin/su - jboss

How can I sudo to jboss and then run some command?
I tried something like
- become: yes
become_user: "jboss"
raw: "touch test"
or
raw: "sudo su - jboss -c ls"
but always ended:
Sorry, user is not allowed to execute 'command' as jboss

@idzuwan

This comment has been minimized.

Show comment
Hide comment
@idzuwan

idzuwan May 13, 2016

you sudoers roles need to be:

%user ALL=(ALL) NOPASSWD: /bin/su - jboss *

as normally ansible user is granted full access like this rules:

%user ALL=(ALL) NOPASSWD: ALL

idzuwan commented May 13, 2016

you sudoers roles need to be:

%user ALL=(ALL) NOPASSWD: /bin/su - jboss *

as normally ansible user is granted full access like this rules:

%user ALL=(ALL) NOPASSWD: ALL

@bcoca

This comment has been minimized.

Show comment
Hide comment
@bcoca

bcoca May 13, 2016

Member

To run any command as a specific user:

%user ALL=(jboss) NOPASSWD: ALL

which removes the need for su


Brian Coca

Member

bcoca commented May 13, 2016

To run any command as a specific user:

%user ALL=(jboss) NOPASSWD: ALL

which removes the need for su


Brian Coca

@bbaassssiiee

This comment has been minimized.

Show comment
Hide comment
@bbaassssiiee

bbaassssiiee May 13, 2016

Member

The sudoers file is complex, sensitive to security errors like shell escapes, and poorly understood. This has led to a practice of granting all permissions/or none, while a granular approach is possible with sudo. Corporate rules dictate that
Ansible impersonates the NPA of the application, but we need more privileges for the application to exist. The community needs more examples of combining Ansible and sudo, with specific rights. For instance a generic list of commands for application deployment?

Member

bbaassssiiee commented May 13, 2016

The sudoers file is complex, sensitive to security errors like shell escapes, and poorly understood. This has led to a practice of granting all permissions/or none, while a granular approach is possible with sudo. Corporate rules dictate that
Ansible impersonates the NPA of the application, but we need more privileges for the application to exist. The community needs more examples of combining Ansible and sudo, with specific rights. For instance a generic list of commands for application deployment?

@sivel

This comment has been minimized.

Show comment
Hide comment
@sivel

sivel May 13, 2016

Member

@bbaassssiiee part of the difficulty there, is that ansible executes a shell with sudo permissions, such as sudo -H -S -u USERNAME /bin/sh -c '/usr/bin/python' (it gets a little more complicated than that, but that is an example). This is partially due to the fact that the system commands that ansible runs are run from within a python file. Additionally there are not always commands that are run, it may be part of native python ability to manipulate files and such (which couldn't be restricted).

Due to opening up /bin/sh for execution via sudo, there is at that point no sense in that restriction, as someone executing /bin/sh via sudo then has access to run any command anyway. The recommendation is to grant access for ansible to run any command via sudo.

Member

sivel commented May 13, 2016

@bbaassssiiee part of the difficulty there, is that ansible executes a shell with sudo permissions, such as sudo -H -S -u USERNAME /bin/sh -c '/usr/bin/python' (it gets a little more complicated than that, but that is an example). This is partially due to the fact that the system commands that ansible runs are run from within a python file. Additionally there are not always commands that are run, it may be part of native python ability to manipulate files and such (which couldn't be restricted).

Due to opening up /bin/sh for execution via sudo, there is at that point no sense in that restriction, as someone executing /bin/sh via sudo then has access to run any command anyway. The recommendation is to grant access for ansible to run any command via sudo.

@bbaassssiiee

This comment has been minimized.

Show comment
Hide comment
@bbaassssiiee

bbaassssiiee May 13, 2016

Member

Our idea here is that the account that is used to run ansible is set up in such a way that it can only run ansible, or at least that it encourages running ansible. This is to change people's habits of using a generic account to do changes in an untracable way. Changes should be codified, stored in Git, and tested.

I expanded the idea of the 'logout' in ~/.bash_profile in a repo on github.
https://github.com/bbaassssiiee/restrict.git

The restricted shell limits setting PATH, changing directories and using slashes in command names. This helps reducing what you can do with the account that runs ansible, if you would have the keys. To make it work the executable in ansible.cfg should be rbash. In the example line 45 of roles/restrict/tasks/main.yml should have rbash. While working on it I found that Ansible cannot use the restricted shell (rbash) because of a redirect to /dev/null in the remote commands that execute the plays.
The way out would be to replace using the shell_plugin with a rbash_plugin, I call for help.

Those commands also have randomized directory names in them that block using 'force-command' in SSH authorized_keys.
Pipelining does not seem to help solving this.

Member

bbaassssiiee commented May 13, 2016

Our idea here is that the account that is used to run ansible is set up in such a way that it can only run ansible, or at least that it encourages running ansible. This is to change people's habits of using a generic account to do changes in an untracable way. Changes should be codified, stored in Git, and tested.

I expanded the idea of the 'logout' in ~/.bash_profile in a repo on github.
https://github.com/bbaassssiiee/restrict.git

The restricted shell limits setting PATH, changing directories and using slashes in command names. This helps reducing what you can do with the account that runs ansible, if you would have the keys. To make it work the executable in ansible.cfg should be rbash. In the example line 45 of roles/restrict/tasks/main.yml should have rbash. While working on it I found that Ansible cannot use the restricted shell (rbash) because of a redirect to /dev/null in the remote commands that execute the plays.
The way out would be to replace using the shell_plugin with a rbash_plugin, I call for help.

Those commands also have randomized directory names in them that block using 'force-command' in SSH authorized_keys.
Pipelining does not seem to help solving this.

@mohanrao

This comment has been minimized.

Show comment
Hide comment
@mohanrao

mohanrao Aug 15, 2016

Is there any workaround to solve this issue?

In am dealing with an environment where i have to do sudo su - <sudo_user> and enter the password.

Any solution how to achieve this Ansible ??

mohanrao commented Aug 15, 2016

Is there any workaround to solve this issue?

In am dealing with an environment where i have to do sudo su - <sudo_user> and enter the password.

Any solution how to achieve this Ansible ??

@ansibot ansibot added the affects_2.1 label Sep 8, 2016

@cpaulraj

This comment has been minimized.

Show comment
Hide comment
@cpaulraj

cpaulraj Sep 14, 2016

I gave up on this issue and worked with our admins to have trusted host connection setup.

cpaulraj commented Sep 14, 2016

I gave up on this issue and worked with our admins to have trusted host connection setup.

@BondAnthony

This comment has been minimized.

Show comment
Hide comment
@BondAnthony

BondAnthony Oct 27, 2016

Contributor

This would be a great feature to have or at least a workaround. Not being able to run sudo su - limits my usage of Ansible in my current environment.

Contributor

BondAnthony commented Oct 27, 2016

This would be a great feature to have or at least a workaround. Not being able to run sudo su - limits my usage of Ansible in my current environment.

@hoesler

This comment has been minimized.

Show comment
Hide comment
@hoesler

hoesler Dec 21, 2016

I had the sudo restriction of only being able to do sudo su - root and found a workaround for me to use ansible with privilege escalation.

I distributed a shell script ~/bin/asroot with the following content:

#!/bin/bash

cmd=''
for i in "$@"; do 
    i="${i//\\/\\\\}"
    cmd="$cmd \"${i//\"/\\\"}\""
done

sudo su - root << END
$cmd
END

and added this to my .ansible.cfg:

[privilege_escalation]
become_method=sudo
become_exe="~/bin/asroot sudo"

hoesler commented Dec 21, 2016

I had the sudo restriction of only being able to do sudo su - root and found a workaround for me to use ansible with privilege escalation.

I distributed a shell script ~/bin/asroot with the following content:

#!/bin/bash

cmd=''
for i in "$@"; do 
    i="${i//\\/\\\\}"
    cmd="$cmd \"${i//\"/\\\"}\""
done

sudo su - root << END
$cmd
END

and added this to my .ansible.cfg:

[privilege_escalation]
become_method=sudo
become_exe="~/bin/asroot sudo"
@aimannajjar

This comment has been minimized.

Show comment
Hide comment
@aimannajjar

aimannajjar Jan 5, 2017

This has worked for me, in sudoers add:

%user ALL=(ALL) NOPASSWD: /bin/su - jboss *

Use su as the become_method and also use sudo su - as become_exe, the latter you can achieve by either specifying it in ansible.cfg file or as an environment variable when executing ansible:

ANSIBLE_BECOME_EXE="sudo su -" ansible-playbook -i  ... 

become_method can be specified at the playbook level.

aimannajjar commented Jan 5, 2017

This has worked for me, in sudoers add:

%user ALL=(ALL) NOPASSWD: /bin/su - jboss *

Use su as the become_method and also use sudo su - as become_exe, the latter you can achieve by either specifying it in ansible.cfg file or as an environment variable when executing ansible:

ANSIBLE_BECOME_EXE="sudo su -" ansible-playbook -i  ... 

become_method can be specified at the playbook level.

@ansibot

This comment has been minimized.

Show comment
Hide comment
@ansibot

ansibot Apr 4, 2017

Contributor

@lucymhdavies Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.

Here are the items we could not find in your description:

  • issue type
  • ansible version
  • component name

Please set the description of this issue with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

click here for bot help

Contributor

ansibot commented Apr 4, 2017

@lucymhdavies Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.

Here are the items we could not find in your description:

  • issue type
  • ansible version
  • component name

Please set the description of this issue with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

click here for bot help

@lucymhdavies

This comment has been minimized.

Show comment
Hide comment
@lucymhdavies

lucymhdavies Apr 4, 2017

Updated description in line with new template, for the benefit of ansibot.

I've moved company since raising this, so I no longer use Ansible, and no longer particularly care about this issue.

There are a few workarounds in here, one of which I've confirmed for myself.
#12686 (comment)

But as I'm no longer using Ansible myself (and wouldn't have this issue if I were to use it in future) I'm no longer following the issue, so won't be updating the description further.

lucymhdavies commented Apr 4, 2017

Updated description in line with new template, for the benefit of ansibot.

I've moved company since raising this, so I no longer use Ansible, and no longer particularly care about this issue.

There are a few workarounds in here, one of which I've confirmed for myself.
#12686 (comment)

But as I'm no longer using Ansible myself (and wouldn't have this issue if I were to use it in future) I'm no longer following the issue, so won't be updating the description further.

@ede-n

This comment has been minimized.

Show comment
Hide comment
@ede-n

ede-n May 8, 2017

I came across the same issue. The work around helped. Thank you.

ede-n commented May 8, 2017

I came across the same issue. The work around helped. Thank you.

@Nebel54

This comment has been minimized.

Show comment
Hide comment
@Nebel54

Nebel54 May 9, 2017

Just in case this does not get fixed:

I have another workaround which can be included directly in the task, just execute su manually instead of using become:

    - name: Execute inventory run.
      shell: su monitor -l -c "yourcommand -youroptions"

Nebel54 commented May 9, 2017

Just in case this does not get fixed:

I have another workaround which can be included directly in the task, just execute su manually instead of using become:

    - name: Execute inventory run.
      shell: su monitor -l -c "yourcommand -youroptions"
@keltik85

This comment has been minimized.

Show comment
Hide comment
@keltik85

keltik85 Feb 21, 2018

Ok for everyone who is interested and maybe has the same use case (ansible + vagrant). I solved it with the following magic:

my-user@my-host:~$ sudo vim /etc/ansible/hosts
----------------------------------------------------------------------
[my-vagrant-cluster:vars]
ansible_ssh_private_key_file = /home/my-user/.vagrant.d/insecure_private_key
ansible_ssh_user=vagrant
ansible_ssh_pass=vagrant
ansible_become=yes
ansible_become_method=su
ansible_become_exe="sudo su -"

[my-vagrant-cluster]
192.168.178.64
192.168.178.65
192.168.178.66
192.168.178.67
192.168.178.68
----------------------------------------------------------------------
my-user@my-host:~$ ansible my-vagrant-cluster -a "ls -all /root"
...
...ls on root folder works...
... have fun.....
...

Its working perfectly.

Note: This is only used in a development environment. If your using this in a production envi rn blablabalbabblablbabalbalbaalablablabab (dont use ansible or vagrant at all ;-) )

keltik85 commented Feb 21, 2018

Ok for everyone who is interested and maybe has the same use case (ansible + vagrant). I solved it with the following magic:

my-user@my-host:~$ sudo vim /etc/ansible/hosts
----------------------------------------------------------------------
[my-vagrant-cluster:vars]
ansible_ssh_private_key_file = /home/my-user/.vagrant.d/insecure_private_key
ansible_ssh_user=vagrant
ansible_ssh_pass=vagrant
ansible_become=yes
ansible_become_method=su
ansible_become_exe="sudo su -"

[my-vagrant-cluster]
192.168.178.64
192.168.178.65
192.168.178.66
192.168.178.67
192.168.178.68
----------------------------------------------------------------------
my-user@my-host:~$ ansible my-vagrant-cluster -a "ls -all /root"
...
...ls on root folder works...
... have fun.....
...

Its working perfectly.

Note: This is only used in a development environment. If your using this in a production envi rn blablabalbabblablbabalbalbaalablablabab (dont use ansible or vagrant at all ;-) )

@ansibot ansibot added feature and removed feature_idea labels Mar 2, 2018

@bravomail

This comment has been minimized.

Show comment
Hide comment
@bravomail

bravomail Mar 9, 2018

Here's what worked for me on ansible 2.4.0.
In the ansible.cfg I set my own su script
su_exe="/path/to/mysu.sh"

Here's script
#!/bin/ksh
#mysu.sh "user" -c "cmd"
if [ $# -lt 3 ]; then
echo 'Not enough arguments: mysu.sh "user" -c "cmd"' >&2
exit 1
fi
if [ x"-c" != x"$2" ]; then
echo 'Wrong 2nd arg: mysu.sh "user" -c "cmd"' >&2
exit 1
fi
printf '%s\n' "$3" | sudo su - "$1"

bravomail commented Mar 9, 2018

Here's what worked for me on ansible 2.4.0.
In the ansible.cfg I set my own su script
su_exe="/path/to/mysu.sh"

Here's script
#!/bin/ksh
#mysu.sh "user" -c "cmd"
if [ $# -lt 3 ]; then
echo 'Not enough arguments: mysu.sh "user" -c "cmd"' >&2
exit 1
fi
if [ x"-c" != x"$2" ]; then
echo 'Wrong 2nd arg: mysu.sh "user" -c "cmd"' >&2
exit 1
fi
printf '%s\n' "$3" | sudo su - "$1"

@brahim-raddahi

This comment has been minimized.

Show comment
Hide comment
@brahim-raddahi

brahim-raddahi Mar 15, 2018

Looks like newer versions of Ansible are expecting the prompt of the become_method

For sudo it overrides it (-p option)
For su it expects the default one, which is "Password: "

If you set the become_method to su and the become_exe to "sudo su -", then you are presented with the default sudo prompt, while Ansible is expecting the "su" prompt, which causes the error message
"Timeout (12s) waiting for privilege escalation prompt:"

So just do this:
ansible_become: true
ansible_become_method: "su"
ansible_become_exe: 'sudo -p "Password: " su -'

brahim-raddahi commented Mar 15, 2018

Looks like newer versions of Ansible are expecting the prompt of the become_method

For sudo it overrides it (-p option)
For su it expects the default one, which is "Password: "

If you set the become_method to su and the become_exe to "sudo su -", then you are presented with the default sudo prompt, while Ansible is expecting the "su" prompt, which causes the error message
"Timeout (12s) waiting for privilege escalation prompt:"

So just do this:
ansible_become: true
ansible_become_method: "su"
ansible_become_exe: 'sudo -p "Password: " su -'

@plup

This comment has been minimized.

Show comment
Hide comment
@plup

plup Apr 11, 2018

ansible_become_exe="sudo su -" workaround works in ansible 2.4.
Thank you guys !

plup commented Apr 11, 2018

ansible_become_exe="sudo su -" workaround works in ansible 2.4.
Thank you guys !

@yodatak

This comment has been minimized.

Show comment
Hide comment
@yodatak

yodatak May 16, 2018

For my part i use an extra_vars.yml and i use it in my command with --extra-vars @extra_vars.yml

ansible_become: true
ansible_become_method: su
ansible_become_pass: 'PASSWORD'
ansible_user: 'USERHERE'
ansible_ssh_pass: 'PASSWORD'
ansible_become_exe: 'sudo -p "Password: " su -'

yodatak commented May 16, 2018

For my part i use an extra_vars.yml and i use it in my command with --extra-vars @extra_vars.yml

ansible_become: true
ansible_become_method: su
ansible_become_pass: 'PASSWORD'
ansible_user: 'USERHERE'
ansible_ssh_pass: 'PASSWORD'
ansible_become_exe: 'sudo -p "Password: " su -'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment