Vous avez besoin d'une méthode pour fournir le mot de passe à sudo . Un askpass est conçu pour demander des mots de passe lorsque les mécanismes habituels ne sont pas disponibles. La mise en place d'un sudo de ne pas exiger de mot de passe pour fonctionner rsync en tant qu'identifiant est une option.

Dans des cas comme celui-ci, je configure normalement une connexion basée sur une clé avec des restrictions appropriées. Si vous configurez une clé restreinte qui ne peut être exécutée qu'en mode rsync en tant que racine, ce genre de choses devient plus facile à faire. Une autre alternative est d'utiliser un rsycnd pour traiter les demandes à distance. La configuration fournit une variété de restrictions qui peuvent être appliquées.

EDIT : J'ai inclus un script pour configurer les clés pour les loings basés sur les clés dans la section Créer des Userids sur les clients de mon post sur Mise en place de BackupPC sous Linux . Voir aussi la documentation de ssh_config qui détaille certaines des choses que vous pouvez faire en restreignant l'utilisation des clés comme le montre le script.

Voici ce qui a fonctionné pour moi, sachant que je veux conserver l'authentification par mot de passe (je ne veux donc pas utiliser la fonction NOPASSWD ou des clés) - sur Ubuntu 14.04 :

• "Ouvrez" sudo sur la machine distante en désactivant tty_tickets par l'intermédiaire d'un fichier temporaire dans /etc/sudoers.d/ (qui devrait être pris en charge par Debian, voir /etc/sudoers.d/README ), et "Update the user's cached credentials", qui "prolonge le délai d'attente de sudo de 15 minutes supplémentaires"
• Exécuter le rsync con sudo comme indiqué dans d'autres réponses
• "Fermer sudo sur la machine distante en supprimant le fichier temporaire dans /etc/sudoers.d/ qui réactive la fonction tty_tickets

... ou, avec des lignes de commande :

ssh -t $REMOTEPC 'echo "Defaults !tty_tickets" | sudo tee /etc/sudoers.d/temp; sudo -v'
rsync -aP -e 'ssh' '--rsync-path=sudo rsync' /etc/pulse/client.conf $REMOTEPC:/etc/pulse/client-copy.conf
ssh -t $REMOTEPC 'sudo rm -v /etc/sudoers.d/temp; sudo -v'

Voici les réponses que j'obtiens lorsque j'exécute ces commandes sur la machine locale :

$ ssh -t $REMOTEPC 'echo "Defaults !tty_tickets" | sudo tee /etc/sudoers.d/temp; sudo -v'
remoteuser@$REMOTEPC's password: 
[sudo] password for remoteuser: 
Defaults !tty_tickets
Connection to $REMOTEPC closed.

$ rsync -aP -e 'ssh' '--rsync-path=sudo rsync' /etc/pulse/client.conf $REMOTEPC:/etc/pulse/client-copy.conf
remoteuser@$REMOTEPC's password: 
sending incremental file list
client.conf
           1269 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)

$ ssh -t $REMOTEPC 'sudo rm -v /etc/sudoers.d/temp; sudo -v'
remoteuser@$REMOTEPC's password: 
removed ‘/etc/sudoers.d/temp’
[sudo] password for remoteuser: 
Connection to $REMOTEPC closed.

Il convient de noter que sudo -v doit être exécuté après chaque fichier de temps dans /etc/sudoers.d/ Les modifications qui y sont apportées sont donc acceptées.

Une autre méthode consiste à contourner les restrictions de permissions en lançant rsync sur la machine distante. Au lieu de :

rsync /home/ubuntu/my/lovely/folder ubuntu@x.x.x.x:/remote/lovely/folder

Vous pouvez le faire :

ssh ubuntu@x.x.x.x 'rsync ubuntu@y.y.y.y:/home/ubuntu/my/lovely/folder /remote/lovely/folder'

Dónde y.y.y.y est l'adresse IP de votre machine locale. Cela ne fonctionne que si votre machine locale peut agir en tant que serveur SSH.

Ma méthode de travail consiste à ajouter --rsync-path="echo PASSWORD | sudo -Sv && sudo rsync"

exemple :

rsync -avz -e ssh /home/ubuntu/my/lovely/folder ubuntu@x.x.x.x:/remote/lovely/folder --delete --rsync-path="echo <PASSWORD> | sudo -Sv && sudo rsync"

Ce n'est généralement pas une bonne idée de mettre des mots de passe dans une ligne de commande ; ils deviennent visibles dans l'arborescence du processus, par exemple. Je remplace parfois le mot de passe réel dans ce type de déclaration par $( cat mon_mot_de_passe.txt ), ce qui est légèrement mieux

rsync -avz -e ssh /home/ubuntu/my/lovely/folder ubuntu@x.x.x.x:/remote/lovely/folder --delete --rsync-path="cat my_password.txt | sudo -Sv && sudo rsync"

Exécuter un cronjob en arrière-plan

