On all our boxes we have ssh access via keys. All keys are password protected. At this moment the sudo mode is not passwordless. Because the number of VMs are growing in our setup, we investigate the usage of Ansible.

Ansible itself says in the docs:

Use of passwordless sudo makes things easier to automate, but it’s not required.

This got me thinking about passwordless sudo and I found some questions/answers here. However, I couldn't really find anything about the security concerns of passwordless sudo per se.

It could happen in the future user Bob has a different password on machine X than Y. When Bob is a sudoer, this gives problems with Ansible to enter one sudo password for all boxes. Given the facts ssh is done via keys, keys are password protected and all user accounts have passwords (so su bob is impossible without a password): how is the security affected when NOPASSWD is set in the sudo file?

6 Answers 6


NOPASSWD doesn't have a major impact on security. Its most obvious effect is to provide protection when the user left his workstation unattended: an attacker with physical access to his workstation can then extract data, perform actions and plant malware with the user's permissions, but not elevate his access to root. This protection is of limited use because the attacker can plant a keylogger-type program that records the user's password the next time he enters it at a sudo prompt or in a screensaver.

Nonetheless, requiring the password does raise the bar for the attacker. In many cases, protection against unsophisticated attackers is useful, particularly in unattended-workstation scenarios where the attack is often one of opportunity and the attacker may not know how to find and configure discreet malware at short notice. Furthermore it is harder to hide malware when you don't have root permissions — you can't hide from root if you don't have root.

There are some realistic scenarios where the lack of a password does protect even against sophisticated attackers. For example, a stolen laptop: the user's laptop is stolen, complete with private SSH keys; either the thief manages to guess the password for the key file (perhaps by brute force), or he gains access to them from a memory dump of a key agent. If the theft is detected, this is a signal to investigate recent activity on that user's account, and this means that a planted malware should be detected. If the attacker only had user-level access, anything he did will leave traces in logs; if the attacker obtained the user's password and ran sudo, all logs are now compromised.

I don't know whether the downsides of NOPASSWD balance the upsides for your use case. You need to balance that against all the other factors of your situation. For example, it seems that you allow but don't enforce having different passwords. Can you instead use a centralized account database? How much containment do you need between your systems? Are you considering alternatives to Ansible that would support differing sudo passwords? Have you considered other authentication mechanisms?

  • We are also currently investigating usage of 2FA for ssh logins. That means the stolen laptop isn't that much of a risk anymore when the token isn't taken as well. Thank you for the response, as it most closely resembles what I somewhat expected for an answer :) Commented Nov 21, 2013 at 8:31
  • 2
    One other aspect to consider with respect to using NOPASSWORD is that it removes one very useful control. If access requires a password, you can centrally restrict access to everyone/everything by changing the password. This is not as useful if scripts all sudo to root. However, with good partitioning of authorisation into different accounts, can be quite useful.
    – Tim X
    Commented Nov 21, 2013 at 21:59
  • 1
    I think the answer doesn't cover an important point: isn't having NOPASSWD in a way equivalent to running everything as root as it gives any program a way to escalate privileges without user's involvement? There is a certain level of protection offered by separating different users, which limits potential damage, either accidental or malicious.
    – raindev
    Commented Oct 26, 2019 at 5:16
  • @raindev NOPASSWD increases potential accidental damage, but offers no protection against malicious damage. A malicious program can just wait until the next time the user types their password. Commented Oct 26, 2019 at 7:11
  • @Gilles I believe this is not quite how sudo works: executing a command with root privileges using sudo does not give any other processes owned by the same user additional privileges. Or maybe I misunderstood your argument. I’ll start a new question to not derail the comments too much.
    – raindev
    Commented Oct 26, 2019 at 7:43

There are two specific cases why you don't want passwordless sudo:

  1. This is a defense mechanism against malicious users who gain access to an administrative account. This can either be through exploitation or due to an admin leaving his workstation unattended without locking his session.
  2. Having to re-issue the password when using sudo gives impulsive users the time to think twice before actually performing the action.

About automation:

I agree you can do this passwordless, but by not requiring the sudo password you are actually giving ALL access to your automation tool. Now think what the tool is actually required to do? Does it really need all these accesses? Probably not.

Sudo comes with a nice feature which allows you to configure specific commands with the NOPASSWD flag within the sudoers file:

