Backup-Probleme nach Update auf Version 24.0

[Henning]

Guten Morgen zusammen,

auch bei mir gab es erneut einen Fehler. Da mein bisheriger Anbieter für Backup nur diese Übertragung anbietet und mir keine weitere Wahl lässt, werde ich die Zusammenarbeit dort beenden und mir morgen eine KeyDisc zulegen. Für mich ist es keine Option, an einem Produktivsystem herumzubasteln.

[Grauer]

Warum stellst Du dann nicht einfach auf SFTP um? Das sollte doch mit eigentlich jedem Backup Ziel arbeiten.

Edit: bzw. aendere einfach Deine bestehenden Repositories auf SFTP und gut ist.

Weil der Backupserver nur via FTP(S) erreichbar ist. Als alternative könnte ein Zugang via CIFS oder NFS erfolgen, aber mit dem kenne ich mich nicht aus und SFTP steht leider nicht zu Verfügung.

[Alexander]

Gibt es Aussichten dass dieses Problem behoben wird. Ich weis nicht inwiefern KeyHelp da etwas machen kann oder ob es ein Update von Restic und Rclone benötigt.

Auf die Funktionsweise von Restic und Rclone habe ich leider keinen Einfluss. In der Regel gibt es regelmäßige Updates von Restic/Rclone. Die können in der Regel auch außerhalb von KeyHelp Updates eingespielt werden.
(restic self-update & rclone selfupdate)

Aktuell gibt es zum Beispiel ein Update für Restic auf Version 0.16.4. KeyHelp 24.0 kommt mit Restic 0.16.3. Laut Changelog sollte es allerdings keine Auswirkungen auf die Funktionalität innerhalb KeyHelp haben. Zumal ich die Ursache auch nicht bei Restic, sondern eher bei Rclone (für Datenübertragung zuständig) suchen würde.

Ich habe in der Vergangenheit immer mal wieder Fehlerberichte bei Rclone eingereicht, die dann daraufhin gefixt wurden. Hierbei war immer FTP in Kombination mit TLS das Problem. Damals konnte ich das Ganze mit speziellen Test-Fällen noch reproduzieren.
Als ich gestern versuchte, den hier gemeldeten Fehler zu reproduzieren, gelang es mir jedoch nicht (Getestet von einem Debian 12 auf ein Ubuntu 22 System mit FTP Server-Version "proftpd 1.3.7c") Was mich zum nächsten Punkt bringt.
Was auch eine eine Ursache für den FTP Fehler sein könnte: Alte FTP-Server Versionen auf den Zielsystemen. Solche Fälle gab es in der Vergangenheit auch schon. Das ist natürlich etwas, das nur der Hostinganbieter beantworten/beurteilen/beheben kann.
Z.B. den Fehler den Blickgerecht auf Seite 1 gepostet hat lässt darauf schließen, das der FTP Server ein Feature nicht beherrscht.

[Grauer]

Danke für die Ausführliche Antwort. Das mit "alten FTP Server" könnte durchaus zutreffen. Ich werde mich mal beim Anbieter erkundigen.

[blickgerecht]

Wie versprochen, noch einmal Feedback nach einigen Tagen von uns: Seit der Umstellung auf SFTP läuft das bei uns auch einwandfrei durch.

[JensE]

Auch ich habe bei nahezu allen meinen Server den selben Fehler, dass das Backup durchläuft und dann beim Bereinigen abbricht. Auf allen Servern läuft Keyhelp in der aktuellsten Version auf Debian 12.
Bei Debian 12 läuft ProFTPD in Version 1.3.8
Das Problem tritt nur mit FTPS-Verbindungen auf.

Ich habe auf dem FTP-Server folgende Fehler entdeckt, die mit der Thematik zu tun haben:
im Log /var/log/proftpd/proftpd.log findet sich folgende Meldung:

Code: Select all

mod_tls/2.9.2: unexpected OpenSSL error, disconnecting

Das spiegelt sich auch im tls-log wider: (/var/log/proftpd/tls.log)

Code: Select all

