ubuntuusers.de

Backup-Skript mit rsync aus dem Wiki funktioniert nicht über SSH

Status: Ungelöst | Ubuntu-Version: Ubuntu 22.04 (Jammy Jellyfish)
Antworten |

crazy-to-bike

Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 273

Hallo,

ich teste gerade dieses Skript, um mein Backup mit einer Versionierung zu versehen: https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC/

Lokal funktioniert das Skript super. Ich kann problemlos Ordner in ein lokales Sicherungsverzeichnis sichern.

Allerdings möchte ich - wie bislang mit rsync ohne Versionierung - per ssh auf ein QNAP NAS sichern.

Der "root" heißt bei QNAP "admin".

Ich habe folgendes im Skript konfiguriert:

SOURCES=(/home/mein_benutzername/Backupdateien)
TARGET="/share/mein_benutzername/Testbackup"

# edit or comment with "#"
MONTHROTATE=monthrotate                 # use DD instead of YYMMDD

RSYNCCONF=(--delete)

SSHUSER="admin"
#FROMSSH="fromssh-server"
TOSSH="nas.local"
SSHPORT=22

Der Ordner /share/mein_benutzername/Testbackup existiert auf dem NAS.

Wenn ich das Skript aufrufe, werde ich zur Eingabe des Passwort auf dem NAS gefragt. Das NAS wird also gefunden. Allerdings wird das Passwort nicht akzeptiert (auch mit Copy & Paste zur Vermeidung von Tippefehlern aus dem Passwort-Safe) und die Passwortabfrage kommt erneut. Danach wird das Skript beendet.

Im Log steht dann:

