"sudo ansible-playbook" command fails even with --user option - ansible

I've a user foo which is able to do passwordless ssh to A(self) and B. The playbook requires sudo access inside which I'm escalating with become and the below command is working fine.
ansible-playbook -i ../inventory.ini --user=foo --become --become-user=root echo_playbook.yml
But the above command is part of a shell script which doesn't have permission for foo. So when I use sudo to trigger that shell script, ansible is saying host unreachable. So I tried the ansible command with sudo as shown below and same. It showed host is unreachable.
sudo ansible-playbook -i ../inventory.ini --user=foo --become --become-user=root echo_playbook.yml
I agree that sudo is escalating the ansible-playbook to root. But I'm also providing the --user to tell ansible that "foo" user needs to be used for ssh.
Basically to access the playbook I need sudo. To connect to other servers I need foo user. To execute the actions inside the playbook (commands in playbook) I need sudo again (which I am using become for).
Am I doing anything wrong? Can anybody tell me the exact command for the ansible-playbook for the above scenario where ansible-playbook needs to run as sudo ansible-playbook?

I'm not entirely clear on exactly where you're stuck. I don't think you're confused between the remote user and the local user. If the playbook works as foo, and from what you describe, I can only guess that ~foo/.ssh/id_rsa or another automatically provided key authenticates foo. But you can generate a key for any user and allow it access to the remote foo if you'd prefer. Or, you can run the playbook as another user. It's up to you. The only thing that won't work is relying on the environment or configuration of particular users and then not providing it.
the above command is part of a shell script which doesn't have permission for foo.
What I'm hearing is that:
a user foo can successfully run ansible job
a script runs (under root?) that cannot run the ansible job
If you're happy with how ansible works for the foo user, you can switch to the foo user to run the ansible:
sudo -u foo ansible-playbook ...
If the script runs as root, sudo will always succeed. Otherwise, you can configure sudo to allow one user to access another for one command or more.

Related

SSH sudo inside script different behaviour

