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?
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)
]]>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.
]]>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...
]]>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
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
"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.
]]>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
]]>one of my servers
It's running Archlinux or another linux? All arch packages are up-to-date? Nothing blacklisted ?
]]>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?
]]>