Mi 12. Jul 17:08:44 CEST 2023
/usr/bin/rsync -e "/usr/bin/ssh -p 22 -l admin" -avR "/home/mein_benutzername/Backupdateien" --delete "nas.local:/share/mein_benutzername/Testbackup/2023-07-12_170844" --link-dest=/share/mein_benutzername/Testbackup/letzte_Sicherung 
sending incremental file list
rsync: mkdir "/root/"/share/mein_benutzername/Testbackup/"2023-07-12_170844" failed: No such file or directory (2)
rsync error: error in file IO (code 11) at main.c(875) [Receiver=3.0.7]
rsync: connection unexpectedly closed (185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(231) [sender=3.2.7]
/usr/bin/ssh -p 22 -l admin nas.local /bin/ln -nsf /share/mein_benutzername/Testbackup/2023-07-12_170844 /share/mein_benutzername/Testbackup/letzte_Sicherung
Mi 12. Jul 17:08:59 CEST 2023

Frage 1: Warum wird das Passwort nicht bei der ersten Eingabe akzeptiert? (Bei einem einfachen

ssh -p 22 admin@nas.local

funktioniert das problemlos)

Frage 2: Was macht / sucht das

"/root/"

vor dem korrekten Pfad in der rsync-Zeile?

Ich vermute, das müsste man da weg bekommen.

shiro

Anmeldungsdatum:
20. Juli 2020

Beiträge: 1182

Ich habe kein QNAP-NAS, möchte aber folgende Anmerkungen für dich zum Überdenken geben:

  1. Häufig haben NAS Anbieter den sshd entsprechend modifiziert, d.h. es muss sich "sshd" nicht in allen Features so verhalten, wie du es erwartest.

  2. Eine "ssh" Kommunikation erfolgt normalerweise über SSH-Zertifikate. Dies bedeutet, dass nach Eingabe des PassKey über den ssh-Agent keine Abfrage mehr über den Bildschirm erfolgt. Offenbar hast du kein passendes Zertifikat auf der QNAP-NAS Seite von deinem Account (admin) installiert und wirst daher zur Passworteingabe aufgefordert.

  3. Warum machst du den Backup eigentlich über den User "admin"?

Wenn du kein SSH-Zertifikat auf dem NAS Server ablegen kannst/darfst, kannst du dir zur Not auch mit "sshpass" behelfen. Wenn du es noch nicht bei dir installiert hast, kannst du dies erreichen mittels:

$ sudo apt-get install sshpass

Um zu testen, ob der "sshd" auf dem NAS-Server überhaupt ordentlich funktioniert, würde ich über den folgenden Befehl mal ein "rsync" testen:

$ SSHPASS=Dein-Geheimes_Passwort rsync --rsh='sshpass -e ssh -l admin' -avR --delete /home/mein_benutzername/Backupdateien/ nas.local:/share/mein_benutzername/Testbackup/2023-07-12_170844/

Das setzt natürlich voraus, dass du auf dem Server den Verzeichnisbaum "/share/mein_benutzername/Testbackup/2023-07-12_170844/" bereits angelegt hast.

Andere Frage: Warum mountest du nicht das NAS-Verzeichnis lokal und machst eine stink normale rsync Sicherung?

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 273

Danke für deine Antwort.

shiro schrieb:

1. Häufig haben NAS Anbieter den sshd entsprechend modifiziert, d.h. es muss sich "sshd" nicht in allen Features so verhalten, wie du es erwartest.

Ich mache schon lange rsyncs via ssh auf das NAS. Daher sollte das imho auch mit dem Skript funktionieren.

shiro schrieb:

2. Eine "ssh" Kommunikation erfolgt normalerweise über SSH-Zertifikate. Dies bedeutet, dass nach Eingabe des PassKey über den ssh-Agent keine Abfrage mehr über den Bildschirm erfolgt. Offenbar hast du kein passendes Zertifikat auf der QNAP-NAS Seite von deinem Account (admin) installiert und wirst daher zur Passworteingabe aufgefordert.

Das Abfragen eines Passwortes ist Absicht. Ermögliche ich passwortlosen Zugriff vom Rechner auf das NAS, dann können im Falle eines kompromittierten Rechners auch die Daten auf dem NAS kompromittiert werden. Das führt ein Backup ein Stück weit ad absurdum. Aber in der Tat, könnte ich man schauen, ob man da Key-Authentication einrichten kann. Den Key kann man ja mit oder ohne Passwort erstellen.

shiro schrieb:

2. Warum machst du den Backup eigentlich über den User "admin"?

Weil das der systemweite User bei einem QNAP-NAS ist. root gibt es dort nicht.

shiro schrieb:

Wenn du kein SSH-Zertifikat auf dem NAS Server ablegen kannst/darfst, kannst du dir zur Not auch mit "sshpass" behelfen. Wenn du es noch nicht bei dir installiert hast, kannst du dies erreichen mittels:

$ sudo apt-get install sshpass

Das könnte ich auch testen. Hat aber dasselbe Problem wie ein passwortloser Zugang, wenn das Passwort im Skript hinterlegt ist.

shiro schrieb:

Andere Frage: Warum mountest du nicht das NAS-Verzeichnis lokal und machst eine stink normale rsync Sicherung?

Antwort siehe oben. Alles was lokal gemounted ist, kann bei einer Kompromittierung des Rechners auch befallen werden.

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 273

Also ich hab jetzt ssh-Key-Authentication am NAS eingerichtet und das klappt auch.

Allerdings habe ich keinen Plan, wie ich dem Skript beibringe, statt normaler ssh-Passwort-Authentifikation das Keyfile zu verwenden.

Dasselbe gilt für sshpass. Auch da weiß ich nicht, wie ich das ins Skript einbauen müsste.

shiro

Anmeldungsdatum:
20. Juli 2020

Beiträge: 1182

Alles was lokal gemounted ist, kann bei einer Kompromittierung des Rechners auch befallen werden.

Man muss nicht alles in die "fstab" eintragen und den Befehl "umount" kann man auch benutzen.

Also ich hab jetzt ssh-Key-Authentication am NAS eingerichtet und das klappt auch.

Da es ja klappt (ohne Passwort aber ohne/mit PassPhrase) hast du ja das PUB-Zertifikat im ~/.ssh Verzeichnis lokal korrekt eingetragen. Auf dem Server ist demnach das private Zertifikat auch im dortigen ~/.ssh Verzeichnis vorhanden.

Allerdings habe ich keinen Plan, wie ich dem Skript beibringe, statt normaler ssh-Passwort-Authentifikation das Keyfile zu verwenden.

Wenn du das PUB-Zertifikat korrekt eingetragen hast, wird dieses als "Keyfile" auch verwendet. Du kannst den Dialog des Aushandelns des zu verwendenden Zertifikats ja mittels "ssh -v" dir anschauen. Am Script brauchst du dann nichts zu ändern.

Dasselbe gilt für sshpass. Auch da weiß ich nicht, wie ich das ins Skript einbauen müsste.

Mit "man sshpass" kannst du dir anschauen, wie du die Passwortübergabe gern machen willst. In meinem obigen Beispiel ist für "sshpass -e" die Variable "SSHPASS" vor dem "rsync" Aufruf definiert. Statt den Wert im Klartext einzutragen, kannst du ihn auch per "read" (oder grafischem "yad") abfragen und in dieser Variablen abspeichern.

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 273

shiro schrieb:

Man muss nicht alles in die "fstab" eintragen und den Befehl "umount" kann man auch benutzen.

Stimmt natürlich. Aber man braucht ja ein Protokoll, mit dem gemounted wird, Samba oder CIFS oder was halt unterstützt wird. Ob das dieselbe Performance erreicht wie rsync direkt über ssh, ist zweifelhaft. Samba in jedem Fall schon mal nicht.

shiro schrieb:

Da es ja klappt (ohne Passwort aber ohne/mit PassPhrase) hast du ja das PUB-Zertifikat im ~/.ssh Verzeichnis lokal korrekt eingetragen. Auf dem Server ist demnach das private Zertifikat auch im dortigen ~/.ssh Verzeichnis vorhanden.

Umgekehrt. Das öffentliche Zertifikat liegt auf dem Server.

shiro schrieb:

Wenn du das PUB-Zertifikat korrekt eingetragen hast, wird dieses als "Keyfile" auch verwendet. Du kannst den Dialog des Aushandelns des zu verwendenden Zertifikats ja mittels "ssh -v" dir anschauen. Am Script brauchst du dann nichts zu ändern.

Doch. Denn ich muss dem Skript ja sagen, dass es sich per ssh verbinden soll. Dafür sieht das Skript eigentlich folgende Variablen vor:

SSHUSER="admin"
#FROMSSH="fromssh-server"
TOSSH="nas.local"
SSHPORT=22

shiro schrieb:

Mit "man sshpass" kannst du dir anschauen, wie du die Passwortübergabe gern machen willst. In meinem obigen Beispiel ist für "sshpass -e" die Variable "SSHPASS" vor dem "rsync" Aufruf definiert. Statt den Wert im Klartext einzutragen, kannst du ihn auch per "read" (oder grafischem "yad") abfragen und in dieser Variablen abspeichern.

Ich weiß auch bei sshpass nicht, wie ich dem Skript beibringe, das zu nutzen, da die SSH-Verbindung wie oben zu sehen über Variablen für Benutzername, IP-Adresse und SSH Port programmiert ist.

Würde ich mich mit Shellskriptprogrammierung auskennen, wäre das sicher kein Problem. Ist aber nicht der Fall.

Mich wundert halt, dass das Skript FROMSSH und TOSSH unterstützt, es aber mit dem Füllen der vorgesehenen Variablen nicht funktioniert - siehe Eingangspost.

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 273

Ich habe jetzt das NAS testweise über cifs gemounted. Damit das Skript Daten hinkopieren kann, musste ich aber die Datei- und Ordnerrechte auf 0777 setzen, da weder der lokale User noch der lokale sudo Besitzer des gemounteten Laufwerks ist. Das ist der Admin des NAS, dessen Credentials beim Mounten angegeben werden müssen, um überhaupt mounten zu können.

Weiterhin kann der symbolische Link "letzte_Sicherung" nicht angelegt werden:

/bin/ln: Die symbolische Verknüpfung '/Pfad/zum/gemounteten/Laufwerk/letzte_Sicherung' konnte nicht angelegt werden: Vorgang wird nicht unterstützt

Das verstehe ich nicht, denn wenn ich einfach in der Konsole ein rsync auf das NAS mache, werden symbolische Links aber einwandfrei mitsynchronisiert.

Also so richtig glücklich macht mich das noch nicht.

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 273

Ich glaube ich bin ein erhebliches Stück weiter. Sync auf ein lokal gemountetes Share funktioniert jetzt. Das Share wird bei Skriptaufuf gemounted und nach Beendigung des Syncs am Ende des Skripts wieder unmounted.

Ich muss aber mal mit umfangreicheren Daten testen, ob das alles wirklich tut wie gewünscht.

Wo ich auch noch schauen muss, wie ich mit den VM-Containern von Virtualbox umgehe. Bislang habe ich die beim rsync einfach ausgeschlossen und immer mal wieder händisch an die entsprechende Stelle der Ordnerstruktur (wie auf dem gesyncten Rechner) auf das Backupmedium kopiert. Dadurch, dass sie beim rsync ausgeschlossen sind, blieben sie auch bei erneutem Sync auf dem Backupmedium erhalten.

Ob das mit dem Versionierungsskript irgendwie funktioniert, muss ich testen. Ich befürchte aber, das wird da wegen den Hardlinks nicht so trivial klappen ...

crazy-to-bike

(Themenstarter)
Avatar von crazy-to-bike

Anmeldungsdatum:
11. Oktober 2009

Beiträge: 273

Also zumindest mit einer cifs-Verbindung ist das Skript bei großem Datenbestand unbrauchbar. Dass der erste Sync von rund 380 GB mehrere Stunden gedauert hat, ok. Aber bei nur marginal geänderten Daten läuft das Skript jetzt schon wieder seit 8 Stunden und gefühlt ist bislang weniger im neuen Backupordner als beim initialen Sync.

Mit rsync direkt über ssh dauert der Abgleich bei wenig Änderungen wenige Minuten.

Ich dachte, mit dem Skript kann ich ein versioniertes Backup machen, um versehentlich gelöschtes nicht womöglich auch im Backup komplett zu löschen, aber so ist das unbrauchbar.

Antworten |