Ok, vous avez plusieurs options.

Ceux qui précèdent sont assez bons lorsqu'il s'agit de rsync en tant qu'utilisateur normal avec des permissions sudo sur le(s) côté(s) opposé(s).

J'ai eu le même problème, à la seule différence que je voulais l'exécuter en tant que cronjob la nuit.

Étape 1

Je travaille avec clés ssh (cela permet de se connecter à un hôte distant sans authentification par mot de passe tout en étant très sûr !)

1. Créez une clé ssh sur votre ordinateur source (serveur) à l'aide de la commande suivante :

   ssh-keygen

Quelques options vous seront proposées, il vous suffit d'appuyer sur la touche Entrée à chaque fois (n'entrez pas de mot de passe !!).

Cette commande crée deux clés différentes. 1. Une clé id_rsa_pub : cette clé doit être copiée sur l'hôte distant (serveur de destination). 2. Une clé id_rsa : il s'agit d'une clé privée que vous ne devez pas manipuler. Assurez-vous que personne ne peut voir cette clé (permissions de lecture). Vous seul devez avoir le droit de voir cette clé.

Étape 2

2. Une fois les clés générées, il est temps de copier la clé id_rsa_pub sur l'ordinateur distant (serveur). Vous pouvez le faire à l'aide de la commande suivante :

   ssh-copy-id user@remoteserver.example

Il vous sera demandé de saisir votre mot de passe pour l'accès ssh par défaut. Entrez simplement votre mot de passe et la commande ssh-copy-id fera le reste pour vous.

Le temps de tester

3. Maintenant, connectez-vous au serveur distant (la destination que vous avez utilisée avec la commande ssh-copy-id).

Vous pouvez considérer que le test est réussi si vous n'êtes pas invité à entrer un mot de passe.

Vous pouvez maintenant effectuer des commandes rsync vers un hôte distant sans avoir à saisir un mot de passe à chaque fois ! De plus, il est possible de faire de l'autocomplétion sur l'hôte de destination à partir de l'hôte source. C'est plutôt sympa si vous voulez mon avis (exemple ssh 192.168.1.100 : "press two time the tab button to autocomplete the rest of the command. Notez que l'adresse IP 192.168.1.100 est l'adresse IP du serveur de destination).

Vous pouvez maintenant effectuer une commande rsync à partir d'un cronjob avec un utilisateur "sudo" normal (il n'est pas nécessaire d'avoir un accès root sur les deux serveurs pour ssh afin d'utiliser l'utilisateur root).

Il suffit de faire la même chose que ce qui est décrit ci-dessus, mais d'ajouter une option :

sudo rsync --rsync-path="sudo rsync" -az --delete -e "ssh -p 1022 -l **buser** -i /home/**buser**/.ssh/id_rsa" /path/to/rsync user@destinationserver.example:

Notez que buser (BackupUSER, est mon utilisateur qui utilise la clé ssh pour se connecter via ssh sans être invité à entrer un mot de passe). Changer buser à votre nom d'utilisateur qui utilise la méthode de connexion ssh-key.

Notez que le dernier caractère de la commande se termine par un " :" Cela signifie que vous copiez des fichiers dans le dossier personnel de l'utilisateur distant. Si vous souhaitez dévier vers un autre emplacement que votre répertoire personnel, vous pouvez le faire en ajoutant le chemin d'accès absolu après l'attribut " :" Par exemple :

sudo rsync --rsync-path="sudo rsync" -az --delete -e "ssh -p 1022 -l **buser** -i /home/**buser**/.ssh/id_rsa" /path/to/rsync user@destinationserver.example:/srv/backup_folder

Explication de l'option "ssh -p 1022 -l username -i /home/username/.ssh/id_rsa"

ssh -p 1022 ssh utilise le port 22 par défaut. Je m'écarte du port par défaut parce que mon serveur ssh écoute le port 1022.

-l nom d'utilisateur l'utilisateur défini qui peut se connecter à l'hôte distant avec la méthode d'authentification ssh-key. Dans mon cas, il s'agit de l'utilisateur BUSER .

-i (Identité) utilise la clé privée que nous avons créée avec la commande ssh-keygen. Elle indique l'endroit où cette clé est stockée. L'emplacement par défaut est le dossier personnel de l'utilisateur, dans un répertoire caché appelé ssh (/home/nomutilisateur/.ssh/id_rsa). .

J'espère que cela aidera d'autres utilisateurs à automatiser leur sauvegarde via cron de manière sécurisée.

Double vérification

Depuis la machine source (serveur), assurez-vous d'exécuter votre commande (script) en tant qu'utilisateur ROOT (si vous créez un cronjob, vous devez vous assurer que vous êtes l'utilisateur root (#) lors de la création du cronjob).

Assurez-vous que l'utilisateur sur le serveur de destination a les droits sudo.

Assurez-vous d'avoir fait le visudo comme le décrit Keith dans sa réponse !