rsync vom Laptop auf DS mit SSH

[wired2051]

Auf der DS420 (DSM7) läuft ein rsync Deamon. Meine Clients laufen mit Kubuntu Linux. Das Backup vom PC auf die DS420 läuft im LAN problemlos mit einem Script:

rsync -au --delete /home/ IP_DER_DS420::RSYNC_DAEMON

Das Backup des Thinkpads soll gerne auch ausserhalb des LANs funktionieren. Da ich auf der DS420 den Port für SSH geändert habe, habe ich es so probiert:

rsync -au -e 'ssh -p SSH_PORT' --delete /home/ USER@DOMAIN.TDL::RSYNC_DAEMON

doch es funktioniert nicht, im log steht:

2022/02/01 22:00:02 [15406] rsync: did not see server greeting
2022/02/01 22:00:02 [15406] sent 0 bytes  received 0 bytes  total size 0
2022/02/01 22:00:02 [15406] rsync error: error starting client-server protocol (code 5) at main.c(1814) [sender=3.2.3]

Wenn ich es ohne SSH, also mit rsync -au -e 'ssh -p SSH_PORT' --delete /home/ USER@DOMAIN.TDL::RSYNC_DAEMON probiere, wird's noch schlimmer.

2022/02/01 22:30:01 [15697] rsync: [sender] failed to connect to DOMAIN.TDL (IP_DER_DS420_IM_WAN): No route to host (113)
2022/02/01 22:30:01 [15697] sent 0 bytes  received 0 bytes  total size 0
2022/02/01 22:30:01 [15697] rsync error: error in socket IO (code 10) at clientserver.c(137) [sender=3.2.3]

Was mache ich falsch?

 

[Tommes]

Hi!

Das Backup des Thinkpads soll gerne auch ausserhalb des LANs funktionieren. Da ich auf der DS420 den Port für SSH geändert habe, habe ich es so probiert:

rsync -au -e 'ssh -p SSH_PORT' --delete /home/ USER@DOMAIN.TDL::RSYNC_DAEMON

Versuch es mal so...

rsync -au -e 'ssh -p SSH_PORT' --delete [SOURCES] USER@DOMAIN.TDL:[TARGET]

Hintergrund!
Verwendest du rsync over SSH, dann folgt nach dem USER@DOMAIN.TDL nur ein Doppelpunkt gefolgt vom Datensicherungsziel, wohingegen bei Verwendung von rsync as Daemon zwei Doppelpunkte angegeben werden, gefolgt vom RSYNC_DAEMON.

Des Weiteren läuft rsync over SSH über einen verschlüsselten SSH Tunnel der standardmäßig auf dem TCP Port 22 lauscht, wohingegen rsync as Daemon über einen unverschlüsselten Daemon Service läuft der standardmäßig auf dem TCP Port 873 lauscht.

Du versuchst also grade über eine verschlüsselte SSH-Verbidung (Post 22) einen unverschlüsselten Daemon Dienst (Port 873) zu schicken.

Anmerkung: Es gibt durchaus unterschiedliche Schreibweisen um einen rsync abzusetzen, daher ist das hier nur als Beispiel zu betrachten. Auch kommt es darauf an, ob du ein Push oder Pull Backup machen möchtest. Wichtig ist, das du die Unterschiede zwischen rsync over SSH und rsyn as Daemon kennst und beachtest.

Tommes

 

[wired2051]

Des Weiteren läuft rsync over SSH über einen verschlüsselten SSH Tunnel der standardmäßig auf dem TCP Port 22 lauscht, wohingegen rsync as Daemon über einen unverschlüsselten Daemon Service läuft der standardmäßig auf dem TCP Port 873 lauscht.

Du versuchst also grade über eine verschlüsselte SSH-Verbidung (Post 22) einen unverschlüsselten Daemon Dienst (Port 873) zu schicken.

Dass Daemon und ssh nicht gleichzeitig gehen, wusste ich nicht. Vielen Dank. Ich lass nur Daemon sei schneller. Aber innerhalb meines LAN kann ich wohl auf ssh verzichten.

Anmerkung: Es gibt durchaus unterschiedliche Schreibweisen um einen rsync abzusetzen, daher ist das hier nur als Beispiel zu betrachten. Auch kommt es darauf an, ob du ein Push oder Pull Backup machen möchtest.

Ich habe am Ziel leider ein Leerzeichen im Verzeichnisnamen. Daher habe ich es mit

