Pourquoi ce travail cron rsync + ssh me donne-t-il des erreurs «Autorisation refusée (publickey)»?

Je fais des sauvegardes fréquentes sur un disque local que je souhaite synchroniser quotidiennement avec un serveur distant.

Le serveur cible est configuré pour l'accès par clé SSH (pas de mot de passe) uniquement. Étant donné que ma clé SSH principale pour ce serveur est protégée par une phrase secrète, j'ai créé une deuxième clé SSH (non protégée par une phrase secrète) + utilisateur à utiliser pour les sauvegardes sans assistance - de cette façon, je n'ai pas besoin d'être présent pour saisir ma phrase secrète lors de l'exécution de cron .

J'utilise cron et rsync, et toutes les commandes fonctionnent individuellement, mais échouent lorsqu'elles sont combinées.

Le plus loin que j'ai obtenu pendant le dépannage est en cours d'exécution

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/"

qui renvoie l'erreur

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.0]

Des conseils sur la façon de résoudre ce problème davantage?

Voici ce que j'ai essayé jusqu'à présent et je suis à court d'idées:

1. Cron tourne définitivement ps aux | grep cron

2. Rien d'inhabituel dans / var / log / syslog Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

3. SSH dans le terminal vers le serveur distant pendant le travail de l'utilisateur de sauvegarde ssh [email protected]

4. L'exécution de la commande dans Terminal fonctionne parfaitement rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

5. La spécification manuelle du chemin d'accès à la clé de sauvegarde-utilisateur n'a aucun effet rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

6. Remplacer la commande non fonctionnelle par une commande de test simple fonctionne echo "Hello world" > ~/Desktop/test.txt