I'm trying to set some automation inside local network and started working with some shell scripting and something that I saw - very strange behaviour SSH inside script according to how script running(with or without sudo):
What I have:
ComputerA and ComputerB.
Inside ComputerA:
A shell script script.sh:
cp /dir1/file1 /dir2/file2
ssh username#ComputerB "sudo reboot"
/etc/ssh/ssh_config file with some configurations to work without ssh-keys (they always changes on ComputerB):
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
GlobalKnownHostsFile=/dev/null
Inside ComputerB:
In /etc/sudoers file:
username ALL=(ALL:ALL) NOPASSWD:ALL
When I connecting through SSH to ComputerA and running script.sh without sudo, I get permission error to write to /dir2 (it's OK) and next command on ComputerB executes normally (reboots ComputerB), but I'm running sudo script.sh. It copy file and then I got strange - SSH asks me username password. Tried different variants to change ssh command to something like:
ssh -t username#ComputerB "echo user_pass | sudo -S reboot"
but nothing helped.
So I need help to figure out what happens and what to do to execute sudo script.sh without entering password for ssh command inside.
Thanks!
Don't run script.sh with sudo on computerA; instead modify the script like so:
sudo cp /dir1/file1 /dir2/file2
ssh username#ComputerB "sudo reboot"
The reason that you're seeing the strange behaviour is that you're actually becoming root on computerA (I assume you have a keypair set-up for your regular user and expect to connect to computerB passwordless?), and that root on computerA doesn't have a keypair that computerB knows about.

Not able to switch user in ansible

We have a system where we have user A and user B. We can switch to user B from A using "sudo su" command only. Direct login to B user is not allowed.
Now From Ansible master, we can login to A user (as ansible remote user) successfully. Our use case is, We have to run some commands as user B using ansible. But we are failing to switch to B user and run those commands.
Our yml file looks like -
Module to copy java to the target host.
- name: Copying Java jdk1.8.0_192
remote_user: A
become_user: B
become: true
become_method: su
copy:
src: /etc/ansible/jboss7-cluster/raw_template/jdk1.8.0_192.zip
dest: "{{ java_install_dir }}"
Any inputs?
In your case, I believe the become_method should be the default sudo. Have you tried using that? If so, what is the result? Can you copy/paste the result here?
Also, can you try to run an ad hoc command against the host, and post the result here?
Something like this:
ansible -i inventory.ini -u A --become --become-user B -m ping myhost
And one more thing: note that there are some restrictions when using become to switch to a non-privileged user:
"In addition to the additional means of doing this securely, Ansible 2.1 also makes it harder to unknowingly do this insecurely. Whereas in Ansible 2.0.x and below, Ansible will silently allow the insecure behaviour if it was unable to find another way to share the files with the unprivileged user, in Ansible 2.1 and above Ansible defaults to issuing an error if it can’t do this securely. If you can’t make any of the changes above to resolve the problem, and you decide that the machine you’re running on is secure enough for the modules you want to run there to be world readable, you can turn on allow_world_readable_tmpfiles in the ansible.cfg file. Setting allow_world_readable_tmpfiles will change this from an error into a warning and allow the task to run as it did prior to 2.1."
And just as a side note: please avoid using sudo su - use sudo -i, or at least sudo su - . These will populate the environment correctly, unlike sudo su. For a fun read about why you want this, see here.

ssh login as user and change to root, without sudo

I have the following task for my golang code:
The command has to be run as root user on the server remotely in bash and the command output has to be fetched in a variable.
Logging over ssh as root is disabled.
sudo on the server is disabled, so I have to use 'su -' and type password
since I want to make it as automated as possible in bash, the password has to be stored inside the command
Here are the workflow actions:
Login via SSH (as unprivileged user) to remote host
Elevate to privileged 'root' user --> su -
Type the root password
run the command which root can execute
get to output to string on localhost and do some actions
I have Googled for days, but it seems that I cannot find a solution for this.
Does anyone have a solution to this?
The issue you are facing is concerning interacting with the command after it has been executing.
It is quite easy to use exec.Command for non-interactive commands.
I would recommend using Expect for interaction, or the Golang equivalent located here.

Ansible Ad-hoc commands requests vault passwords

This afternoon when running ansible ad-hoc commands I've started to be prompted for the vault passwords.
The process shouldn't need this and this was never required before.
I'm just running something like
ansible prod_servers -m shell -a "ls -al /var/logs/" --sudo
I can just provide the password and the command works, but it's driving me crazy.
We're using ansible 1.8.4 (don't ask) :(
Check for vaulted files under group_vars/host_vars in your inventory – this should be the only reason why password prompt may appear for ad-hoc commands.

Switching the user while deploying with capistrano?

is there any way to switch the user (to root or so) while deploying with capistrano without closing the current session (session is started with ssh keys)?
So i want to start the deployment with user foo and then change to root and then execute some commands.
Thanks for your answers!
You can use the capistrano sudo helper:
task :some_task_as_root do
run "#{sudo} some_command"
end
you can even specify a different user:
task :some_task_as_other_user do
run "#{sudo :as => 'other_user'} some_command"
end
The sudo helper will take care of getting the password from you if necessary and pass it along correctly.
You don't say where you want to run the commands as root. On the local system? On the remote system?
Each "run" sort of command in capistrano uses a separate new ssh connection. As stated above, "sudo" is the official way to run one set of statements as root.
If you're comfortable giving Root an ssh key to be able to log in directly via ssh, you can specify a user to ssh over as. I wouldn't recommend it, though.
In a Solaris environment without "sudo" (sigh), we use pfexec instead.
I believe sudo is what you need
your user should be sudoers groups before.
then use it:
task :specific_sudo_take do
run 'sudo -c sh "whoami' #put your sudo command here
end

Resources