rsync -au -e 'ssh -p SSH_PORT' --delete /media/Daten/ USER@DOMAIN.TDL:/Backup/ThinkPad\ Daten
rsync -au -e 'ssh -p SSH_PORT' --delete /media/Daten/ USER@DOMAIN.TDL:'Backup/ThinkPad Daten'
rsync -au -e 'ssh -p SSH_PORT' --delete /media/Daten/ USER@DOMAIN.TDL:"/Backup/ThinkPad Daten"

versucht. das Ergebnis ist immer wieder

2022/02/02 23:30:01 [2883] rsync: connection unexpectedly closed (0 bytes received so far) [sender]
2022/02/02 23:30:01 [2883] sent 0 bytes  received 0 bytes  total size 0
2022/02/02 23:30:01 [2883] rsync error: unexplained error (code 255) at io.c(228) [sender=3.2.3]

Was gibt es noch für Schreibweisen?

Ich mache ein Push-Backup vom ThinkPad zur DS420 (Pull-Backups, z. B. mit ABfB, produzieren ja dauernd Warnungen, wenn die Quelle ausgeschaltet ist). Die IP der DS420 ist übrigens mit dem ssh-Port zur Liste der known hosts des ThinkPad hinzugefügt. Und es gibt keine aktive Firewall, weder auf der DS420 noch im Router (Fritzbox).

 

[Tommes]

Der Daemon Service ist schneller, weil hier die SSH Verschlüsselung wegfällt. Das wiederum wirkt sich positiv auf die Prozessorauslastung aus. Auch hat man weniger Probleme mit den Berechtigungen und muss sich ggfl. nicht als root am Remote Server ausgeben. Im LAN ist der Daemon Dienst somit sicherlich eine Option.

Ich mag nur nicht gerne in der /etc/rsyncd.conf rumspielen, schon garnicht, wenn ich das wie bei Basic Backup über eine GUI füttern müsste. Von daher verwende ich persönlich immer rsync over SSH, egal ob LAN oder WAN.

Der Umgang mit Leerzeichen, Tabulatoren und Zeilenumbrüchen ist unter Linux immer die Hölle. Daher setzte ich Strings bzw. Variablen i.d.R. immer in Anführungszeichen. Das hilft zwar nicht immer, oftmals ist das aber von Erfolg gekrönt. Daher würde ich es an deiner Stelle mal so versuchen…

rsync -au -e "ssh -p SSH_PORT" --delete "/media/Daten/" USER@DOMAIN.TDL:"/Backup/ThinkPad Daten"

…oder am Ende auch so…

USER@DOMAIN.TDL:"/Backup/ThinkPad\ Daten"

…schreiben.

… wobei ich dazu sagen muss, das ich hier mit Variablen arbeite, was dann ungefähr so aussieht…

rsync -au -e "ssh -p ${sshport}" --delete "${sources}" USER@DOMAIN.TDL:"${target}"

…wobei ich auch schon "'${target}'" anstatt "${target}" bei einem Push Backup geschrieben habe. Bei Scripten musst du u.a. auch mit dem IFS (internal field separator) arbeiten um Zeilenumbrüche zwischen zwei Wörtern zu verhindern. Du siehst… alles nicht so einfach und oft nur durch das Try and Error Prinzip zu lösen.

Tommes

 

[wired2051]

Ah, Du nutzt natürlich Dein Paket Basic Backup. Das ist für mich leider nichts, weil ein Pull Backup laufend Meldungen produziert, wenn die Quelle aus/offline ist - und ich mag meine Logs sauber.

Ich nutze seit der DS209 ein mit cron gesteuertes rsync Script auf den Quellen und rsync Daemon auf dem NAS. Ich habe nur in Systemsteuerung > Dateidienste > rsync-Dienst aktiviert. Allerdings ist mir gerade aufgefallen, dass hier der SSH-Verschlüsselungsport 22 gesetzt ist. Ich hatte den SSH-Port längst unter Systemsteuerung > Terminal & SNMP > SSH-Dienst geändert, weil der Synology Sicherheitsberater gemurrt hatte.

Warum kann ein SSH-Port an zwei Stellen im DSM unterschiedlich sein? Ist das nicht der gleiche Port?

Wie auch immer, ich habe an beiden Stellen den Port wie im rsync-Aufruf gesetzt und es hat nichts gebracht. Bisher hatte ich auch unter Dateidienste > rsync-Verschlüsselungsdienst > sync-Konto den User Backup eingestellt, doch auch wenn ich ihn lösche und mit einem administtrators-User rsync aufrufe, funktioniert es nicht. Stattdessen motzt nun ABfB (damit versioniere ich die mit rsync erstellten Backups).

