pam_unix(sudo:auth): conversation failed, auth could not identify password for [username]

Question

I'm using ansible to provision my Centos 7 produciton cluster. Unfortunately, execution of below command results with ansible Tiemout and Linux Pluggable Authentication Modules (pam) error conversation failed.

The same ansible command works well, executed against virtual lab mad out of vagrant boxes.

Ansible Command

$ ansible master_server -m yum -a 'name=vim state=installed' -b -K -u lukas -vvvv
123.123.123.123 | FAILED! => {
    "msg": "Timeout (7s) waiting for privilege escalation prompt: \u001b[?1h\u001b=\r\r"
}

SSHd Log

# /var/log/secure
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): conversation failed
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): auth could not identify password for [lukas]

Longobard

Sorry if the question seems dumb, but just to double check: Do you get the BECOME password: prompt when launching you ansible command ? Did you enter your pass for sudo there ? – Unlikelihood

There are no dumb questions :) Yes, I did it. – Longobard

Answer 1

I've found the problem. It turned out to be PAM's auth module problem! Let me describe how I got to the solution.

Context:

I set up my machine for debugging - that is I had four terminal windows opened.

• 1st terminal (local machine): Here, I was executing ansible prduction_server -m yum -a 'name=vim state=installed' -b -K -u username
• 2nd terminal (production server): Here, I executed journalctl -f (system wide log).
• 3rd terminal (production server): Here, I executed tail -f /var/log/secure (log for sshd).
• 4th terminal (production server): Here, I was editing vi /etc/pam.d/sudo file.

Every time, I executed command from 1st terminal I got this errors:

# ansible error - on local machine
Timeout (7s) waiting for privilege escalation prompt error.

# sshd error - on remote machine
pam_unix(sudo:auth): conversation failed
pam_unix(sudo:auth):  [username]

I showed my entire setup to my colleague, and he told me that the error had to do something with "PAM". Frankly, It was the first time that I've heard about PAM. So, I had to read this PAM Tutorial. I figured out, that error relates to auth interface located in /etc/pam.d/sudo module. Diging over the internet, I stambled upon this pam_permit.so module with sufficient controll flag, that fixed my problem!

Solution

Basically, what I added was auth sufficient pam_permit.so line to /etc/pam.d/sudo file. Look at the example below.

$ cat /etc/pam.d/sudo
#%PAM-1.0
# Fixing ssh "auth could not identify password for [username]"
auth       sufficient   pam_permit.so

# Below is original config
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so revoke
session    required     pam_limits.so
session    include      system-auth

Conclusion:

I spent 4 days to arrive to this solution. I stumbled upon over a dozens solutions that did not worked for me, starting from "duplicated sudo password in ansible hosts/config file", "ldap specific configuration" to getting advice from always grumpy system admins!

Note:

Since, I'm not expert in PAM, I'm not aware if this fix affects other aspects of the system, so be cautious over blindly copy pasting this code! However, if you are expert on PAM please share with us alternative solutions or input. Thanks!

Longobard

after adding this, I can sudo from the command line with no password at all. I'm seeing the same problem you were, but others should know this will disable sudo security (which does get rid of the error!) – Catadromous

Thanks for the input Bill, much appreciated. – Longobard

if it helps, a few hours later I discovered that my error was due to the order of files in /etc/sudoers. The files are loaded in ASCII order and a later 'ALL' was masking a NOPASSWD: /path/to/command that came earlier. I renamed the more restrictive file to 00_filename and then the error message we both encountered went away! Not sure if we had the same problem. – Catadromous

So after all it looks like sudo security, was not related to PAM. It has been almost a year since I wrote this answer and don't remember having password less access on sudo users on my side. Thank you for clarifying that. – Longobard

By doing this, you essentially skip all authentication steps and granted access. Not a secure step for production server. – Supernova

@Ding-YiChen Thank you for your input. This solution was hanging on the back of my head because I was not sure about security implications. Your, comment seems to clarifies it. Thanks! – Longobard

Good job getting to a conclusion on this. Helped me out +1 – Trelliswork

Answer 2

Assuming the lukas user is a local account, you should look at how the pam_unix.so module is declared in your system-auth pam file. But more information about the user account and pam configuration is necessary for a specific answer.

---

While adding auth sufficient pam_permit.so is enough to gain access. Using it in anything but the most insecure test environment would not be recommended. From the pam_permit man page:

   pam_permit is a PAM module that always permit access. It does nothing
   else.

So adding pam_permit.so as sufficient for authentication in this manner will completely bypass the security for all users.

Radiothorium

Answer 3

Found myself in the same situation, tearing my hair out. In my case, hidden toward the end of the sudoers file, there was the line:

%sudo ALL=(ALL:ALL) ALL

This undoes authorizations that come before it. If you're not using the sudo group then this line can safely be deleted.

Willowwillowy

if you never set up a password for root user, doing this you will lose access to any sudoer user – Asclepiadaceous

Answer 4

I got the same error when I tried to restart apache2 with sudo service apache2 restart

When logging into root I was able to see the real error lied with the configuration of apache2. Turned out I removed a site's SSL-Certificate files a few months ago but didn't disable the site in apache2. a2dissite did the trick.

Sweeney

Running apache service and broken ssl certs have nothing to do with pam_unix. The problem is more fundamental than that. Just disabling a site in apache is very unlikely to have any impact on this issue. Thus I down-voted your answer. – Longobard

Imho this makes my answer even more valid. Yes clearly there is a fundamental problem with PAM's auth module but many others running into this will probably prefer to avoid touching it and find what caused the error in the first place even though the proper error message is missing (this thread is #1 on Google for PAM's error message). In my case it was missing files in the apache config, could be something else for someone else obviously. Yet for many this will be exactly it as this happened on a basic LAMP installation. So no, I do not accept your downvote ;) – Sweeney

This page is the first result when looking for this error in reference to Apache, and this comment is the correct answer. For these cases, the problem is configuration of Apache, not specific to SSL. Do not modify PAM permit for an Apache configuration issue. – Boyce

upvote for "get different error messages when running apache2 as root" – Obscuration

Answer 5

I had this error since upgrading sudo to version 1.9.4 with pacman. I hadn't noticed that pacman had provided a new sudoers file.

I just needed to merge /etc/sudoers.pacnew. See here for more details: https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave

I know that this doesn't answer the original question (which pertains to a Centos system), but this is the top Google result for the error message, so I thought I'd leave my solution here in case anyone stumbles across this problem coming from an Arch Linux based operating system.

Waler

Answer 6

It's not related to Ansible but I had the same issue in my case, I need telegraf the service account to run sudo command in [inputs.exec]. Auth failed because it failed to input sudo password. So I added NOPASSWD but still failed with this error message:

# You can see the same errors using systemctl status telegraf.service or journalctl -u telegraf | tail -f
<date> <server name> sudo: pam_unix(sudo:auth): conversation failed
<date> <server name> sudo: pam_unix(sudo:auth): auth could not identify password for [telegraf]

The problem is double entries in my /etc/sudoers file and /etc/sudoers.d/.

# /etc/sudoers
%sudo ALL=(ALL:ALL) ALL
telegraf ALL=(ALL:ALL) ALL #this line should be removed

---

# /etc/sudoers.d/go
telegraf ALL=(ALL:ALL) NOPASSWD:ALL

After removing that line, and restarting the telegraf service (sudo systemctl restart telegraf), it works again.

Twi