3

I am using Ubuntu 16.04.3 LTS Server. I have a user with sudo privileges on it. When I attempt to switch from my current user to root, it asks for my password. I enter the correct password and it refuses my password.

username@server:/ sudo su
[sudo] password for username:
Sorry, try again.
[sudo] password for username:
Sorry, try again.
[sudo] password for username:
sudo: 3 incorrect password attempts

Fortunately, I have another terminal window open where I am still logged in as root. So I attempted to reset the password for my user. It says I have updated the user successfully.

root@server:/# passwd username
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

So I then attempt to the sudo su command again. It fails with the same messages.

I open a new terminal window for the same user and attempt to sudo su and the same command fails with the same messages.

I also tried unlocking the user sudo usermod --expiredate -1 username. This also did not resolve the issue.

I also tried granting the user "sudo" rights usermod -aG sudo username. And the user still had the issue.

I gave up and just created a new user with sudo rights and started using the new user. The next day I started having the exact same problems with the new user.

The pwck command lists several system accounts and messages about their home directories, but nothing else. The grpck command gives no message at all.

We recently added "pam" authentication about a month ago.

/etc/pam.d/sudo

#%PAM-1.0

session    required   pam_env.so readenv=1 user_readenv=0
session    required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
@include common-auth
@include common-account
@include common-session-noninteractive

/etc/pam.d/common-auth

auth    required        pam_tally2.so deny=5 unlock_time=600
# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth    optional                        pam_cap.so
# end of pam-auth-update config

/etc/pam.d/common-account

# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
# here's the fallback if no module succeeds
account requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

/etc/pam.d/common-session-noninteractive

# here are the per-package modules (the "Primary" block)
session [default=1]                     pam_permit.so
# here's the fallback if no module succeeds
session requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# 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)
session required        pam_unix.so
# end of pam-auth-update config

Thanks to @telcoM and @roaima I found that the pam authentication module is the cause of the problem.

root@server:/# pam_tally2
Login           Failures  Latest    failure     From
username           53    06/05/18   16:53:42    xxx.xxx.xxx.xxx

While I have found the cause of the problem, I do not understand the behavior. Maybe I have something configured incorrectly in the pam module. Every time I type sudo su (success or not) a failure is added to the pam_tally2. I have no idea why successfully typing the correct password would increment the failure attempts, but it is. Example below.

pam_tally2
Login           Failures  Latest    failure     From
username           0    06/05/18   16:53:42    xxx.xxx.xxx.xxx

username@server:/ sudo su
[sudo] password for username:
root@server:/#

pam_tally2
Login           Failures  Latest    failure     From
username           1    06/05/18   16:54:03    xxx.xxx.xxx.xxx

Using the sudo -s or sudo -i also result in incrementing the failures in the pam_tally2.

  • Usually the # sign in the prompt means that you're already root. Do you have a customized prompt? Please run the whoami command to verify that the account you're currently on is what you think it is. As root, you might also want to run the pwck and grpck commands - they will verify the integrity of the /etc/passwd, /etc/shadow and /etc/group files. You'll get some messages reporting that some system accounts don't actually have a home directory; that's normal. Any other messages might indicate a problem. – telcoM Jun 1 '18 at 8:01
  • @telcoM The # sign above was a typo, I've fixed the example. I ran the pwck command and it listed several system accounts and messages about their home directories, but nothing else. The grpck command gave no message at all. – Daryl Jun 1 '18 at 14:59
  • Have you checked the system logs under /var/log/? In particular, /var/log/auth.log might have a more detailed description of the problem. Or have you added new PAM modules or otherwise changed the authentication configuration of the system lately? /etc/pam.d/sudo describes the PAM authentication configuration for the sudo command: it might have just @include lines referring to other files in the same directory. Have those files been changed recently? – telcoM Jun 2 '18 at 6:33
  • @telcoM I looked at the /var/log/auth.log file. The only thing that stood out to me were people attempting to log in with invalid users (Hacking attempts. It seems like any time I put a public IP Address on something, people attempt to log in.) We did add PAM authentication about a month ago to add an additional layer of security. I've updated my question with the config options you mentioned. – Daryl Jun 4 '18 at 22:09
  • 1
    @roaima @telcoM I found out what is creating the failures in the pam_tally2 command. Every time, I type sudo su and successfully log in, it adds a failure to the pam_tally2 even though I've successfully typed the password and logged in. – Daryl Jun 5 '18 at 16:06
1

You mentioned that there are continuous login attempts from unauthorised external users. If these unwanted remote login attempts referencing root or your username user account it may mean that the pam_tally2 PAM module is locking one or both of them out.

Run the pam_tally2 command to see what is creating the failures. (You may need to run pam_tally2 --user=username --reset to reset the block on username.

Alternatively, this problem report The pam_tally2 counts a good password as a failed login attempt if "ChallengeResponseAuthentication yes" is set in /etc/ssh/sshd_config file may describe your scenario more closely. (I'm still working on finding an alternate source for a solution.)


Incidentally, despite all the best (but wrong) efforts of Canonical, you shouldn't ever need to use sudo su for anything. (It's like saying "Give me root? OK thank you. Now I'm root, I need to become root".) Try sudo -s for a root shell or sudo -i for a root login shell.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.