1

I have a fairly basic setup where user accounts are distributed from an ansible server, along with passwords taken from /etc/shadow, on Ubuntu 20.04 systems. However, I have a few systems which seem to be having problems.

I generally log into them using an ssh key, so no password at that point. However, I regularly use my password while sudoing, and at some stage my password stops working. I can cut & paste it in, and it simply doesn't work, specifically stating "incorrect password attempts". If I try to su to my own account at this stage, it doesn't accept my password. My account is still unlocked and I can get into it using the ssh key, and the password field stored in /etc/shadow is identical to the one on the ansible server, and cutting and pasting my password into an ansible server login works, but doesn't on this client. The same thing eventually happens with the ansible login.

Can anyone provide any ideas as to what's going on here, or how to stop it happening again?

Thanks.

StuWhitby
  • 43

1 Answers1

1

The auth.log showed me the following, where I log in & sudo twice in a row (apologies for dodgy spacing, but it was just running lines together):

Sep 19 15:45:23 <server> sshd[4449]: Accepted publickey for <user> from 212.100.25.223 port 44560 ssh2: RSA SHA256:dat4CCgbWGDp06cC5qI1G4rjy5G6dSkbYdIRChVz3l0

Sep 19 15:45:23 <server> systemd: pam_unix(systemd-user:session): session opened for user <user> by (uid=0)

Sep 19 15:45:29 <server> sudo: : TTY=pts/1 ; PWD=/home/<user>; USER=root ; COMMAND=/usr/bin/su

Sep 19 15:45:29 <server> sudo: pam_unix(sudo:session): session opened for user root by <user> (uid=0)

Sep 19 15:45:29 <server> su: (to root) <user> on pts/2

Sep 19 15:45:29 <server> su: pam_unix(su:session): session opened for user root by <user>(uid=0)

Sep 19 15:46:55 <server> sshd[4607]: Accepted publickey for <user> from <IP> port 58146 ssh2: RSA SHA256:dat4CCgbWGDp06cC5qI1G4rjy5G6dSkbYdIRChVz3l0

Sep 19 15:46:55 <server> sshd[4607]: pam_unix(sshd:session): session opened for user <user> by (uid=0)

Sep 19 15:46:55 <server> systemd-logind[796]: New session 12 of user <user>

Sep 19 15:47:01 <server> sudo: pam_tally2(sudo:auth): user <user> (1012) tally 38, deny 5

That appears to be showing that the logins are accepted by pam_unix. However, there's a difference with the second session. The first shows a " systemd: pam_unix(systemd-user:session): session opened " message, the second doesn't. This is followed by the sudo attempt. The first works with "sudo: pam_unix(sudo:session): session opened for user root", while the second shows "sudo: pam_tally2(sudo:auth): user (1012) tally 38, deny 5".

That led me to a SUSE page which discusses this issue, and provides a workaround:

https://www.suse.com/support/kb/doc/?id=000018034

In both cases, the tally of failed logins increases rather than resets on successful authentication. Changing the following line in /etc/pam.d/common-auth works around the issue by setting the acceptable number of failed logins stupidly high:

auth required pam_tally2.so onerr=fail audit silent deny=50000 unlock_time=900

(deny was 5 previously).

I also looked at the services running on this server and noted the following:

● sssd-nss.socket loaded failed failed SSSD NSS Service responder socket> sssd-pac.socket loaded active listening SSSD PAC Service responder socket> ● sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder privat> ● sssd-pam.socket loaded failed failed SSSD PAM Service responder socket>

I haven't had a chance to look into those yet, but at least I can do so now that I can successfully elevate my account using a valid password!

Thanks to @steeldriver for the suggestion that got me to this point

StuWhitby
  • 43