Ich glaube, ich gehe wieder zurück zum rsync Daemon, dann funktioniert das Backup zwar nur im LAN aber es funktioniert. Aber schade wär's schon...

 

[Tommes]

Warum kann ein SSH-Port an zwei Stellen im DSM unterschiedlich sein? Ist das nicht der gleiche Port?

Jaaaaaa…. diese Frage habe ich mir auch schon gestellt. Eine fundierte Antwort habe ich darauf jedoch nicht. Wenn es mich packt, werde ich diese Frage mal dem Support stellen.

Das ist für mich leider nichts, weil ein Pull Backup laufend Meldungen produziert, wenn die Quelle aus/offline ist - und ich mag meine Logs sauber.

Naja… Basic Backup prüft zuerst, ob der Remote Server online ist und bricht ggfl. ab, noch bevor rsync überhaupt seine Arbeit aufnimmt. Daher würde im Log nur stehen… Datensicherung fehlgeschlagen. Server offline! Aber das nur am Rande.

Ich würde dir gerne weiter helfen, aber ich bin grade ein wenig ratlos. Da ich mich selber aber schon mit unzähligen Problemen diesbezüglich rumgeschlagen habe, kann ich deinen Frust durchaus nachvollziehen. Oftmals hilft da nur das Try and Error Prinzip weiter, in der Hoffnung so den Fehler einzugrenzen und zu finden. Mir hilft oft, das Problem in mehrere kleine Teile zu zerlegen um nach dem Ausschlussprinzip den Fehler einzugrenzen. In deinem Fall wäre das z.B. das ich erst mal sicher stelle, das die SSH Verbindung einwandfrei arbeitet und ich über die nötigen Berechtigungen am Ziel verfüge. Im Zweifelsfall schalte ich mich erst mal als root auf, damit ich ein Rechteproblem vorerst ausschließen kann. Danach setze ich z.B. einen einfachen rsync ab um zu schauen, ob dieser korrekt abgearbeitet wird und immer so weiter. Dabei versuche ich jeden Befehl mit einem Verbose (-v o.ä.) so gesprächig wie möglich zu bekommen und recherchiere dann jeden Fehler bis dieser gelöst ist. Am Ende bin ich so immer ans Ziel gekommen, auch wenn der Weg dorthin oft sehr steinig war.

Vielleicht motiviert dich das ja ein wenig, es weiter zu probieren. Ich helfe gerne weiter, aktuell bin ich aber auch überfragt. Vielleicht eins noch… der Exit Code 255 aus deinem #3 Beitrag könnte schon mit SSH Zusammenhängen, weil…

Schau dir daher das vielleicht mal an… *klick*

If you're seeing exit code 255 after running rsync, it can mean rsync just passed exit code from a command it used to connect - typically SSH.

Tommes

 

[wired2051]

Jaaaaaa…. diese Frage habe ich mir auch schon gestellt. Eine fundierte Antwort habe ich darauf jedoch nicht. Wenn es mich packt, werde ich diese Frage mal dem Support stellen.

Ich würde es auch tun, wenn Du keine Zeit hast.

Naja… Basic Backup prüft zuerst, ob der Remote Server online ist und bricht ggfl. ab, noch bevor rsync überhaupt seine Arbeit aufnimmt. Daher würde im Log nur stehen… Datensicherung fehlgeschlagen. Server offline! Aber das nur am Rande.

Ich kontrolliere regelmässig meine Logs und müsste dann prüfen, warum der Server offline ist. Klar ist die Wahrscheinlichkeit gross, dass es am fehlenden Strom liegt aber es kann auch sein, dass es etwas ernstes ist. Um solche Missverständnisse auszuschliessen habe ich mich grundsätzlich gegen Pull-Backups entschieden. ABfB entspricht ja ansonsten meinen Ansprüchen an ein Backup (notfalls lesbar ohne spezielle Software) aber es kamen dauernd Fehlermeldungen.

Mir hilft oft, das Problem in mehrere kleine Teile zu zerlegen um nach dem Ausschlussprinzip den Fehler einzugrenzen. In deinem Fall wäre das z.B. das ich erst mal sicher stelle, das die SSH Verbindung einwandfrei arbeitet und ich über die nötigen Berechtigungen am Ziel verfüge.

Der User ist Mitglied in administrators und ssh -p GEÄNDERTER_SSH_PORT ADMIN_USER@IP_DER_DS420 funktioniert in der Konsole.

Danach setze ich z.B. einen einfachen rsync ab um zu schauen, ob dieser korrekt abgearbeitet wird und immer so weiter.

rsync -au --delete /home/ IP_DER_DS420::RSYNC_DAEMON funktioniert im Script.

Dabei versuche ich jeden Befehl mit einem Verbose (-v o.ä.) so gesprächig wie möglich zu bekommen und recherchiere dann jeden Fehler bis dieser gelöst ist.

Ich habe jetzt das Script mit rsync -auvvv gestartet und nur Zeile 4 ist dazu gekommen:

2022/02/04 21:35:01 [2560] rsync: connection unexpectedly closed (0 bytes received so far) [sender]
2022/02/04 21:35:01 [2560] sent 0 bytes  received 0 bytes  total size 0
2022/02/04 21:35:01 [2560] rsync error: unexplained error (code 255) at io.c(228) [sender=3.2.3]
2022/02/04 21:35:01 [2560] [sender] _exit_cleanup(code=12, file=io.c, line=228): about to call exit(255)

code 12 = Error in rsync protocol data stream? Sagt mir nichts.

Was mich wundert: im Script sind 2 rsync-Aufrufe über ssh, einer mit dem Ziel /volume1/Backup und einer mit dem Ziel /Backup. Beide geben aber das Gleiche ins log. Offenbar ist das Problem bevor das Ziel erreicht wird.

Und ich dachte, wenn ssh -p GEÄNDERTER_SSH_PORT ADMIN_USER@IP_DER_DS420 in der Konsole funktioniert, ist ssh nicht das Problem.

Falls Dir noch was einfällt, poste es bitte.

Ansonsten Danke für Deine geduldige Hilfe...

 

[Tommes]

Den Error-Code 12 hatte ich bisher zwar noch nicht, aber eine schnelle Suche im Intermet ergab u.a.sowas hier *klick* Eventuell schaust du selber mal nach dem „rsync exit Code 12“ in einschlägigen Suchmaschinen und schaust, was diesen Fehler noch verursachen kann.

Ich hatte hier auch mal das Problem, das ein Push Backup erst dann korrekt ausgeführt wurde, wenn das Ziel Verzeichnis (Target) bereits existierte. Auch benötigt Basic Backup bei einem Push Backup angepasste Berechtigungen, da es ansonsten Fehlermeldungen hagelt. Suche dazu mal nach dem rsync Optionsschalter --chmod=ugo=rwX falls du mehr darüber erfahren möchtest.

Wie gesagt… oftmals hilft hier nur das Try and Error Prinzip weiter, verbunden mit einer ausgiebigen Recherche zu möglichen Fehlermeldungen, die dir ein Verobse ausspuckt. Manchmal muss man den Fehler selber sehen oder zumindest reproduzieren können, um fundiertere Aussagen treffen zu können. So ist das immer ein stochern im Nebel.

Du darfst gerne den Support anschreiben, wenn du darauf Lust hast. Mich interessiert das zwar auch und Zeit hätte ich sicherlich auch dafür, lasse dir da aber gerne den Vortritt.

Tommes

 

[wired2051]

Du darfst gerne den Support anschreiben, wenn du darauf Lust hast. Mich interessiert das zwar auch und Zeit hätte ich sicherlich auch dafür, lasse dir da aber gerne den Vortritt.

Vielleicht hättest doch besser Du dem Support geschrieben... Jetzt habe ich schon die zweite Antwort (die kamen immer innerhalb von 24h), bin mir aber nicht sicher ob der Support und ich nicht aneinander vorbei reden. Hier deren letzte Antwort von gestern (farbliche Hervorhebung vom Support):

die beiden Ports sind die festgelegten Standard-Ports der unterschiedlichen Dienste.

Port 22 ist SSH (also der Port den ich nutze wenn ich rsync über SSH verwende)

Und Port 873 ist der Standard-Port für den rsync daemon.

Das sind zwei unterschiedliche Arten wie man mit rsync arbeiten kann, die beide ihre eigenen Standard-Ports haben.

Und deswegen kann man diese Ports auch an zwei unterschiedlichen Stellen anpassen:

Systemsteuerung > Terminal & SNMP > SSH-Dienst aktivieren > Port

Systemsteuerung > Dateidienste > rsync-Dienst aktivieren > SSH-Verschlüsselungsport

