122

I have a NOPASSWD line in /etc/sudoers (edited with visudo)

gatoatigrado    ALL=(ALL) NOPASSWD: /bin/set-slow-cpufreq

However, the output is,

gatoatigrado@coral:~> sudo -n /bin/set-slow-cpufreq
sudo: sorry, a password is required to run sudo

This kind of command works on an OpenSuSE machine, but not on Ubuntu 11.10. What am I doing wrong?

Note: I cannot find any relevant system log messages, e.g. via tail -f /var/log/syslog.

edit

Here is /etc/sudoers.

Defaults    env_reset

# things I've tried copying from an opensuse machine
Defaults always_set_home
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"

root    ALL=(ALL:ALL) ALL
gatoatigrado ALL=NOPASSWD: /bin/set-slow-cpufreq
%admin ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
2

6 Answers 6

211

You should put that line after the line with the rule for the sudo group, because, as the sudoers man page states:

   When multiple entries match for a user, they are applied in order.
   Where there are multiple matches, the last match is used (which is not
   necessarily the most specific match).
4
  • 5
    as an additional note, this applies to users in multiple groups as well: e.g. user is in group admin and group sudo if the rule for sudo is after admin then the rule for sudo overrides the rule for admin for the user in both groups.
    – Populus
    Sep 30, 2012 at 23:49
  • 2
    Thanks! I added my line to the end of /etc/sudoers and it now works. Full explanation here to people who are interested: techglimpse.com/ubuntu-sudoers-nopasswd-option-not-working
    – elimisteve
    Apr 28, 2017 at 21:21
  • Thank you! I would not have guessed from this manpage description that this is necessary. It would be nice if visudo did some self-checking whether rules make sense.
    – CodeMonkey
    Dec 9, 2020 at 10:14
  • 1
    And another note - check /etc/sudoers.d. I just spent 20 minutes pulling my hair out because it just wouldn't work, until I realized it was getting overwritten by a distro-default file in sudoers.d.
    – Tomáš M.
    Aug 29, 2021 at 19:38
10

Just ran into this too.

My situation is I'm setting up a remote system that will run headless. I have enabled full disk encryption (otherwise an attacker with physicall access can do anything he or she wants) I want to auth with pub key only (I will unset the password so that the "have something, know something" scheme will be a password protected keypair --root login is of course disabled entirely)

The Ubuntu installer prompts for a non-root admin user which gets added to the group sudo. I had then manually added myself to the sudoers file using sudo visudo:

my_username ALL=(ALL:ALL) NOPASSWD:ALL

NOTE if you use nopasswd on your laptop you must always lock your computer as you walk away or else a casual attacker can compromise a lot while you're getting up to put cream in your coffee

I was still having to password authenticate.

enzotib's answer is the key to what's going on. The group sudo shows up in sudoers after the entry for my username.

Rather than moving my entry below the sudo line I simply removed the line I had previously added and then added NOPASSWD to the entry for %sudo

That seems to work. Again only use nopasswd if you really need it (In my case it was precisely what I needed, for most users requiring a password for sudo activity is best)

Additional WARNING: Always edit sudoers with visudo. (sudo visudo) Also, having another window open switched to the root user allows you to recover any mistakes you might make while changing the sudoers file.

6
  • It is never a good idea to enable NOPASSWD against any/all commands, this means that anybody that gets on your system and manages to get a user into the sudo group will be able to do ANYTHING BAD to your system VERY quickly. I can easily do this with only a few minutes of access using a LiveCD or by tricking your user into running a cmd called sudo that uses your own permissions to add another user to the sudo group in addition to running your requested command.
    – dragon788
    May 22, 2017 at 20:05
  • 4
    Don't make blanket statements like this. On a headless system it's not desirable to set a login password at all (relying on keypairs instead) I have enabled full disk encryption so good luck with that live cd. (which by the way would allow you to do all sorts of fun things on an unencrypted system regardless of the sudoers file) Also you can't write to any of the locations in my PATH and I'm not giving you shell to begin with unless I trust you not to attempt to subvert the system. Your security concern is not invalid, it's simply outdated and not as universally applicable as you imply.
    – jorfus
    May 29, 2017 at 21:06
  • For those that don't have a deep understanding of security like you, this kind of recommendation is probably better than the alternative but I agree it's not ideal.
    – dragon788
    May 29, 2017 at 21:48
  • @dragon788 True enough, maybe we can both edit our responses to help users of all levels take a step towards better security. I'll add a warning to enable full disk encryption to prevent compromise when an attacker has physical access and a note that if a laptop user forgets to lock his or her computer in public, sudo nopasswd could lead to quick compromise. (Though I would propose setting a five minute lock and screen lock quick key could actually lead to better security.)
    – jorfus
    Jun 3, 2017 at 18:50
  • Excellent update, my answer doesn't have any strong recommendations other than these comments here, and ironically enough at work where I do use full disk encryption I've ended up enabling NOPASSWD because I have a very secure password that becomes a pain to type repeatedly, and I use xautolock to lock my machine after a short idle time.
    – dragon788
    Jun 16, 2017 at 15:29
7

Ideally if you are customizing what commands can be run via sudo you should be making these changes in a separate file under /etc/sudoers.d/ instead of editing the sudoers file directly. You should also always use visudo to edit the file(s).

Example: sudo visudo -f /etc/sudoers.d/slowcpu

Insert your line granting permission: gatoatigrado ALL=NOPASSWD: /bin/set-slow-cpufreq

