sshsudorsyncpam

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

I'm facing a weird behavior trying to run rsync as sudo through ssh with passwordless login. This is something I do with dozens of servers, I'm having this frustrating problem connecting to a couple of Ubuntu 18.04.4 servers

PREMISE

  1. the passwordless SSH from CLIENT to SERVER with account USER works nicely

  2. When I'm logged in SERVER I can sudo everything with account USER

  3. On SERVER I've added the following to /etc/sudoers

    user ALL=NOPASSWD:/usr/bin/rsync

Now, if I launch this simple test from machine CLIENT as user USER, I receive the following sudo error message:

$ ssh utente@192.168.200.135 -p 2310 sudo rsync
sudo: no tty present and no askpass program specified

Moreover, looking in the SERVER's /var/log/auth.log I found this errors:

sudo: pam_unix(sudo:auth): conversation failed
sudo: pam_unix(sudo:auth): auth could not identify password for [user]
Solution

  • I've found a solution thanks to Centos. Infact, because of the more complex configuration of /etc/sudoers in Centos (compared to Ubuntu or Debian), I've been forced to put my additional configurations to an external file in /etc/sudoers.d/ instead than putting it directly into /etc/sudoers

    SOLUTION:

    1. Putting additional configurations directly into /etc/sudoers wouldn't work
    2. Putting the needed additional settings in a file within the directory /etc/sudoers.d/ will work

    e.g. , these are the config lines put in a file named /etc/sudoers.d/my_config_file:

    Host_Alias MYSERVERHOST=192.168.1.135,localhost

# User that will execute Rsync with Sudo from a remote client
rsyncuser MYSERVERHOST=NOPASSWD:/usr/bin/rsync

    Why /etc/sudoers didn't work? It's unknown to me even after two days worth of Internet search. I find this very obscure and awful.

    What follows is a quote from this useful article: https://askubuntu.com/a/931207

    Unlike /etc/sudoers, the contents of /etc/sudoers.d survive system upgrades, so it's preferrable to create a file there than to modify /etc/sudoers.

    For the editing of any configuration file to be used by sudo the command visudo is preferable.

    i.e.

    $ sudo visudo -f /etc/sudoers.d/my_config_file