Warum erhalte ich bei diesem rsync + ssh-Cronjob die Fehlermeldung „Zugriff verweigert (öffentlicher Schlüssel)“?

Question

Ich erstelle regelmäßig Backups auf einem lokalen Laufwerk, das ich täglich mit einem Remote-Server synchronisieren möchte.

Der Zielserver ist nur für den Zugriff per SSH-Schlüssel (kein Passwort) konfiguriert. Da mein primärer SSH-Schlüssel für diesen Server passwortgeschützt ist, habe icheinen zweiten SSH-Schlüssel (nicht passwortgeschützt) + Benutzer für unbeaufsichtigte Backups erstellt– auf diese Weise muss ich nicht anwesend sein, um meine Passphrase einzugeben, wenn Cron ausgeführt wird.

Ich verwende cron und rsync, und alle Befehle funktionieren einzeln, schlagen aber fehl, wenn sie kombiniert werden.

Das weiteste, was ich bei der Fehlerbehebung erreicht habe, ist

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

was den Fehler zurückgibt

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]

Gibt es Tipps zur weiteren Fehlerbehebung?

---

Folgendes habe ich bisher versucht, aber mir fallen keine Ideen mehr ein:

1. Cron läuft definitivps aux | grep cron

2. Nichts Ungewöhnliches in /var/log/syslogSep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

3. SSH im Terminal zum Remote-Server, da der Backup-Benutzer arbeitetssh [email protected]

4. Das Ausführen des Befehls im Terminal funktioniert einwandfreirsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

5. Die manuelle Angabe des Pfads zum Backups-Benutzerschlüssel hat keine Auswirkungrsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

6. Das Ersetzen des nicht funktionierenden Befehls durch einen einfachen Testbefehl funktioniertecho "Hello world" > ~/Desktop/test.txt

7. Den Computer anzuschreien/zu fluchen hatte keine Wirkung (aber mir ging es vorübergehend besser).

---

Bearbeitung 1:

Hier ist meine Crontab-Datei und das Skript, das sie aufruft.

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

Und

#!/bin/bash

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

---

Bearbeitung 2:

Nur zur Klarstellung: /var/log/auth.logAuf dem Zielserver befindet sich die Zeile Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootDies ist verwirrend, da ich Cron nicht mehr jede Minute lokal ausführe, aber in den Serverprotokollen erscheint immer noch jede Minute ein neuer Eintrag. Crontab-Dateien füralleBenutzer (einschließlich Root) auf dem Server sind leer und tun nichts.

Außerdem wurde der Benutzer „backups-only“ nur auf dem Server und mit eingeschränkten Rechten erstellt, wobei ein dedizierter SSH-Schlüssel auf meinen Desktop-Computer kopiert wurde. Ich gehe davon aus, dass dies der richtige Weg ist, da beim manuellen Ausführen der Befehle alles funktioniert.

Die oben gepostete Crontab-Datei ist für mich, Benutzer „tom“ auf meinem Desktop-Rechner. Ich möchte, dass sie das Skript aufruft, das sich als Benutzer „backups-only“ beim Server anmelden soll. Ich habe gerade versucht, das Backup-Skript auszuführen (anstatt des darin enthaltenen Befehls), und es hat erfolgreich eine Verbindung hergestellt und funktioniert. Ich habe es auf meinem Desktop als Benutzer „tom“ ausgeführt, derselbe Benutzer, der den Cron-Job erstellt hat, der nicht funktioniert. Hier ist die Ausgabe aus dem Serverprotokoll, die dieser erfolgreichen Anmeldung entspricht.

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

Answer 1

Da über die Befehlszeile alles einwandfrei funktioniert, Permission denied (publickey)bedeutet der Fehler, dass der SSH-Teil rsynceine andere Identitätsdatei als der angegebene Benutzername verwendet.

AusKommentar von JanZur ursprünglichen Frage: Wir können die Identitätsdatei im rsyncBefehl mit angeben -e 'ssh -i /path/to/identity.file' ....

Das Starten einer neuen Umgebung in Cron mit dem folgenden Befehl und die Angabe des vollständigen Pfads zur Datei löst das Problem anscheinend:

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/"

_{Ich bin immer noch sehr an diesem Ergebnis interessiert. Es hat wahrscheinlich mit Cron zu tun, der Tatsache, dass es mit minimalen Umgebungsvariablen startet, und dem SSH-Agenten. Ich werde in ein paar Tagen dasselbe Szenario einrichten, um es zu testen und darüber zu berichten.}

Answer 2

Ich habe gerade dieses Problem gelöst, das mich beschäftigt hat.

