相关文章推荐
睿智的葫芦  ·  解决RStudio中"plot.new() ...·  4 月前    · 
咆哮的抽屉  ·  Cookie.Expires() ...·  7 月前    · 
心软的鼠标  ·  BorderLayout_百度百科·  1 年前    · 
近视的胡萝卜  ·  python repo python ...·  1 年前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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

Ask Question

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

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

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

  • 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]
    

    am not an PAM expert, but tested the following solution working on Ubuntu 16.04.5 and 20.04.1

    NOTE : Configuration set to default on /etc/ssh/sshd_config

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

    add the below lines

    my_username ALL=(ALL) NOPASSWD:ALL
    

    and don't forget to restart sshd

    $ sudo systemctl restart sshd
    

    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:

  • Putting additional configurations directly into /etc/sudoers wouldn't work
  • 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.

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

    I had a similar problem on a custom linux server, but the solution was similar to the answers above. As soon as I removed the line your_user ALL=(ALL) NOPASSWD:ALL from /etc/sudoers, the errors were gone.

    Thanks for contributing an answer to Stack Overflow!

    • Please be sure to answer the question. Provide details and share your research!

    But avoid

    • Asking for help, clarification, or responding to other answers.
    • Making statements based on opinion; back them up with references or personal experience.

    To learn more, see our tips on writing great answers.