I have the following two rules in separate files in sudoers.d. The user foobar is in the sudo group. The expectation is that the user foobar can login only via ssh with public key auth because their password is scrambled to a random value when their user is created. They should then set their password by running sudo passwd foobar after accessing the machine via ssh.

# /etc/sudoers.d/sudo-group
%sudo   ALL=(ALL) ALL

# /etc/sudoers.d/change-own-passwd
foobar  ALL = NOPASSWD: /usr/bin/passwd foobar

However, the user is still prompted for their password:

$ which passwd

$ sudo -ll
User foobar may run the following commands on bizbazz:

Sudoers entry:
    RunAsUsers: root
    Options: !authenticate
    /usr/bin/passwd foobar

Sudoers entry:
    RunAsUsers: ALL

$ sudo passwd foobar
[sudo] password for foobar: ^C
sudo: a password is required
  • 1
    Why would sudo continue searching after it matched the %sudo rule? Also, passwd with no parameter changes $USERs passwd. /bin/passwd is setuid root for this purpose. Read man passwd.
    – waltinator
    Mar 8, 2021 at 5:32
  • @waltinator passwd will only change a user's password if they know the existing password. If their account is locked or if their password is scrambled (i.e., a new user account) then they cannot use passwd to change their own password, even if they have access via ssh.
    – Huckle
    Mar 8, 2021 at 6:26
  • That being said, order does seem to matter with the sudo rules. Moving the files to 000-sudo-group and 100-change-own-passwd ensures that the last matching rule is the desired one. There are a couple of strategies I could see the authors of sudo selecting (first, last, most specific) and I don't see any clear reason to pick 'last' over any other strategy.
    – Huckle
    Mar 8, 2021 at 6:29

1 Answer 1




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

From man 5 sudoers

So order matters when applying the rules. Changing the names to be lexicographically ordered (000-sudo-group and 100-change-own-passwd) worked around the issue.

You must log in to answer this question.

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