3

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]
dancal
  • 51
  • 1
  • 1
  • 6

3 Answers3

4

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
SRi
  • 1,046
  • 7
  • 10
2

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
dancal
  • 51
  • 1
  • 1
  • 6
0

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.

ouflak
  • 2,458
  • 10
  • 44
  • 49
Enver Uygun
  • 1