sudo sporadically failing with "conversation failed"

juphu2Va · 2020-08-23 19:24:42

Hey,

so I've got this problem I can't figure out:

Sporadically, one of my servers doesn't accept the user's password anymore (for example when becoming root using "sudo su").

When trying to do "sudo su", the syslog states:

pam_unix(sudo:auth): conversation failed

I am 100% sure that the password is correct, since I copy it from my password manager.
Also, anything which shows up from a google search, has already been tried. (I have not changed anything in the sudoers)

What's strange is that this issue only occurs sporadically, but isn't fixed by a reboot if it happens. Also beginning a new ssh session doesn't fix it.

Anyone got an idea?

ua4000 · 2020-08-27 16:10:35

juphu2Va wrote:

one of my servers

It's running Archlinux or another linux? All arch packages are up-to-date? Nothing blacklisted ?

juphu2Va · 2020-08-27 16:23:57

> It's running Archlinux or another linux?

Yes, of course. I wouldn't post it on the Archlinux forum otherwise.

> All arch packages are up-to-date?

Yes

> Nothing blacklisted ?

Yes, no package is blacklisted

Head_on_a_Stick · 2020-08-27 17:40:00

juphu2Va wrote:

"sudo su"

That's just silly:

sudo -i

Anyway, please post the contents of /etc/sudoers, /etc/pam.d/sudo and /etc/pam.d/su.

juphu2Va · 2020-08-27 20:30:16

Head_on_a_Stick wrote:

juphu2Va wrote:
"sudo su"
That's just silly:
sudo -i

Well, I've done it like this for the last 5 years at least, for me it's easier to type

Head_on_a_Stick wrote:

Anyway, please post the contents of /etc/sudoers, /etc/pam.d/sudo and /etc/pam.d/su.

nothing special, only the sudo group was de-commented in the sudoers file, the other files are untouched.

sudoers:

# .. much commented stuff left out

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

## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL

## Uncomment to allow members of group sudo to execute any command
 %sudo  ALL=(ALL) ALL

# .. more commented stuff

/etc/pam.d/sudo:

#%PAM-1.0
auth            include         system-auth
account         include         system-auth
session         include         system-auth

/etc/pam.d/su:

#%PAM-1.0
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            required        pam_unix.so
account         required        pam_unix.so
session         required        pam_unix.so

Head_on_a_Stick · 2020-08-29 11:01:11

So does 'sudo -i' work as expected? I don't have any servers so I can't really help directly (sorry).

seth · 2020-08-29 11:40:33

Remote server or do you (optionally) have physical access?

juphu2Va · 2020-09-05 18:09:43

It's a remote server, I have no physical access.

It just happened to me again, on another device, a ArchLinux-arm Server (raspberry pi), so I could try "sudo -i". Unfortunately, doesn't work.

Now sudo works again for the RPi (after I closed all ssh sessions). I now suspect it has something to do with ssh...

Last edited by juphu2Va (2020-09-05 18:11:28)

maxweiss · 2020-09-12 18:12:45

I ran into this exact issue as well. It's a combination of two things. First, the file /etc/pam.d/system-auth was updated with the most recent PAM update, and it includes using a new fail module that blocks access for your user temporarily across all terminals (rather than just the current one) on multiple incorrect password attempts. Secondly, I had a startup service script running that was trying to use sudo and failing multiple times, and I just never noticed until I looked at my logs and journalctl. So at startup, I had a background process that was trying and failing to run sudo, which caused the new pam module to kick in and block sudo access everywhere for the default fail timeout period.

While I was attempting to diagnose which process was causing the sudo failes, my quick-fix was to revert the system-auth file to what it was before the update, the version that doesn't use the new homed and fail modules. Then, once I isolated the problem script, using the new system-auth file didn't cause all this hassle.

Last edited by maxweiss (2020-09-12 18:15:10)

juphu2Va · 2020-09-12 18:28:16

Thanks for the post and hint.

I don't have any startup screen which does use sudo or otherwise tries to login as my user however.

Also, when forcing to login with a locked account, the syslog doesn't show "conversation failed" (I've just tried in on my laptop via two tty's, the log specifically said that the account was locked)

seth · 2020-09-12 18:58:44

What bothers me is the sporadic thing - there's either a network error or you're running out of file descriptors or something.

When this fails can you
a) open a new ssh connection
b) run a subshell (bash)
c) run a login shell (bash -l)
d) physically access the raspi (assuming it's the ssh server), ssh into itself (ssh localhost) and try sudo there?

Arch Linux

#1 2020-08-23 19:24:42

sudo sporadically failing with "conversation failed"

#2 2020-08-27 16:10:35

Re: sudo sporadically failing with "conversation failed"

#3 2020-08-27 16:23:57

Re: sudo sporadically failing with "conversation failed"

#4 2020-08-27 17:40:00

Re: sudo sporadically failing with "conversation failed"

#5 2020-08-27 20:30:16

Re: sudo sporadically failing with "conversation failed"

#6 2020-08-29 11:01:11

Re: sudo sporadically failing with "conversation failed"

#7 2020-08-29 11:40:33

Re: sudo sporadically failing with "conversation failed"

#8 2020-09-05 18:09:43

Re: sudo sporadically failing with "conversation failed"

#9 2020-09-12 18:12:45

Re: sudo sporadically failing with "conversation failed"

#10 2020-09-12 18:28:16

Re: sudo sporadically failing with "conversation failed"

#11 2020-09-12 18:58:44

Re: sudo sporadically failing with "conversation failed"

Board footer