# FAILED =\> Missing sudo password when NO SUDO PASSWORD is needed **URL:** \ **Category:** Ansible Project\ **Created:** [November 10, 2015, 12:01pm UTC](https://forum.ansible.com/t/failed-missing-sudo-password-when-no-sudo-password-is-needed/19725 "2015-11-10T12:01:37Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Jeff1](https://avatars.discourse-cdn.com/v4/letter/j/4af34b/32.png) [@Jeff1](https://forum.ansible.com/u/Jeff1)\ **Post date:** [November 10, 2015, 12:01pm UTC](https://forum.ansible.com/t/failed-missing-sudo-password-when-no-sudo-password-is-needed/19725/1 "2015-11-10T12:01:37Z")
I have SUDO configured to work without passwords. This command **works just fine** : ansible quee -a “/usr/bin/sudo /usr/bin/apt-get update” This command **fails with "FAILED =\> Missing sudo password "** ansible quee -a “/usr/bin/apt-get update” --sudo It works if I add --ask-sudo-pass and enter a sudo password. I am using Ansible 1.7.2 on Debian Jessie (current stable) I want to use Ansible playbooks and expect that I will need --sudo to work properly without passwords. Have I missed something obvious? Any help much appreciated. ---
**Author:** ![Jeff1](https://avatars.discourse-cdn.com/v4/letter/j/4af34b/32.png) [@Jeff1](https://forum.ansible.com/u/Jeff1)\ **Post date:** [November 10, 2015, 5:20pm UTC](https://forum.ansible.com/t/failed-missing-sudo-password-when-no-sudo-password-is-needed/19725/2 "2015-11-10T17:20:51Z")
I’ve found the answer elsewhere on the list - Ansible SUDO is not the SUDO you expect. Basically Ansible SUDO executes a temporary scrip on the fly - something like: > ssh ‘/bin/sh -c “sudo /tmp/ansible-temp-script”’ A better approach would have been to place the SUDO command INSIDE the temporary script around each command. This would enable fine-grained SUDO configuration on each of the managed hosts. I assume that the problem is in passing the password through to each command for those that want passwords. Personally I would be happy with a SUDO\_COMMAND option that only works for password-less sudo permissioned commands. You can work around the SUDO issues by setting the SUDO permissions and then writing your own modules etc that use SUDO commands, e.g. - command: /usr/bin/sudo /user/bin/apt-get update - command: /usr/bin/sudo /user/bin/apt-get upgrade -y Or you can follow the Ansible recommendations - which effectively give root access to any command, using your password. ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [November 10, 2015, 5:48pm UTC](https://forum.ansible.com/t/failed-missing-sudo-password-when-no-sudo-password-is-needed/19725/3 "2015-11-10T17:48:59Z")
You are making the assumption that all modules shell out to run commands, this is true only for a few modules. Most modules use functions native to the language they are written in (python in the case of those shipped with ansible, but it can be any scripting language) which would end up calling the same system calls most command line utilities use but that would not allow for fine grain sudo to match. ---
**Author:** ![Jeff1](https://avatars.discourse-cdn.com/v4/letter/j/4af34b/32.png) [@Jeff1](https://forum.ansible.com/u/Jeff1)\ **Post date:** [November 11, 2015, 10:02am UTC](https://forum.ansible.com/t/failed-missing-sudo-password-when-no-sudo-password-is-needed/19725/4 "2015-11-11T10:02:58Z")
Is that really true of most modules? AFAIK things like apt-get are not available via a system call. Security is a big concern and it seems that Ansible is designed to require SUDO anything, which kind of defeats the purpose of SUDO in the first place. And trying to get Ansible to work with password-less SUDO? Allowing root access to any command with no password, somehow feels like we have increased the size of the attack surface somewhat. If its impossible to support SUDO properly, why not make the Ansible SUDO something predictable so that it can be explicitly permissioned? At least in that scenario, Ansible is taking some responsibility. Are you using unpredictable temp-script names in the hope that this is more secure, or to prevent multiple-executions from colliding? ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [November 11, 2015, 4:11pm UTC](https://forum.ansible.com/t/failed-missing-sudo-password-when-no-sudo-password-is-needed/19725/5 "2015-11-11T16:11:39Z")
> Is that really true of most modules? AFAIK things like apt-get are not > available via a system call. In the case of apt, it uses the python apt library which talks directly to the apt bindings, it does shell out for some commands but not all. But take 'file' for example, it sets file permissions using the python builtins which will not call 'chmod' command line. > Security is a big concern and it seems that Ansible is designed to require > SUDO anything, which kind of defeats the purpose of SUDO in the first place. No, sudo is still there to control who can execute as which user, ansible also supports SU. What you do loose is fine grained permissions, which is one reason people use SUDO over SU. > And trying to get Ansible to work with password-less SUDO? That is up to you, Ansible can use it with or without passwords as different environments have different requirements and setups. > Allowing root access to any command with no password, somehow feels like we > have increased the size of the attack surface somewhat. again, not a requirement, that is up to your setup. > If its impossible to support SUDO properly, why not make the Ansible SUDO > something predictable so that it can be explicitly permissioned? At least in > that scenario, Ansible is taking some responsibility. Hard to do when you don't install anything on the machine, this is a tradeoff for not having an agent, you could install ansible-pull on the machines and use it to execute everything running as root from cron (this is how most agent manage machines, by being root in the first place). Ansible can be mostly predicted by using the remote\_tmp to control where the scripts are put, there are issues like when sudoing to a non root user in which this is switched to /tmp to allow both users access (root does not normally have this problem unless NFS or something like that is involved). With pipelining we don't even copy the scripts to a location but execute directly over ssh as a pipe, this prevents secrets from ever being written to disk, but makes sudoers settings that much harder. > Are you using unpredictable temp-script names in the hope that this is more > secure, or to prevent multiple-executions from colliding? mostly to avoid collisions, but it does help a bit to make it harder for others to predict the script locations and drop in their own. ---
**Author:** ![Dylan\_Martin](https://avatars.discourse-cdn.com/v4/letter/d/8797f3/32.png) [@Dylan\_Martin](https://forum.ansible.com/u/Dylan_Martin)\ **Post date:** [November 11, 2015, 6:52pm UTC](https://forum.ansible.com/t/failed-missing-sudo-password-when-no-sudo-password-is-needed/19725/6 "2015-11-11T18:52:58Z")
I’ve used sudo for different tasks in my play so I can get more granularity that way. You can say “sudo: true” or “sudo:false” in a task within a playbook that has sudo set to either true or false. EG - name: compile thingy command: make thingy sudo: false - name: install thingy command: make install sudo: true Holy Cow! Apparently sudo is uncool and now it’s all “become”. See this link for details. Totally new to me! [http://docs.ansible.com/ansible/become.html](http://docs.ansible.com/ansible/become.html) On Tuesday, November 10, 2015 at 8:48:53 AM UTC-8, Jeff wrote:[http://docs.ansible.com/ansible/become.html](http://docs.ansible.com/ansible/become.html) ---
**Author:** ![Dylan\_Martin](https://avatars.discourse-cdn.com/v4/letter/d/8797f3/32.png) [@Dylan\_Martin](https://forum.ansible.com/u/Dylan_Martin)\ **Post date:** [November 11, 2015, 7:51pm UTC](https://forum.ansible.com/t/failed-missing-sudo-password-when-no-sudo-password-is-needed/19725/7 "2015-11-11T19:51:56Z")
Oh, another important thing about sudo! Don’t use wildcards in a sudoers file if you care about the args your user passes! You cannot specify how many args are allowed, so no matter how tightly you construct the wildcard, the user can always add more args. Either use literal commands in the sudoers file or use a wrapper that sanitizes the args and have sudo call the wrapper.