2024-04-19 16:10:42,193 mod_tls/2.9.2[155667]: TLS/TLS-C requested, starting TLS handshake
2024-04-19 16:10:42,220 mod_tls/2.9.2[155667]: TLSv1.3 connection accepted, using cipher TLS_AES_256_GCM_SHA384 (256 bits)
2024-04-19 16:10:42,344 mod_tls/2.9.2[155665]: Protection set to Private
2024-04-19 16:10:42,358 mod_tls/2.9.2[155665]: TLSv1.3 data connection accepted, using cipher TLS_AES_256_GCM_SHA384 (256 bits, resumed session)
2024-04-19 16:10:42,898 mod_tls/2.9.2[155419]: panic: SSL_ERROR_SYSCALL, line 11104: system error: Datenübergabe unterbrochen (broken pipe)
2024-04-19 16:10:42,898 mod_tls/2.9.2[155419]: unexpected OpenSSL error, disconnecting

Auf Seiten Keyhelps, das auf dem zu sichernden Server läuft gibt es dann die Fehlermeldung:

Code: Select all

Failed to prune repository: Remove(<lock/fda1fe071c>) returned error, retrying after 1.004040118s: blob not removed, server response: 500 Internal Server Error (500)
rclone: 2024/04/19 16:00:43 ERROR : locks/

Ich habe ProFTPD so konfiguriert, dass er nur TLS 1.3 akzeptiert.
Wenn ich die Meldungen so lese, vermute ich dass es an ProFTPD liegt. Besser gesagt am Modul mod_tls von ProFTPD
Demnach dürften FTP-Verbindungen das Problem nicht haben. Ich will das aber jetzt nicht ausprobieren, meine Daten unverschlüsselt durch Netz zu jagen....

Könnte es sein, dass es an TLS 1.3 liegt? oder am Cipher?
Ich habe das auch mit TLS 1.2 getestet: Gleicher Fehler...

Code: Select all

2024-04-19 17:18:19,178 mod_tls/2.9.2[167555]: TLSv1.2 data connection accepted, using cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)
2024-04-19 17:18:22,180 mod_tls/2.9.2[167552]: panic: SSL_ERROR_SYSCALL, line 11104: system error: Datenübergabe unterbrochen (broken pipe)
2024-04-19 17:18:22,180 mod_tls/2.9.2[167552]: unexpected OpenSSL error, disconnecting

Liegt es am Zusammenspiel von ProFTPD und openSSL?
Hat jemand eine Idee, wie man den OpenSSL-Fehler beheben kann?

[24unix]

Hat jemand eine Idee, wie man den OpenSSL-Fehler beheben kann?

FTP war Schrott und ist Schrott auch mit angeschraubter Verschlüsselung (FTPS). SFTP läuft ohne Probleme.

[Tobi]

Du kannst problemlos auf unverschlüsseltens FTP umstellen, da das Backup selbst schon verschlüsselt ist.

[JensE]

FTP war Schrott und ist Schrott auch mit angeschraubter Verschlüsselung (FTPS). SFTP läuft ohne Probleme.

Da gebe ich dir recht. Ich vermeide FTPS eigentlich so gut ich kann...
Ich wollte nur, dass jeder Server beim Backup nur sein Verzeichnis auf dem Backup-Server sehen kann und nicht die Ordner der anderen Server. Bei SFTP hat der User in KeyHelp ja Zugriff auf den ganzen Server... (Außer in KeyHelp Pro mit chroot)

Du kannst problemlos auf unverschlüsseltens FTP umstellen, da das Backup selbst schon verschlüsselt ist.

Danke für den Hinweis. Dann teste ich das doch mal mit FTP only...

[24unix]

Da gebe ich dir recht. Ich vermeide FTPS eigentlich so gut ich kann...
Ich wollte nur, dass jeder Server beim Backup nur sein Verzeichnis auf dem Backup-Server sehen kann und nicht die Ordner der anderen Server. Bei SFTP hat der User in KeyHelp ja Zugriff auf den ganzen Server... (Außer in KeyHelp Pro mit chroot)

Ach, das Target ist auch KeyHelp?

ProFTPd kann auch SFTP, aber ich weiß nicht, ob man das unterKeyHelp anflanschen kann. Nutze kein FTP.

[JensE]

