When we issue a sudo request via ansible, ansible using the –p option of sudo to display a customized message (which is generated dynamically with each ansible run ) using the command
sudo -H -S -p "[sudo via ansible, key=vrioenmynjfokqgzjxywtayyaivnxspy] password: " <command Name>
This has been observed via -vvv mode.
The problem is we have a situation where the default custom sudo prompt is fixed and cannot be overriden using sudo -p option (beause sudo access is verified via third-party tool Active directory).
Say for example:
sudo ls -l:
use Window's password:
If I use sudo -p
sudo -p 'Enter your password:' ls -l
use Window's password:
When ansible tries to do sudo , it expects the custom prompt and then if the expected custom prompt matched with the thrown custom prompt ansible sends the password, otherwise not and results in error (timeout)
My question is is there any way
sudo -H -S -p "[sudo via ansible, key=vrioenmynjfokqgzjxywtayyaivnxspy]
the custom prompt using -p option in ansible can be made fixed for every ansible run using some configuration
Set the ansible_become_exe parameter for a task, play, or in the inventory.
For example:
- name: Check escalation
vars:
ansible_become: true
ansible_become_exe: 'sudo -p "[sudo via ansible, key=vrioenmynjfokqgzjxywtayyaivnxspy]"'
command: whoami
Related
So here is my weirdness from work.
We have user accounts and service accounts and sudo access to the service accounts from the user accounts. Most, if not all, user accounts are running bash, whilst the service accounts use a misxture of bash or ksh.
When I am logged in as a user(bash) and using sudo to a service account(ksh) and run the following:
sudo -u svc_user -i alias_name
The alias runs as expected.
When I am logged in as a user(bash) and using sudo to a service account(bash) and run the following:
sudo -u svc_user -i alias_name
I get the error:
-bash: alias_name: command not found
Strangely, even when both accounts are bash, I can see the alias:
sudo -u svc_user -i alias
alias alias_name='func_name'
sudo -u svc_user -i which alias_name
alias alias_name='func_name'
Is there a reason why this works with ksh as the service account shell and not in bash?
Please let me know if any further details are required?
EDIT:- I just want to be clear, the alias I want to run belongs to the service account and not the original user who is calling sudo
Because bash only parse the first word in your command line to check if there is an alias in current environment.
You can try sudo alias_name, maybe also cannot find the alias. But you can try to add alias sudo='sudo ' to tell bash to parse next command for alias.
However, for your current case, it maybe actually run command bash -c xxxx in your srv_account. So it is not an easy things to resolve.
I'm trying to change my user to one that doesn't need password to run ssh instructions and then do exactly that, run an ssh instruction. What I have now is:
sudo su - testUser ssh testUser#server2 'cat /home/randomUser/hola.txt'
But I'm getting the answer:
/usr/bin/ssh: /usr/bin/ssh: cannot execute binary file
if I put the instructions in a different file called testit like this:
ssh testUser#server2
cat /home/randomUser/hola.txt
and I run:
sudo su - testUser < testit
it works!, but I need to use the one line instruction, someone know what should I change to make it work?
sudo su - testUser
why don't you use just sudo -u testUser as it is supposed to be used?
But anyway, manual pages for the tools you are using is a good start. For sudo:
sudo [...] [command]
This looks good and fits into your example.
For su:
su [options] [username]
Ola ... su does not have any argument command, unless you provide also -c switch, which is written also in the manual page. And it is [option], so it should come in front of [username]! Something like this should do the job:
sudo su -l -c "ssh testUser#server2 'cat /home/randomUser/hola.txt'" testUser
but as I already mentioned, it can be significantly simplified by using sudo only:
sudo -i -u testUser "ssh testUser#server2 'cat /home/randomUser/hola.txt'"
I try configure ansible for become other user:
My ansible.cfg entries
sudo_flags=
ssh_args = -t -t
sudo_exe = sudo /bin/su
I can escalate privilege on remote host only one way (and this works in ssh session):
sudo /bin/su anyuser -
Example playbook:
---
- hosts: anyhosts
become: true
become_user: anyuser
tasks:
- name: check becoming anyuser
command: "ls -ltha"
When i run my simple playbook, in verbose log output i see -u option:
'"'"'sudo /bin/su -u anyuser -
How i can disable/remove this -u option in playbook or ansible.cfg?
You have told Ansible that sudo is sudo /bin/su, but as far as Ansible knows it's still using sudo, which supports -u argument. If you want to use some other command for privilege escalation, consider setting become_method.
However, it's not clear why you're not just using sudo, since you appear to have sudo privileges. Possibly setting sudo_exe = sudo sudo would actually solve the problem, since the first sudo would get you root access (which appears to work just fine, based on your question), and then root would be able to run sudo -u ..., which should work just fine.
In my docker container I am running a command as a specific user like this from entrypoint.sh:
sudo -u appuser "$#"
This works fine, however, it doesn't set any of the environment variables that get created by using the --link option while running the container.
Question
Is it possible to set all environment variables that exist for a root user to some other specific user (in this example appuser)
Note: related question to this discussion. This is the reason I can't just use the USER command How to give non-root user in Docker container access to a volume mounted on the host
The sudo command, because it is designed as a tool for privilege escalation, intentionally sanitizes the environment before switching to a new user id. If you take a look at the sudo man page, you'll find:
-E, --preserve-env
Indicates to the security policy that the user wishes to preserve their existing
environment variables. The security policy may return an error if the user does not
have permission to preserve the environment.
So instead of sudo -u appuser somecommand, just use sudo -E -u appuser somecommand.
The runuser command is provided by the util-linux package in recent versions of Ubuntu, and does not perform any environment initialization by default. For example:
$ docker pull ubuntu
$ docker run -it --rm ubuntu /bin/bash
root#ded49ffde72e:/# runuser --help
Usage:
runuser [options] -u <user> <command>
runuser [options] [-] [<user> [<argument>...]]
[...]
This is with Ubuntu Xenial (but the runuser command also appears to be available on ubuntu:vivid, but is not available under ubuntu:trusty).
So your options are:
Use sudo -E, or
Use a more recent Ubuntu image
This question already has answers here:
How to fix 'sudo: no tty present and no askpass program specified' error?
(30 answers)
Closed 6 years ago.
I have a shell script which creates a user and executes another script as that user
sudo useradd -m devops
sudo passwd devops
sudo adduser devops sudo
su - devops -c "sh /path/to/myscript.sh"
This script creates the user,sets the password and adds user to sudo group as expected.
myscript.sh contains commands which uses sudo previlages. (sudo apt-get update, sudo apt-get install software-properties-common etc.). And other commands like ssh-keygen,curl and wget.
All commands except the one's with sudo are executed correctly and producing results as excepted.
But commands having sudo fails by giving the error "no tty present and no askpass program specified"
Why does this happen in this case and how can I overcome this?
I have seen similiar questions but will be thankful if I get a clear explanation in this context,thank you.
Try to replace this:
su - devops -c "sh /path/to/myscript.sh"
with this:
sudo -u devops -H sh -c "sh /path/to/myscript.sh"
The -c option of su doesn't support interactive mode:
-c, --command COMMAND Specify a command that will be invoked by
the shell using its -c.
The executed command will have no controlling terminal. This option
cannot be used to execute interractive programs which need a
controlling TTY.
(man su)
By the way, I wouldn't use sudo within a script everywhere. The script might simply require root permissions. Within the script you might drop privileges where necessary by means of the above-mentioned sudo command.