129

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

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

However, the output is:

$ 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.

And here is the content of /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

gatoatigrado
  • 1,883

6 Answers6

220

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).
enzotib
  • 96,093
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, 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 of 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.

jorfus
  • 284
8

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 artifact of the installation. I deleted it and now it works.

spawn
  • 251
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.

dragon788
  • 1,716
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.

abu_bua
  • 11,313
Knut H
  • 1
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.