Ubuntu 22.04: sudo not asking for password with empty sudoers.d and no "NOPASSWD" entry in /etc/sudoers

Weird thing, lately I noticed that every time I run a command with sudo, it doesn't ask for password.

Thing I've checked:

• /etc/sudoers.d = empty

myuser@MYPC:/etc/sudoers.d# ls
README
myuser@MYPC:/etc/sudoers.d# cat README 
#
# As of Debian version 1.7.2p1-1, the default /etc/sudoers file created on
# installation of the package now includes the directive:
# 
#   #includedir /etc/sudoers.d
# 
# This will cause sudo to read and parse any files in the /etc/sudoers.d 
# directory that do not end in '~' or contain a '.' character.
# 
# Note that there must be at least one file in the sudoers.d directory (this
# one will do), and all files in this directory should be mode 0440.
# 
# Note also, that because sudoers contents can vary widely, no attempt is 
# made to add this directive to existing sudoers files on upgrade.  Feel free
# to add the above directive to the end of your /etc/sudoers file to enable 
# this functionality for existing installations if you wish!
#
# Finally, please note that using the visudo command is the recommended way
# to update sudoers content, since it protects against many failure modes.
# See the man page for visudo for more information.
#

• /etc/sudoers = not even a single NOPASSWD entry

#
# 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:/snap/bin"
Defaults        use_pty

# This preserves proxy settings from user environments of root
# equivalent users (group sudo)
#Defaults:%sudo env_keep += "http_proxy https_proxy ftp_proxy all_proxy no_proxy"

# This allows running arbitrary commands, but so does ALL, and it means
# different sudoers have their choice of editor respected.
#Defaults:%sudo env_keep += "EDITOR"

# Completely harmless preservation of a user preference.
#Defaults:%sudo env_keep += "GREP_COLOR"

# While you shouldn't normally run git as root, you need to with etckeeper
#Defaults:%sudo env_keep += "GIT_AUTHOR_* GIT_COMMITTER_*"

# Per-user preferences; root won't have sensible values for them.
#Defaults:%sudo env_keep += "EMAIL DEBEMAIL DEBFULLNAME"

# "sudo scp" or "sudo rsync" should be able to use your SSH agent.
#Defaults:%sudo env_keep += "SSH_AGENT_PID SSH_AUTH_SOCK"

# Ditto for GPG agent
#Defaults:%sudo env_keep += "GPG_AGENT_INFO"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
#%admin ALL=(ALL) ALL

# 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

• groups: not knowing what else to try, I tried to leave my user in the only group sudo, but it didn't change anything, anyway this are the actual groups:

uid=1000(myuser) gid=1000(myuser) groups=1000(myuser),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),104(input),118(lpadmin),128(sambashare),133(libvirt),138(ubridge),143(render),997(docker)

as asked by muru, "sudo -l" output:

myuser@MYPC:~$ sudo -l
Matching Defaults entries for myuser on MYPC:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User myuser may run the following commands on MYPC:
    (ALL : ALL) ALL

BTW, I somehow managed to resolve the problem, just by copying the files from /etc/pam.d (that I never ever manually edited in the previous Ubuntu 20.04 and 18.04 and so on) from a new Virtual Machine with a fresh Ubuntu 22.04 installation.

So it appears it's something inherited from a previous Ubuntu version, in which the "pam.d" configuration was anyway having a different behaviour (sudo password was always asked).

I tried to do a diff of the files contained in the "pam.d" directory, but those are 44 files, so it's quite time consuming.

If someone is interested, I may post the output of the "diff" and we could try to investigate which line is causing this weird behaviour.

BTW, before doing this "raw" copy of pam.d files, I tried to investigate every single file related to authentication (like common-auth and so on) using Google and Linux doc in general, but I didn't find nothing meaningful.

Further investigation of difference between a "proper" setup and the setup "inherrited" somehow.

# cd /etc/pam.d ; diff -r . ~/pam-save-20230731/ -y --suppress-common-lines
diff -r -y --suppress-common-lines ./common-account /root/pam-save-20230731/common-account
account [success=1 new_authtok_reqd=done default=ignore]      | account [default=1]                     pam_permit.so
account sufficient                      pam_localuser.so      <
account [default=bad success=ok user_unknown=ignore]    pam_s <
diff -r -y --suppress-common-lines ./common-auth /root/pam-save-20230731/common-auth
auth    [success=2 default=ignore]      pam_unix.so nullok    | auth    [default=1]                     pam_permit.so
auth    [success=1 default=ignore]      pam_sss.so use_first_ <
diff -r -y --suppress-common-lines ./common-password /root/pam-save-20230731/common-password
password        requisite                       pam_pwquality | password        [default=1]                     pam_permit.so
password        [success=2 default=ignore]      pam_unix.so o <
password        sufficient                      pam_sss.so us <
diff -r -y --suppress-common-lines ./common-session /root/pam-save-20230731/common-session
session required        pam_unix.so                           <
session optional                        pam_sss.so            <
session optional        pam_systemd.so                        <
diff -r -y --suppress-common-lines ./common-session-noninteractive /root/pam-save-20230731/common-session-noninteractive
session required        pam_unix.so                           <

On a different system there was:

# diff -r -y --suppress-common-lines . ~/pam-20230731/
diff -r -y --suppress-common-lines ./common-account /root/pam-20230731/common-account
account [success=1 new_authtok_reqd=done default=ignore]      | account [default=1]                     pam_permit.so
account sufficient                      pam_localuser.so      <
account [default=bad success=ok user_unknown=ignore]    pam_s <
diff -r -y --suppress-common-lines ./common-auth /root/pam-20230731/common-auth
auth    [success=2 default=ignore]      pam_unix.so nullok    | auth    [default=1]                     pam_permit.so
auth    [success=1 default=ignore]      pam_sss.so use_first_ <
diff -r -y --suppress-common-lines ./common-password /root/pam-20230731/common-password
password        requisite                       pam_pwquality | password        [default=1]                     pam_permit.so
password        [success=2 default=ignore]      pam_unix.so o <
password        sufficient                      pam_sss.so us <
diff -r -y --suppress-common-lines ./common-session /root/pam-20230731/common-session
session required        pam_unix.so                           <
session optional                        pam_sss.so            <
session optional        pam_systemd.so                        <
diff -r -y --suppress-common-lines ./common-session-noninteractive /root/pam-20230731/common-session-noninteractive
session required        pam_unix.so                           <

pam-auth-update shows:

 │    [ ] Pwquality password strength checking                               │
 │    [ ] Unix authentication                                                │
 │    [ ] SSS authentication                                                 │
 │    [ ] Register user sessions in the systemd control group ...            │
 │    [*] Create home directory on login                                     │
 │    [*] Inheritable Capabilities Management                                │

Which obviously should have been:

 │    [*] Pwquality password strength checking                               │
 │    [*] Unix authentication                                                │
 │    [*] SSS authentication                                                 │
 │    [*] Register user sessions in the systemd control group ...            │
 │    [*] Create home directory on login                                     │
 │    [*] Inheritable Capabilities Management                                │

After setting the last settings everything is back to normal Also observed... ANY password would do on login/ssh etc etc. It would still ask for one but never validate it. This after seeing unix authentication wasn't required as well.

So this issue is bigger that it seemed to be.