# Ask for sudo password on-demand/Why does ansible run sudo -k? **URL:** \ **Category:** Ansible Developer\ **Created:** [January 15, 2014, 10:42am UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347 "2014-01-15T10:42:11Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Till\_Maas](https://avatars.discourse-cdn.com/v4/letter/t/9f8e36/32.png) [@Till\_Maas](https://forum.ansible.com/u/Till_Maas)\ **Post date:** [January 15, 2014, 10:42am UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/1 "2014-01-15T10:42:11Z")
Hi, I want to use ansible with systems where sudo requires a password, but I would also avoid to enter it always. Since ansible runs "sudo -k" before the actual sudo command, it always requires a password. The option "-k" revokes cached access. Why is this done? Proof-of-concept code is here: [https://github.com/tyll/ansible/commit/98b37644f8e6bce925b77fd71ef3e0094ad694e6](https://github.com/tyll/ansible/commit/98b37644f8e6bce925b77fd71ef3e0094ad694e6) What do you think about this feature? Does it have chances to be included? Regards Till ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [January 15, 2014, 12:58pm UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/2 "2014-01-15T12:58:00Z")
Because Ansible isn’t merely automating what a user would log in as a sysadmin and do. Many people consider Ansible being able to rerun and someone not entering in the sudo password because it was already entered as a very bad thing, so we don’t do it. There would be riots 🙂 Now, what I think you’d really want is ‘ansible\_ask\_sudo\_pass’ as an inventory variable, and being able to set it to no for certain systems. Right now you can also set ‘ansible\_sudo\_pass’ (though this is not recommended, since it exposes this in inventory) on a per system basis, which would technically solve this problem (but in a way I wouldn’t recommend). ---
**Author:** ![Till\_Maas](https://avatars.discourse-cdn.com/v4/letter/t/9f8e36/32.png) [@Till\_Maas](https://forum.ansible.com/u/Till_Maas)\ **Post date:** [January 15, 2014, 2:09pm UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/3 "2014-01-15T14:09:54Z")
> Because Ansible isn't merely automating what a user would log in as a > sysadmin and do. > > Many people consider Ansible being able to rerun and someone not entering > in the sudo password because it was already entered as a very bad thing, so > we don't do it. There would be riots 🙂 This does not really explain the use of "sudo -k", because as far as I can see the only way to get stock ansible to ask for a sudo password is setting ask\_sudo\_pass. But then ansible will always ask for a sudo password even if sudo does not require one. For this "sudo -k" does not make a difference. Also "sudo -k" runs always, even if ansible\_ask\_sudo\_pass is not set. > Now, what I think you'd really want is 'ansible\_ask\_sudo\_pass' as an > inventory variable, and being able to set it to no for certain systems. Actually the implemented changes seem to be what I want, because I would like to be able to use. Is there any chance to get this in but e.g. disabled by default for people who like it more to always enter their sudo password? Regards Till ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [January 15, 2014, 2:30pm UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/4 "2014-01-15T14:30:08Z")
“This does not really explain the use of “sudo -k”,” See what I wrote about cached passwords. “Actually the implemented changes seem to be what I want” I can’t parse this sentence due to the mixed past and future tense. Can you restate what you think something should do? “Is there any chance to get this in but e.g. disabled by default for people who like it more to always enter their sudo password?” Are you asking to be able to set “ask\_sudo\_password” at play level? I’m confused as to how that has any bearing on -k. ---
**Author:** ![Till\_Maas](https://avatars.discourse-cdn.com/v4/letter/t/9f8e36/32.png) [@Till\_Maas](https://forum.ansible.com/u/Till_Maas)\ **Post date:** [January 15, 2014, 3:07pm UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/5 "2014-01-15T15:07:45Z")
> "This does not really explain the use of "sudo -k"," > > See what I wrote about cached passwords. You did not write about cached passwords as far as I can see. However you wrote that it is wrong if ansible runs without asking for a password. But ansible always asks for a password if "-K" is specified to ansible. It asks before sudo even runs. One minor difference is, is that the password won't be verified if "sudo -k" is not run. Is this what you mean? However running "sudo -k" unconditionally also makes it impossible to e.g. run "sudo -v" manually outside of ansible and then run ansible without asking for a sudo password. What actually happens is that ansible just hangs at the sudo login prompt. > "Actually the implemented changes seem to be what I want" > > I can't parse this sentence due to the mixed past and future tense. Can > you restate what you think something should do? I would like to be able to use ansible with password protected sudo. Ansible should only ask for a sudo password if one is required according to the sudo policies on the affected host (e.g. if I set a high enough timeout and disable tty\_tickets ansible should ask at most once per host). This is what I implemented (partially) in the commit I referenced. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [January 15, 2014, 3:26pm UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/6 "2014-01-15T15:26:35Z")
re: cached passwords, this part: “Many people consider Ansible being able to rerun and someone not entering in the sudo password because it was already entered as a very bad thing, so we don’t do it.” This will likely not be changing. For folks managing large numbers of hosts, it’s unlikely that the sudo password would be consistently cached on all of them, and as such it would be unclear whether we had to prompt \*until \* we hit one that did, and then would need to know to pass that around to the other forks. A lot of code for something most people want _off_ by default, and also would require another configuration option. ---
**Author:** ![Till\_Maas](https://avatars.discourse-cdn.com/v4/letter/t/9f8e36/32.png) [@Till\_Maas](https://forum.ansible.com/u/Till_Maas)\ **Post date:** [January 15, 2014, 3:50pm UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/7 "2014-01-15T15:50:52Z")
> re: cached passwords, this part: > > "Many people consider Ansible being able to rerun and someone not entering > in the sudo password because it was already entered as a very bad thing, so > we don't do it." > > This will likely not be changing. Ok, but as I wrote several times, if ansible asks for the password, then it asks before checking sudo. So removing/adding "sudo -k" does not change this. > For folks managing large numbers of hosts, it's unlikely that the sudo > password would be consistently cached on all of them, and as such it would > be unclear whether we had to prompt \*until \* we hit one that did, and then > would need to know to pass that around to the other forks. Do they even use sudo password? And how does it work with multiple hosts if there a different passwords for different hosts? I am not promoting to disallow to specify the sudo password beforehand but asking for it everytime is very annoying especially if one uses different passwords for different hosts. > A lot of code for something most people want \*off\* by default, and also > would require another configuration option. Did you look at the commit? There is not much code involved here. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [January 15, 2014, 4:00pm UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/8 "2014-01-15T16:00:34Z")
“Ok, but as I wrote several times, if ansible asks for the password, then it asks before checking sudo. So removing/adding “sudo -k” does not change this.” Yes, because you are going to need to supply the password, it asks before sudo asks, and then feeds this in to sudo. "Do they even use sudo password? " Yes, plenty of people do. It’s an important feature to be able to support. " And how does it work with multiple hosts if there a different passwords for different hosts?" In this case, they need to be the same. “Did you look at the commit? There is not much code involved here” It’s a little large for me. Also I really don’t want to remove -k. It is very very rare for someone to want to log in via normal SSH as a means of priming Ansible for being able to manage those systems, so I think this is really a niche kind of thing that we shouldn’t concentrate on. ---
**Author:** ![Till\_Maas](https://avatars.discourse-cdn.com/v4/letter/t/9f8e36/32.png) [@Till\_Maas](https://forum.ansible.com/u/Till_Maas)\ **Post date:** [January 16, 2014, 8:03am UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/9 "2014-01-16T08:03:59Z")
> "Ok, but as I wrote several times, if ansible asks for the password, then > it asks before checking sudo. So removing/adding "sudo -k" does not > change this." > > Yes, because you are going to need to supply the password, it asks before > sudo asks, and then feeds this in to sudo. But then the visible interface does not change. If people run ansible with ask\_sudo\_pass, ansible will ask for the password before it proceeds. So there is nothing to worry whether or not "sudo -k" is run. > "Do they even use sudo password? " > > Yes, plenty of people do. It's an important feature to be able to support. I think the feature us useful, too, but I wonder why there is no bug report that ansible hangs when a sudo password is required and none provided. E.g. the following code is missing (it depends on my previous commit): [https://github.com/tyll/ansible/commit/64211947d12bf0a5a3cc3f642b2e2fbf98434bce](https://github.com/tyll/ansible/commit/64211947d12bf0a5a3cc3f642b2e2fbf98434bce) > "Did you look at the commit? There is not much code involved here" > > It's a little large for me. Also I really don't want to remove -k. Most of the changes just pass the sudo\_ask\_pass\_callback from the tools to the connection plugin. And at the place where the connection plugin calls the callback, it need to raise an error anyhow (see the commit mentioned previously). > It is very very rare for someone to want to log in via normal SSH as a > means of priming Ansible for being able to manage those systems, so I think > this is really a niche kind of thing that we shouldn't concentrate on. sudo supports this and probably for a reason. Therefore IMHO it is better if ansible just lets admins configure sudo via sudoers instead of hardcoding defaults in ansible that manipulate sudo defaults. E.g. instead of running "sudo -k" in ansible one can just set the timestamp\_timeout to "0" to make sudo ask for a password every time. I for example did not expect ansible to just ignore my sudo config. Therefore it is not just about being able to priming ansible but also about being flexible. For example this would be required to use ansible with sudo and non-static passwords, e.g. using a yubikey for authentication. To address your concerns, maybe this commit helps: [https://github.com/tyll/ansible/commit/0bcf35c499141be5f2eac9f881c65795ff10620f](https://github.com/tyll/ansible/commit/0bcf35c499141be5f2eac9f881c65795ff10620f) Here "sudo -k" is only run when a sudo password is provided to ensure that it is always verified when it is provided. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [January 16, 2014, 2:15pm UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/10 "2014-01-16T14:15:21Z")
" If people run ansible with ask\_sudo\_pass, ansible will ask for the password before it proceeds. So there is nothing to worry whether or not “sudo -k” is run." This is a seperate issue. We simply do not want to rely on previously cached sudo passwords. This is considered a security issue by enough people sharing a central machine to access remotes, etc. ---
**Author:** ![Till\_Maas](https://avatars.discourse-cdn.com/v4/letter/t/9f8e36/32.png) [@Till\_Maas](https://forum.ansible.com/u/Till_Maas)\ **Post date:** [January 16, 2014, 3:24pm UTC](https://forum.ansible.com/t/ask-for-sudo-password-on-demand-why-does-ansible-run-sudo-k/14347/11 "2014-01-16T15:24:38Z")
> " If people run ansible > with ask\_sudo\_pass, ansible will ask for the password before it > proceeds. So there is nothing to worry whether or not "sudo -k" is run." > > This is a seperate issue. > > We simply do not want to rely on previously cached sudo passwords. This > is considered a security issue by enough people sharing a central machine > to access remotes, etc. If you consider/other people consider cached passwords a security issue, why don't you disable cached passwords with "timestamp\_timeout" in sudo? Also what is your attack here? Ansible resets the timestamp before it runs. So someone already entered the sudo password and an attacker that could run ansible with customs command can just run ansible without sudo and run a task that justs calls sudo via system to execute code via sudo. Therefore ansible run "sudo -k" after it ran to disable the timestamp again - but then you have a race condition, which is why the only clean option is to just disable the timestamp feature in sudo.