username myhost = (root) NOPASSWD: /sbin/shutdown
username myhost = (root) NOPASSWD: /sbin/reboot
  • For ansible provisioning the server, it is required ansible can use vim, has file read/write permissions in /etc and /var, can use apt and can start/stop/reload services. Is the protection for specific commands still a viable option then? Commented Nov 19, 2013 at 13:57
  • sure why not? Vim is just another command no? Commented Nov 19, 2013 at 14:44
  • Unfortunately I cannot accept two answers, so I had to choose between yours and @Gilles. Both are good answers, but it felt Gilles gets closer to the actual risk of NOPASSWD. I just +1'd you now :) Commented Nov 21, 2013 at 8:32
  • No worries, I think his answer covers your question better than I did ^^ Commented Nov 21, 2013 at 8:33
  • 6
    It's a little (a lot) late, but it's worth noting that allowing the use of vim with NOPASSWD is as good as allowing any commands: an adversary can just run vim +\!sh to get full root access. The only real advantage here is against automated or very unsophisticated threats.
    – Chris
    Commented Nov 17, 2016 at 20:14

One thing it doesn't look like anyone's pointed out for some reason (correct me if I'm wrong) is that it enables any program you run to elevate to root access without you knowing. Normally, if you accidentally run a malicious program or script as a non-root user without sudo, then while it may still be able to do a lot of damage, it still (barring a separate exploit) won't have root privileges. So you at least won't need to worry about a rootkit or anything. But with NOPASSWD mode, you don't have that protection. Any program that runs under your user will be able to escalate to root by re-invoking itself with sudo. The malware still needs to specifically be programmed to do this, and it won't have root access otherwise, but then what about malicious code that does do that?

  • You may want to point out that this is only true if the logs are automatically sent remotely to a log server, otherwise the malicious process could tamper with the logs.
    – forest
    Commented Jan 31, 2019 at 23:37
  • 1
    @forest: Did you reply to the wrong comment? What's only true in that case?
    – Sparkette
    Commented Feb 10, 2019 at 4:19
  • Is there a workaround for this? Something that allows sudo interactively without asking for a password but still requires one when a script executes sudo? Commented Mar 29, 2023 at 19:55

Given the facts ssh is done via keys, keys are password protected and all user accounts have passwords (so su bob is impossible without a password)

Let's be clear here. The passwords used to protect the SSH keys and the passwords of the user accounts ARE NOT THE SAME ONES.

NOPASSWD simply allows the user to execute commands as another user without entering his password. It does not affect the fact that the user has to enter his password when SSH-ing into the system.

  • Thanks for the answer. I know the fact NOPASSWD does not affect ssh logins. And of course there are different passwords, at least: that is what we ask from those who have the privilege. But in the end, I cannot check their passwords so I don't know for sure. Commented Nov 19, 2013 at 13:55
  • 1
    @JurianSluiman It's good that you know that, wasn't very clear coming from the question. NOPASSWD is really more of a convenience option and doesn't really affect security that much imo. It's more important to ensure that users are given only as much sudo privileges as required to get the job done.
    – user10211
    Commented Nov 19, 2013 at 13:58

Ansible can use various things for automation: like sudo with a sudo password, or NOPASSWD. Or use su, suexec, doas, or whatever.

Nowaday we speak of:

become: yes
become_method: sudo

Just bear in mind that ideally ansible should be used for automation (infra as code), not for interactive use. Human users could still use passwords, incidentally they might stumble upon expiration policies.

Ansible Tower and AWX can store all kinds of credentials encrypted and delegate their use for specific jobs, without leaking the keys or passwords.

An alternative is using temporary (signed) ssh keys. Hashicorp Vault can manage those


There are pros and cons to having the user enter a password to access sudo.

Pro: better protection if someone gains access to an admin account. eg through an unlocked terminal, or some sort of exploit.

Con: the user is entering a plain text password which is encrypted in transit, but then decrypted before it reaches the user's shell. Someone could for example tamper with the bashrc script to run a key logger. Depending on your setup, and the users' habits that might permit use of the password for direct login to the users account on this machine, and perhaps on other machines as well. People re-use passwords all too often.

  • 3
    If they can tamper with your bashrc script they've pretty much already won anyhow.
    – atk
    Commented Nov 19, 2013 at 15:58
  • 3
    @atk no it is worse because now they have a password that someone probably reused across other machines or services. Passwords are just inherently a weak form of security (compared to keys) but they are especially bad because people reuse them in other places.
    – Adam Gent
    Commented Nov 30, 2016 at 17:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .