1
  • The problem is happening on a remote server, so everything is done through ssh.
  • I can login with my key, no problem here.
  • I can change my password at will with passwd (which I believe shows that it's the correct password for my user).
  • My user is in the sudoers file (I could check with pkexec cat /etc/sudoers and entering the root password)

However, being logged in as my regular user, I can't run sudo commands anymore, it just says Sorry, try again as if the password was mistyped.

I have no clue what causes that, I've tried changing my password, which I could, but it doesn't solve the sudo problem.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.10
Release:        12.10
Codename:       quantal
1
  • 1
    Are you the adminstrator for the remote server? It is possible that someone changed the PAM module sudo uses to authenticate its users, and that whatever that is set to is different to the system that passwd is using for authentication. You can use this when setting up different passwords for sudo and for shell login.
    – Aaron D
    Dec 28, 2013 at 13:53

2 Answers 2

2

Ok, fixed it, but I don't really know what caused it in the first place.

The issue was from a line in /etc/pam.d/common-session-noninteractive

It had

session [success=1 default=ignore] pam_succeed_if.so service in cron 
quiet use_uid

And it appears that having this on two lines instead of one was breaking PAM completely. I just changed it to

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

And now everything is back to normal.

I have to thank @AaronD for his comment as it pointed me to investigat PAM, which I found nothing wrong at first (looking at /etc/pam.d/sudo) but when I looked at /var/log/auth.log and noticed all the PAM errors I felt I was digging in the right direction.

The log entry looked like these :

Dec 28 15:43:33 srv12120 sudo: PAM (sudo) illegal module type: quiet
Dec 28 15:43:33 srv12120 sudo: PAM pam_parse: expecting return value; [...use_uid]
Dec 28 15:43:33 srv12120 sudo: PAM (sudo) no module name supplied

A little bit of googling gave me this forum post which gave me the solution highlighted above.

0

I recently encountered this exact problem, through I had to solve it slightly differently. The cause was very similar.

Basically, in my case, somehow, /etc/pam.d/common-session-noninteractive had gotten slightly corrupted in a rather bizarre manner. My common-session-noninteractive looked like this:

# since the modules above will each just jump around
session required                        pam_permit.so
# The pam_umask module will set the umask according to the system default in
# /etc/login.defs and user settings, solving the problem of different
# umask settings with different shells, display managers, remote sessions etc.
# See "man pam_umask".
session optional                        pam_umask.so
# and here are more per-package modules (the "Additional" block)
Dec 25 11:45:01 websrv CRON[44085]: pam_unix(cron:session): session opened for user root by (uid=0) session 
required                        pam_unix.so
# end of pam-auth-update config

The issue is the Dec 25 11:45:01 websrv CRON[44085]: pam_unix(cron:session): session opened for user root by (uid=0) text, that apparently somehow got inserted into the pam configuration file.

My assumption here, and I'm really, really guessing, is that a script was modifying this file from a tty attached to the kernel auth log somehow, and it accidentally cated or echoed the text into the file. I've never touched anything pam related.

In any event, it was simple to fix once I found the issue, but the debug output was certainly rather unclear.

You must log in to answer this question.

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