Wenn meine Aufzeichnungen nicht lügen, ist an beiden Stellen aber die Voreinstellung Port 22 gewesen. Das passt nicht zu deren Erklärung oder irre ich mich?

Port 873 bin ich in DSM7 bisher nur in Active Backup for Business begegnet, wenn man einen Dateiserver mit rsync module-Modus (Daemon?), ohne Verschlüsselung, wählt.

 

[Tommes]

Zuerst einmal danke fürs nachfragen. Ich bin zwar etwas verwirrt, was das hier angeht…

(farbliche Hervorhebung vom Support)

… da ich nicht ganz erkenne, was von dir und was vom Support geschrieben wurde (kann es mir aber denken), dennoch lese ich in der DSM Hilfe u.a. folgendes…

Zitat von hier…

rsync-Sicherungsberechtigungen zuweisen:​

…

1. …
2. …
3. Weisen Sie den gewünschten Benutzern (DSM-Benutzer für verschlüsseltes rsync oder rsync-Konten für unverschlüsseltes rsync) Berechtigungen des Typs Zulassen zu oder oder geben Sie die zugelassenen IP-Adressen für bestimmte Benutzer an.

… was mir suggeriert, das wenn von verschlüsselten rsync geredet wird, eine SSH Verbindung durch einen DSM-Benutzer aufgebaut werden muss, da rsync selber nicht verschlüsselt. Bei unverschlüsselten rsync kommen dann die rsync-Konten ins Spiel die hier dann halt unverschlüsselt über den rsync-Daemon Dienst laufen. Das würde zumindest erklären, warum hier von einem SSH-Verschlüsselungsport die Rede ist und nicht von einem rsync Daemon Port. Den Port für den Daemon kannst du meines Wissens nämlich nur über die /etc/rsyncd.conf einstellen.

Ich hab das auch schon mal irgendwo an anderer Stelle geschrieben, aber Hyper Backup funktioniert auf die gleiche Weise. Dort kannst du je nach Auftrag die rsync Übertagungsverschlüsselung ein- bzw. ausschalten. Bei ausgeschalteter Übertagungsverschlüsselung wird der Port 873 herangezogen, bei eingeschalteter Übertagungsverschlüsselung wird der Port 22 herangezogen. Ist doch komisch, oder?

Tommes

 

[wired2051]

Das ist ein 1:1 Ausschnitt aus der Mail des Supports:



Ich verstehe ja, was der Support meint aber wenn ich mir die Einstellungen ansehe, geht es nicht um die Wahl verschlüsselt / unverschlüsselt (wie bei Active Backup for Business und Hyper Backup) sondern um das ändern der ssh-Port-Nummer - also security by obscurity.

Nur ehrlich gesagt, weiss ich nicht, wie ich das verständlich machen soll.

Ich dachte ja auch schon, dass es um ein Übersetzungsproblem des GUI geht aber dann würde da ja keine freie Portnummer-Eingabe sein, sondern eine Wahl zwischen 22 und 873.

