I am having a random issue. I am having the same configuration for multiple servers, but only some of them are asking password from an excluded user:

Using username "a-u".
Authenticating with public key "rsa-key-20220705"
Linux i01.is-u.local 4.9.0-18-amd64 #1 SMP Debian 4.9.303-1 (2022-03-07) x86_64

a-u@i01:~$ sudo su -
[sudo] password for a-u:

The user is part of "sudo" group. Create a file under /etc/sudoers.d/ and declared "sudo" group like:

[/etc/sudoers.d]# cat nopasswd

Also, /etc/sudoers file is configured like:

[/etc]# cat sudoers
# This file MUST be edited with the 'visudo' command as root.
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
# See the man page for details on how to write a sudoers file.
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification
User_Alias ADMINS = a-u

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL
ADMINS  ALL = (ALL) NOPASSWD: ALL,!/usr/bin/passwd,!/usr/bin/passwd [A-z]*,!/usr/bin/passwd root

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

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Please help me find the problem. Thank you.


2 Answers 2


The pattern I've successfully used looks a little different from your nopasswd file:


If you look at your /etc/sudoers file, the ADMINS line is pretty much the same as this, with a list of excluded commands after the last ALL, so I believe it will work for you.

EDIT: In fairness, WhiteOwl posted the same solution a few minutes before this one. The OP accepted this answer because in a comment thread here, the OP reported trouble and troubleshooting found the cause was other files in the /etc/sudoers.d folder that were overriding the config in his nopasswd file. Sudo was reading the other files after his, and this allowed one of them to override his config.

To expand a little on this, sudo reads files in the order they are written and included in the /etc/sudoers file. When the sudoers file includes a folder/directory, sudo sorts the folder's filenames alphanumerically (per the locale's collation rules) and then reads the files in that order. It's pretty common to name files in such directories (like /etc/sudoers.d) with numeric prefixes to ensure sudo reads the files in the order you intend. I often see filenames like 10-sudoers-group, 20-admins-group, 99-special-admins, designed to control the order they are evaluated.


The proper syntax for your nopasswd file should be:

  • Already tried this syntax, and retried right now. Same behaviour. Not sure if it is related to sudoers files - for other similar systems, the same setup works fine. Is it possible that other modules can interfere? Got this in the auth log: sshd[20837]: pam_unix(sshd:session): session opened for user a-u by (uid=0) systemd-logind[1265]: New session 211 of user a-u. sshd[20837]: pam_unix(sshd:session): session closed for user a-u sudo: pam_unix(sudo:auth): conversation failed sudo: pam_unix(sudo:auth): auth could not identify password for [a-u] systemd-logind[1265]: Removed session 211.
    – RookieRoo
    Jul 14, 2022 at 17:03

You must log in to answer this question.

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