7. Crier / jurer devant l'ordinateur n'a eu aucun effet (mais m'a fait me sentir mieux temporairement).

Modifier 1:

Voici mon fichier crontab et le script qu'il appelle.

...
# m h  dom mon dow   command
MAILTO=""
* * * * * sh /home/tom/Documents/Scripts/offsite-backup

et

#!/bin/bash

rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

Modifier 2:

Juste pour clarifier, /var/log/auth.logsur le serveur cible contient la ligne Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootC'est déroutant car je n'exécute plus cron toutes les minutes localement, mais une nouvelle entrée apparaît toujours toutes les minutes dans les journaux du serveur. Fichiers Crontab pour tous utilisateurs (y compris root) sur le serveur sont vides et ne font rien.

De plus, les «sauvegardes uniquement» de l'utilisateur ont été créées uniquement sur le serveur et avec des droits limités, avec une clé SSH dédiée copiée sur ma machine de bureau. Je suppose que c'est la voie à suivre car tout fonctionne lors de l'exécution manuelle des commandes.

Le fichier crontab affiché ci-dessus est pour moi, l'utilisateur 'tom' sur ma machine de bureau. Mon intention est de le faire appeler le script qui devrait se connecter au serveur en tant qu'utilisateur «sauvegardes uniquement». J'ai juste essayé d'exécuter le script de sauvegarde (plutôt que la commande à l'intérieur) et il a réussi à se connecter et à fonctionner. Je l'ai exécuté sur mon bureau en tant qu'utilisateur 'tom', le même utilisateur qui a créé le travail cron qui ne fonctionnera pas. Voici la sortie du journal du serveur correspondant à cette connexion réussie

Sep 11 08:35:31 <hostname> sshd[25071]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Sep 11 08:35:32 <hostname> sshd[25071]: Accepted publickey for backups-only from <desktop IP> port 54242 ssh2: RSA e2:e6:07:27:c1:continues...
Sep 11 08:35:32 <hostname> sshd[25071]: pam_unix(sshd:session): session opened for user backups-only by (uid=0)
Sep 11 08:35:32 <hostname> systemd-logind[638]: New session 12 of user backups-only.
Sep 11 08:36:00 <hostname> sshd[25133]: Received disconnect from <desktop IP>: 11: disconnected by user
Sep 11 08:36:00 <hostname> sshd[25071]: pam_unix(sshd:session): session closed for user backups-only

Étant donné que tout fonctionne correctement à partir de la ligne de commande, l'erreur Permission denied (publickey)signifie que la partie SSH dersync utilise un fichier d'identité différent de celui du nom d'utilisateur spécifié.

À partir du commentaire de Jan sur la question d'origine, nous pouvons spécifier le fichier d'identité dans la rsynccommande en utilisant -e 'ssh -i /path/to/identity.file' ....

L'utilisation de la commande ci-dessous pour commencer avec un nouvel environnement dans cron et en spécifiant le chemin d'accès complet au fichier résout apparemment le problème:

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/"

_{Je suis toujours très intéressé par cette découverte. Cela a probablement à voir avec cron, le fait qu'il commence avec des variables d'environnement minimales et l'agent ssh. Je mettrai en place le même scénario dans quelques jours pour le tester et faire rapport.}

Je viens de résoudre ce problème qui m'a occupé ..

Impossible de se connecter en RSYNC sur SSH, malgré avoir stipulé l'identité de SSH ... Rien n'est fait ... Rsync dit "permission refusée" et ssh me dit "read_passphrase: impossible d'ouvrir / dev / tty: Aucun périphérique ou adresse de ce type"

Mais j'ai lu un article qui expliquait que le crontab a son propre environnement qui n'est pas le même que root. Je le savais déjà, mais je ne comprenais pas l'impact que cela pouvait avoir sur SSH lors de l'utilisation de SSH-AGENT

Mais mes échanges de clés SSH se font avec PassPhrase ... donc si l'environnement est différent et mon RSYNC sur SSH attend une phrase secrète qui ne peut pas être entrée => les informations de débogage SSH indiquent également l'erreur:

"debug1: read_passphrase: impossible d'ouvrir / dev / tty: aucun périphérique ou adresse de ce type" => Eh bien oui non TTY = pas de phrase secrète = non autorisé

Sur ma machine, j'utilise "Keychain" pour lancer l'agent SSH, donc je n'ai pas à ressaisir la phrase secrète à chaque fois que j'essaye une connexion à distance. Le trousseau génère un fichier qui contient les informations suivantes

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891; export SSH_AUTH_SOCK; SSH_AGENT_PID = 18893; export SSH_AGENT_PID;

==> La commande SSH-AGENT renvoie les mêmes informations.

Donc, au final, ce sont ces informations liées à la session en cours qui permettent de futures authentifications de la session en cours, sans avoir besoin de saisir la phrase secrète car déjà faite précédemment et mémorisée ...

==> La solution est là ... il suffit dans le script lancé par la crontab, et de "source" le fichier contenant ces informations ou de le faire sur la ligne de commande ds la crontab ...

exemple: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh [email protected]:. >> / var / log / check_connexion.log 2> & 1 ou utilisez la commande "source /home/foo/keychain/foo.server.org-sh" dans le script qui démarre une connexion en utilisant SSH.

=> Avec ce sourcing, plus de soucis. Les informations de SSH_AUTH_SOCK et SSH_AGENT_PID sont chargées dans l'environnement du Crontab et sont donc connues, le RSYNC sur SSH fonctionne sans aucun problème.

Ça m'a occupé mais maintenant ça marche :)

Avertissement pour ceux qui utilisent le transfert d'agent SSH:

Si vous voyez ce comportement lors du débogage d'un script sur un hôte distant, c'est parce que même avec le -e "ssh -i /path/to/key" indicateur, ssh utilisera votre clé locale (transférée) plutôt que celle sur le serveur.

Exemple concret: J'ai un script sur le serveur de développement qui extrait les données du "serveur de données" en utilisant rsync sur ssh. Lorsque je me connecte au serveur de développement et que je l'exécute, tout va bien, mais lors de l'exécution à partir de cron, l'autorisation est refusée. En ajoutant de la verbosité au processus SSH (indicateur -vv), j'ai remarqué ce qui suit:

debug2: key: /home/nighty/.ssh/id_rsa (0x562d8b974820),
debug2: key: /home/juanr/.ssh/id_rsa (0x562d8b962930), explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/nighty/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 1a:19:08:9f:80:16:b1:db:55:42:9a:52:b2:49:9b:0a
debug1: Authentication succeeded (publickey).

Ce qui m'a fait comprendre ici, c'est que par pur hasard, il se trouve que j'ai un nom d'utilisateur différent sur l'hôte local ("nighty") que sur le serveur de développement ("juanr").

Remarquez comment il marque la clé sur le serveur de développement comme "explicite", mais utilise toujours la clé transférée de mon ordinateur portable pour se connecter. Faire un ssh-copy-idà ce stade ne résout rien, car il réinstalle simplement la clé transférée plutôt que celle du développeur serveur. Si vous utilisez ssh-copy-id avec le transfert d'agent, vous devez spécifier la clé à installer avec l'indicateur -i:ssh-copy-id -i ~/.ssh/id_rsa.pub user@host .

Avez-vous déjà essayé l'ancienne astuce de nettoyage des fichiers hôtes? Je veux dire:

rm ~/.ssh/known_hosts

Cela vaut la peine d'essayer car ssh le reconstruira et vous vous débarrasserez des choses périmées. Vous pouvez bien sûr également supprimer les pièces appartenant à un IP / Host donné.

Plus de questions: votre tâche cron s'exécute-t-elle sous votre UID ou s'exécute-t-elle en tant qu'utilisateur cron ou root?

Utilisez le rrsync script avec une clé ssh dédiée comme suit:

Serveur REMOTE

mkdir ~/bin
gunzip /usr/share/doc/rsync/scripts/rrsync.gz -c > ~/bin/rrsync
chmod +x ~/bin/rrsync

Ordinateur LOCAL

ssh-keygen -f ~/.ssh/id_remote_backup -C "Automated remote backup"      #NO passphrase
scp ~/.ssh/id_remote_backup.pub [email protected]:/home/devel/.ssh

Ordinateur distant

cat id_remote_backup.pub >> authorized_keys

Ajoutez à la ligne nouvellement ajoutée ce qui suit

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

Pour que le résultat ressemble

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...vp Automated remote backup

LOCAL

Mettez votre crontabscript suivant avec xpermission:

#!/bin/sh
echo ""
echo ""
echo "CRON:" `date`
set -xv
rsync -e "ssh -i $HOME/.ssh/id_remote_backup" -avzP [email protected]:/ /home/user/servidor 

Source: http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

Pour essayer de déboguer, ajoutez à la partie ssh "ssh -v" de cette façon, vous pouvez obtenir le mode détaillé avec des informations utiles.

Modifier: à partir de la page de manuel:

-v      Verbose mode.  Causes ssh to print debugging messages about its progress.  This is helpful in debugging connection,
             authentication, and configuration problems.  Multiple -v options increase the verbosity.  The maximum is 3.

Je pense que vous n'avez pas configuré correctement le fichier sshd_config. Vérifiez cela PermitRootLogin yeset PubkeyAuthentication yes pour la maintenance à distance.