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
What do you think about this feature? Does it have chances to be
included?
Regards
Till
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).
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
“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.
"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.
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.
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.
“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.
"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
"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
Here "sudo -k" is only run when a sudo password is provided to ensure
that it is always verified when it is provided.
" 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 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.