dennoch lese ich in der DSM Hilfe u.a. folgendes… [https://kb.synology.com/de-de/DSM/help/DSM/AdminCenter/file_rsync?version=6]

Systemsteuerung > Berechtigungen kann ich in DSM7 nicht finden...

Unter Systemsteuerung > Anwendungsberechtigungen > rsync habe ich die Berechtigung allen Besitzern gegeben (Vorgabe). Und unter Systemsteuerung > Dateidienste > rsync > rsync-Konto ist Nutzer Backup in Gruppe Backup eingetragen. Hier sehe ich keinen Zusammenhang zum ssh Port.

Was nun? Eigentlich müsste ich weiter mit dem Support diskutieren, nur wie?

 

[Tommes]

Frag doch einfach mal, worin der Unterschied zwischen der Portangabe...

Hauptmenü > Systemsteuerung > Terminal & SNMP > im Reiter [Terminal] > SSH-Dienst aktvieren > Port: 22

... und somit dem Eintrag ssh_port="22" in der /etc/synoinfo.conf sowie...

Hauptmenü > Systemsteuerung > Dateidienste > im Reiter [rsync] > rsync-Dienst aktivieren > SSH-Verschlüsselungsport: 22

und dem Eintrag rsync_sshd_port="22" in der /etc/synoinfo.conf liegt.

Was würde passieren, wenn man den SSH-Verschlüsselungsport (rsync_sshd_port) von 22 z.B. auf 22222 ändert?
Würde dann eine rsync over SSH Verbindung über den TCP Port 22222 verschlüsselt übertragen werden?
Hätte man somit also zwei mögliche SSH-Verbindungen? Einmal über den Port 22 und einmal über den Port 22222?

 

[wired2051]

Ich habe Systemsteuerung > Terminal & SNMP > Terminal > SSH-Dienst aktvieren > Port: 22 in Port 60022 geändert und habe deshalb in /etc/synoinfo.conf ssh_port="62200". Systemsteuerung > Dateidienste > im Reiter [rsync] > rsync-Dienst aktivieren > SSH-Verschlüsselungsport: 22 ist unverändert.

Die Anmeldung auf der DS funktioniert nun mit ssh -p 60022 USER@IP_DER_DS, Gleichzeitig funktioniert rsync -au "ss -p 22" USER@DS.TLD:/ZIEL genauso wenig wie mit "ss -p 60022" - aber das muss natürlich nicht nur am Port liegen (s.o.).

Wie auch immer, ich habe dem Support die Frage gestellt und harre der Antwort.

 

[wired2051]

Gestern kam die Antwort:

wenn Sie den Port an der Stelle Systemsteuerung > Terminal & SNMP > Terminal > SSH-Dienst aktvieren > Port: X, ändern,
dann können Sie die NAS über einen SSH-Client nur über den dort eingestellten Port nutzen.
Sie müssten für den rsync job dann denn entsprechenden Operator -e ssh setzen und den Port, den Sie dort eingesetzt haben.

Wenn Sie an der Stelle Systemsteuerung > Dateidienste > rsync > rsync-Dienst aktivieren > SSH-Verschlüsselungsport: X, den Port ändern,
entscheiden Sie ob der rsyncd über SSH geht (gleicher Port wie bei Systemsteuerung > Terminal & SNMP > Terminal > SSH-Dienst aktvieren > Port: X)
oder einen anderen Port nimmt, der ebenfalls verschlüsselt ist.

Der Port unter Systemsteuerung > Terminal & SNMP > Terminal > SSH-Dienst aktvieren > Port: X ist aber nicht über die normale shell erreichbar sondern
nur für den Rsynd.

Wenn ich das richtig verstanden habe, ist der Port unter Terminal & SNMP für SSH allgemein. Unter Dateidienste > rsync wählt man für den Rsync Daemon entweder den SSH Port (s. Terminal & SNMP) oder einen anderen.

Mich wundert die implizierte Aussage, dass rsyncd immer verschlüsselt sei. Ich nutze seit Jahren für Push-Backups auf das NAS im LAN

rsync -au  LOKALE_QUELLE IP_DES_NAS::ZIEL_MODUL

und das ist doch nicht verschlüsselt?

Ansonsten halte ich unsere Frage für beantwortet oder hast Du Nachfragen?

 

[tproko]

doch nicht verschlüsselt?

rsync verwendet ssh als Protokoll, und SSH baut eine verschlüsselte Verbindung auf. Das meinen sie damit mMn.
Das hat noch nichts damit zu tun, ob das Backup in irgendeiner Form verschlüsselt ist oder nicht.

 

[Tommes]

Aber wenn rsync SSH als Protokoll verwendet, dann würde ich doch erstmal davon ausgehen, das dies über den (Standard-) Port 22 erfolgt. Warum Synology aber einen abweichenden SSH-Verschlüsselungsport zum eigentlichen SSH Port ermöglicht, will nicht in meinen Kopf. Rsync bzw. der rsync Daemon Dienst selber bietet keine Übertragungsverschlüsselung an, weshalb in einem solchen Fall SSH zur Hilfe gezogen wird. Soweit klar. Aber zwei SSH Zugänge mit unterschiedlichen Ports, das ist mir irgendwie zu hoch.

Das einzige, was für mich noch einigermaßen logisch erscheinen würde wäre, das man den unverschlüsselten rsync Daemon durch einen verschlüsselten SSH Tunnel schickt um so einen root-Zugriff per SSH zu umgehen, so wie hier beschrieben…

https://linux-bildung.at/2021/06/backup-mit-rsync/

Das würde aber immer noch nicht den abweichenden SSH-Verschlüsselungsport erklären, da man ja auch eine SSH Verbindung nicht zwangsläufig als root initiieren muss.

Aber wie gesagt… kann auch sein, das ich das einfach nicht verstehen will oder ich einfach zu beschränkt bin, den Sinn dahinter zu verstehen.