Keine Verbindung in RSYNC über SSH möglich, obwohl die Identität für SSH festgelegt wurde ... Es wird nichts unternommen ... Rsync sagt „Zugriff verweigert“ und SSH sagt mir „read_passphrase: kann /dev/tty nicht öffnen: Kein Gerät oder Adresse dieses Typs“

Aber ich habe einen Beitrag gelesen, in dem erklärt wurde, dass die Crontab eine eigene Umgebung hat, die nicht mit der von Root identisch ist. Das wusste ich bereits, aber ich verstand nicht, welche Auswirkungen dies auf SSH haben könnte, wenn der SSH-AGENT verwendet wird.

Aber mein SSH-Schlüsselaustausch erfolgt mit PassPhrase ... wenn also die Umgebung anders ist und mein RSYNC über SSH eine Passphrase erwartet, die nicht eingegeben werden kann => SSH-Debug-Info zeigt auch den Fehler an:

"debug1: read_passphrase: kann /dev/tty nicht öffnen: Kein solches Gerät oder keine solche Adresse" => Also ja, kein TTY = keine Passphrase = nicht erlaubt

Auf meinem Rechner verwende ich "Keychain", um den SSH-Agenten zu starten, damit ich die Passphrase nicht bei jedem Versuch einer Remote-Verbindung erneut eingeben muss. Keychain generiert eine Datei, die die folgenden Informationen enthält

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

==> Der Befehl SSH-AGENT gibt dieselben Informationen zurück.

Letztendlich sind es also diese Informationen zur aktuellen Sitzung, die zukünftige Authentifizierungen der aktuellen Sitzung ermöglichen, ohne dass die Passphrase eingegeben werden muss, weil dies bereits zuvor erledigt und gespeichert wurde …

==> Die Lösung ist da ...es reicht aus, im von der Crontab gestarteten Skript die Datei mit diesen Informationen als „Quelle“ zu verwenden oder dies über die Befehlszeile der Crontab zu tun …

Beispiel: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh[email geschützt]:. >> /var/log/check_connexion.log 2>&1 oder verwenden Sie den Befehl „source /home/foo/keychain/foo.server.org-sh“ im Skript, das eine Verbindung per SSH startet.

=> Mit diesem Sourcing gibt es keine Sorgen mehr. Die Informationen von SSH_AUTH_SOCK und SSH_AGENT_PID werden in die Umgebung der Crontab geladen und sind daher bekannt, das RSYNC über SSH funktioniert problemlos.

Es hat mich beschäftigt, aber jetzt funktioniert es :)

Answer 3

Vorbehalt für diejenigen, die SSH Agent Forwarding verwenden:

Wenn Sie dieses Verhalten beim Debuggen eines Skripts auf einem Remote-Host feststellen, liegt dies daran, dass -e "ssh -i /path/to/key"SSH auch mit diesem Flag Ihren lokalen (weitergeleiteten) Schlüssel und nicht den auf dem Server verwendeten Schlüssel verwendet.

Konkretes Beispiel: Ich habe ein Skript auf dem Entwicklungsserver, das Daten vom „Datenserver“ über rsync über ssh abruft. Wenn ich mich beim Entwicklungsserver anmelde und es ausführe, ist alles in Ordnung, aber wenn ich es von cron aus ausführe, wird mir die Berechtigung verweigert. Als ich dem SSH-Prozess etwas mehr Ausführlichkeit hinzufügte (Flag -vv), bemerkte ich Folgendes:

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).

Was mich hier aufgefallen ist, ist, dass ich durch reinen Zufall auf dem lokalen Host („nighty“) einen anderen Benutzernamen habe als auf dem Dev-Server („juanr“).

Beachten Sie, dass der Schlüssel auf dem Dev-Server als „explizit“ markiert wird, aber dennoch der weitergeleitete Schlüssel von meinem Laptop zum Anmelden verwendet wird. Wenn Sie ssh-copy-idan dieser Stelle einen ausführen, wird nichts behoben, da einfach der weitergeleitete Schlüssel neu installiert wird und nicht der vom Dev-Server. Wenn Sie ssh-copy-id mit Agent-Weiterleitung verwenden, müssen Sie mit dem Flag -i angeben, welcher Schlüssel installiert werden soll: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

Answer 4

Hast du schon den alten Trick mit dem Bereinigen der Hosts-Dateien ausprobiert? Ich meine:

rm ~/.ssh/known_hosts

Es lohnt sich, es zu versuchen, da SSH es neu aufbaut und Sie veraltete Inhalte loswerden. Sie können natürlich auch die Teile entfernen, die zu einer bestimmten IP / einem bestimmten Host gehören.

Weitere Fragen: Läuft Ihr Cron-Job unter Ihrer UID oder als Benutzer „Cron“ oder „Root“?