Ja, beide Systeme laufen mit KeyHelp. Der zu sichernde Server und der Backup-Server...
Ich habe das jetzt mit FTP only getestet, und da lief alles problemlos durch. Das ist aber nicht was ich will.
Aber ich habe jetzt eine Lösung mit SFTP gefunden, die mir besser gefällt.

Ziel:
Jeder zu sichernde Server soll auf dem Backup-Server nichts von den anderen Servern sehen können und das soll über SFTP mit SSH-Keys laufen (nicht mit Passwort).

Vorgehensweise:
Dazu benötigt man auf dem Backup-Server für die zu sichernden Server eine SSH-Umbebung mit chroot.
Für jeden zu sichernden Server wird dazu auf dem Backup-Server in KeyHelp ein eigener Kunde angelegt.
Dieser Kunde hat nur folgende Berechtigungen:
Speicherplatz und Traffic unbegrenzt, Zugriff auf SSH, Datei-Manager und Control-Panel

Ab jetzt geht es in der Konsole des Backup-Servers weiter und wir müssen uns dort als root anmelden.
Um den Kunden-Account des zu sichernden Servers in einer chroot-Umgebung einzusperren, genügt es diesen Account der Gruppe keyhelp_chroot hinzuzufügen:

Code: Select all

usermod -aG keyhelp_chroot USERNAME

Zur Info: Um den Kunden-Account wieder aus dieser Gruppe zu entfernen, kann man folgenden Befehl verwenden...

Code: Select all

gpasswd -d USERNAME keyhelp_chroot

Damit haben wir für den zu sichernden Server schon mal die SSH-chroot-Umgebung, aus der er nicht ausbrechen kann. Dieser Account hat keinen Zugriff auf die Konsole, aber man kann den Zugang verwenden um das Backup über SFTP auf dem Backup-Server zu speichern.

Nun bereiten wir alles vor, um den öffentlichen Schlüssel, den wir auf dem zu sichernden Server erstellen werden auf dem Backup-Server zu hinterlegen. Dazu brauchen wir die Datei ~/.ssh/authorized_keys mit dem richtigen Besitzer und Rechten...

Datei anlegen:

Code: Select all

> /home/users/USERNAME/.ssh/authorized_keys

Den Besitzer korrigieren, da diese Datei aktuell root gehört:

Code: Select all

chown USERNAME:USERNAME /home/users/USERNAME/.ssh/authorized_keys

und nun noch die richtigen Rechte: (nur der Kunde selbst darf Zugriff auf diese Datei haben...)

Code: Select all

chmod 700 /home/users/USERNAME/.ssh/authorized_keys

Wir legen noch ein Verzeichnis an, in dem wir das Backup speichern wollen z.B. im Home-Ordner/files/ des Kundenaccounts mit dem richtigen Besitzer:

Code: Select all

mkdir /home/users/USERNAME/files/backup
chown USERNAME:USERNAME /home/users/USERNAME/files/backup

Jetzt müssen wir nur noch den öffentlichen Schlüssel auf dem zu sichernden Server generieren und im Backup-Server hinterlegen:
Dazu melden wir uns beim zu sichernden Server in KeyHelp an und legen ein neues Repository für das Backup an.
Dort wählen wir SFTP aus und als Authentifizierungsmethode "Öffentlicher / Privater Schlüssel", den wir dort mit einem Klick generieren und kopieren können.
Das Repository aber noch nicht speichern. Wir müssen den öffentlichen Schlüssel erst auf dem Backup-Server hinterlegen.
Dazu gehen wir wieder in die Konsole des Backup-Servers und öffnen die vorher angelegte Datei authorized_keys und kopieren dort den öffentlichen Schlüssel hinein:

Code: Select all

vim /home/users/USERNAME/.ssh/authorized_keys

Jetzt können wir auf dem zu sichernden Server das Repository speichern und wenn alles geklappt hat, sollte das Repository angelegt worden sein.
Nun legen wir noch einen regelmäßigen Backup-Plan an und das Backup läuft...

Das war jetzt eine Menge Text, aber wem dieses Vorgehen gefällt, kann das übernehmen.

LG Jens

[24unix]

Top! Gefällt mir, gut beschrieben.

Code: Select all

vim /home/users/USERNAME/.ssh/authorized_keys

Yes Es gibt auch noch Lösungen ohne nano