web-dev-qa-db-fra.com

Pourquoi ce travail rsync + ssh cron me donne-t-il des erreurs de type 'autorisation refusée (publickey)'?

Je fais souvent des sauvegardes sur un lecteur local que je veux synchroniser quotidiennement sur un serveur distant.

Le serveur cible est configuré pour un accès par clé SSH (sans mot de passe) uniquement. Puisque 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) + un utilisateur à utiliser pour les sauvegardes sans surveillance - de cette manière, je n'ai pas besoin d'être présent. pour entrer ma phrase secrète lorsque cron s'exécute.

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

Le plus éloigné que j'ai 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]

Avez-vous des conseils pour résoudre ce problème?

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

  1. Cron est définitivement en cours d'exécution 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 sur le serveur distant pendant que l'utilisateur de sauvegarde travaille 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é sauvegardes-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. Le remplacement de la commande qui ne fonctionne pas par une simple commande de test fonctionne à echo "Hello world" > ~/Desktop/test.txt

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

Éditer 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/

Éditer 2:

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

De plus, l'utilisateur ne sauvegardait que sur le serveur, avec des droits limités, avec une clé SSH dédiée copiée sur mon ordinateur de bureau. Je suppose que c'est la voie à suivre car tout fonctionne lors de l'exécution manuelle des commandes.

Le fichier crontab posté ci-dessus est pour moi, l'utilisateur 'tom' sur mon ordinateur de bureau. Mon intention est de lui demander d'appeler le script qui doit 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 qu'il contient) et tout s'est bien connecté. Je l'ai exécuté sur mon bureau en tant qu'utilisateur 'tom', 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
permissionssshbackupcronrsync
19
Tom Brossman

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

À partir de commentaire de Jan sur la question d'origine, nous pouvons spécifier le fichier d'identité dans la commande rsync à l'aide de -e 'ssh -i /path/to/identity.file' ....

Utiliser la commande ci-dessous pour démarrer avec un nouvel environnement dans cron et spécifier le chemin complet du fichier résolvent 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 vraiment intéressé par cette découverte. Cela a probablement à voir avec cron, le fait qu’il commence avec des variables d’environnement minimales et ssh-agent. Je mettrai en place le même scénario dans quelques jours pour le tester et en rendre compte.

13
Alaa Ali

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

Impossible de se connecter à RSYNC via SSH, bien qu’il ait spécifié l’identité de SSH ... Rien n’est fait ... Rsync dit "autorisation refusée" et ssh me dit "read_passphrase: impossible d'ouvrir/dev/tty: pas de périphérique ou d'adresse de ce type "

Mais j’ai lu un article expliquant que la crontab a son propre environnement, différent de celui de root. Je le savais déjà mais je ne comprenais pas l'impact que cela pourrait avoir sur SSH avec SSH-AGENT

Mais mes échanges de clés SSH se font avec PassPhrase ... Ainsi, si l'environnement est différent et que 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 = non phrase secrète = non autorisé

Sur ma machine, j'utilise "Keychain" pour lancer l'agent SSH. Je n'ai donc pas à ressaisir la phrase secrète à chaque fois que j'essaie de me connecter à distance. Le trousseau génère un fichier contenant 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 relatives à la session en cours qui permettent des authentifications futures de la session en cours, sans qu'il soit nécessaire de saisir la phrase secrète car elles ont déjà été effectuées et mémorisées ...

==> La solution est là ... il suffit dans le script lancé par la crontab, et de "rechercher" le fichier contenant cette information 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 à l'aide de SSH.

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

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

1
SoniXtrA

Avez-vous déjà essayé le vieux truc du 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 de choses périmées. Vous pouvez bien sûr également supprimer les parties appartenant à une adresse IP/hôte donnée.

Autres questions: Votre travail cron est-il exécuté sous votre UID ou est-il exécuté en tant qu'utilisateur cron ou root?

0
runlevel0

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

Edit: 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.
0
Pedro Luz

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

Serveur distant

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

Ajouter à la ligne nouvellement ajoutée les éléments suivants

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

Alors 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 dans votre crontab le script suivant avec la permission x:

#!/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/

0
Alessandro Cuttin