Then save and exit and visudo will warn you if you have any syntax errors.

You can run sudo -l to see the permissions that your user has been granted, if any of the user specific NOPASSWD commands appear BEFORE any %groupyouarein ALL=(ALL) ALL command in the output you will be prompted for your password.

If you find yourself creating lots of these sudoers.d files then perhaps you will want to create them named per user so they are easier to visualize. Keep in mind that the ordering of the FILE NAMES and of the RULES within the file is very important, the LAST one loaded wins, whether it is MORE or LESS permissive than the previous entries.

You can control the file name ordering by using a prefix of 00-99 or aa/bb/cc, though also keep in mind that if you have ANY files that don't have numeric prefix, they will load after the numbered files, overriding the settings. This is because depending on your language settings the "lexical sorting" the shell uses sorts numbers first and then may interleave upper and lowercase when sorting in "ascending" order.

Try running printf '%s\n' {{0..99},{A-Z},{a-z}} | sort and printf '%s\n' {{0..99},{A-Z},{a-z}} | LANG=C sort to see whether your current language prints AaBbCc etc or ABC then abc to determine what the best "last" letter prefix to use would be.

6
  • I agree with this. Some of the logic in editing the /etc/sudoers file seemed counter intuitive - I could not get %wheel ALL=(ALL) NOPASSWD: ALL to work the way it was written in sudoers until I read a post where someone said the #includedir /etc/sudoers.d line had to be before the other lines like %SUDO and %WHEEL. When I put the #include dir above the other group permissions, they started working. So then I made files for each group in /etc/sudoers.d/ numbered in the same order they were in the sudoers file, but root ALL=(ALL) ALL had to still be sudoers below the #includedir line. Weird. Nov 27, 2017 at 14:41
  • Actually I think the includedir should remain at the end of sudoers. What you were probably seeing is one of the other files in your sudoers.d was undoing your change. You may have also had a line further down in your main file that was restricting the wheel group. Keep in mind that sudoers is processed where the last rule to apply to a command or group wins so being more specific helps but if a general ANY command comes at the end and doesn't have NOPASSWD it will override your previous exceptions. This is why you should have your rules in separate files so they are processed later.
    – dragon788
    Nov 27, 2017 at 15:18
  • I don't think so, it was a brand new install of arch. All I did was try and uncomment that one line. But that's definitely a good thing to check for, thanks. Nov 27, 2017 at 15:33
  • Some systems don't actually use wheel and instead use a group called sudo or adm or admin. I can't recall the Arch behavior but you can run id and see which groups you belong to.
    – dragon788
    Nov 27, 2017 at 16:14
  • Arch uses wheel. Nov 27, 2017 at 21:38
3

Besides the answer of @enzotib (add the line at the end of /etc/sudoers) also make sure to look at /etc/sudoers.d. After a Debian Buster install I had this file

$ sudo cat /etc/sudoers.d/10-installer
%sudo ALL=(ALL) ALL

which overwrote my rule at the end of the sudoers file. Strangely I also had the line

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

in /etc/sudoers. Therefor I assume /etc/sudoers.d/10-installer is an artefact of the installation. I deleted it and now it works.

4
  • Just found out about this myself. It was driving me CRAZY! It seems this is an issue with distributions that use the Calamares installer. In my case KDE Neon.
    – Paidhi
    Nov 25, 2020 at 6:55
  • I hope there is a bug report for this somewhere, such a time-consuming problem to have on a new install. Dec 22, 2020 at 18:11
  • In Debian bullseye/sid, which is now 'testing' and has kernel 5.10.9-1 this artifact do not appear. System was installed via netinstall as base system, and then task-xfce-desktop was added, among other things. Simple edits using visudo did not help, but enzotip answer pointed me to the right direction: LAST directive in a file matters most.
    – piotao
    Feb 3, 2021 at 0:29
  • 1
    @piotao: As Paidhi said, it seems to a affect the Calamares installer, not the netinstall you performed.
    – spawn
    Feb 3, 2021 at 16:49
0

On the remote system, drop the encryption, but let everything be owned by a root as in the group of "Administrators" - that is not 0!
You can amend #sudo -g Administrators to those that need full access - not in the sudo file, but .login profile. Any standard script now can have access to the remote as "root" and you can protect the files that must be protected.
Another handy "group" is "Sandbox" with a login directory in the browser cache and can read this freely and nothing else. Use upper case first character.

0

I encountered this issue when setting up a user to execute sudo commands without the need for the password prompts in Ubuntu.

I had created a file named my_user in the /etc/sudoers.d directory, that contained the following:

# User rules for my_user
my_user ALL=(ALL) NOPASSWD: ALL

Also, my_user was part of the sudo group after I ran the command below:

sudo usermod -aG sudo my_user

But when I run a sudo command to test it out like sudo ls, a password prompt pops up.

Here's how I solved it:

First I ran the command below to check the permissions of my user:

sudo -l -U my_user

And I got the output below:

(ALL : ALL) ALL
(ALL) NOPASSWD: ALL
(ALL) ALL

The last line of the output (ALL) ALL was overriding the (ALL) NOPASSWD: ALL permission.

After much investigation I found out that there is another file name waagent in the /etc/sudoers.d directory that contained:

my_user ALL = (ALL) ALL

All I had to do was either comment out the contents of the waagent file or delete the file entirely. And this made the contents of the my_user file in the /etc/sudoers.d directory to take precendence.

And this time everything worked fine.

You must log in to answer this question.

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