TrueNAS: rsync über SSH in die Cloud (Backups)

[ShadowDragon]

Hi,

ich versuche aktuell ein Remote-Backup meiner Daten von TrueNAS 12 über rsync (via SSH) in eine Storagebox durchzuführen. Allerdings stoße ich dabei auf einige Probleme....

Zuerst ein paar Begriffserklärungen:

• Host = lokales TrueNAS 12 System
• Remote = Server in der Cloud. Auf diesen habe ich keine interaktive Shell und kein root-Zugriff.

Im Web-interface von TrueNAS bin ich als root eingeloggt. (ich kann mich auch nicht mit anderen Usernames einloggen)

Versuch 1:​

Mein erster Versuch bestand darin, der Dokumentation von TrueNAS zu folgen. Hierzu habe ich auf meinem Storage in der Cloud erstmal SSH-Support aktiviert.

Um via SSH auf Ihre Storage Box zugreifen zu können, aktivieren Sie bitte die Funktion "SSH-Support". Weiterhin ist es möglich mit aktivierter SSH Funktion Rsync und BorgBackup zu nutzen.

Daraufhin habe ich den rsync-Service unter TrueNAS aktiviert. Anschließend habe ich eine SSH-Connection vom Host (TrueNAS) zum Remote eingerichtet. Hierzu bin ich der Anleitung unter "Manuel" gefolgt und habe anschließend den Key hochgeladen:

echo -e "mkdir .ssh \n chmod 700 .ssh \n put storagebox_authorized_keys .ssh/authorized_keys \n chmod 600 .ssh/authorized_keys" | sftp <Benutzername>@<Benutzername>.your-storagebox.de

Wenn ich jetzt den rsync Task erstelle, klappt das ganze allerdings nicht.
Erstmal stellt sich die Frage, welchen "User" ich angeben muss:

Select the user to run the rsync task. The user selected must have permissions to write to the specified directory on the remote host.

Anhand dieser Beschreibung in TrueNAS könnte man meinen, man muss den User, welchen auf dem Server in der Cloud existiert auch lokal anlegen, allerdings ist es anscheinend auch möglich hier einen beliebigen User anzugeben und unter "Remote Host" username@ vor die IP-Adresse zu setzen. Am Ende spielt es keine Rolle, der Fehler (weiter unten) tritt unabhängig vom gewählten User auf.

Unter Rsync Mode habe ich SSH ausgewählt und den Port auf 23 gestellt (da dies der rsync port auf dem Remote Host ist). Direction wurde Push ausgewählt und anschließend ein Ordner und Schedule festgelegt. Bestätigt man nun mit "Submit" erhält man folgende 2 Fehlermeldungen:

In order to use rsync over SSH you need a user with a private key (DSA/ECDSA/RSA) set up in home dir.

Disconnect Error[ error code 14 ] was generated when trying to communicate with remote host XYZ.com and remote user xyz.

Versuch 1.1​

Mein nächster Versuch bestand darin, einen Home-Ordner anzulegen und den Public Key, welcher generiert wurde, in das Feld "SSH Public-Key" des jeweiligen Nutzers im Host einzufügen. Das Ergebnis sind die selben 2 Fehler wie in Versuch 1. :/

Research:​

Also habe ich mal nachgeschaut was genau die Option "SSH Public-Key" des jeweiligen Nutzers eigentlich bewirkt. Anscheinend passiert hier nichts außer, dass eine Datei Names "authorized_keys" im ssh Ordner des Nutzers angelegt wird. Dies hilft mir natürlich nicht weiter.
Der nächste Schritt bestand darin, nachzuschauen wo überhaupt der Key gespeichert wurde, welchen das Webinterface erstellt hat. Leider blieb die Suche hier erfolgslos. Ich kann ausschließen dass es im ssh-Ordner vom Root-User ist sowie in den ssh Ordnern der einzelnen Nutzer. Mehr kann ich aber nicht dazu sagen.
Zeitgleich stellt sich mir nun die Frage, wieso am Ende dieses Keys das Wort root vermerkt ist.Dies impliziert, dass der Key für den root-User angelegt wurde. Wieso taucht dieser dann nicht im SSH Ordner diesen auf? Wieso klappt dann eine Verbindung selbst mit root als User und username@ vor die IP-Adresse nicht?
Viele Fragen und keine Antworten. -_-

Versuch 2, der manuelle Weg:​

Nachdem ich bei Versuch 1 keine Ideen hatte was ich sonst noch versuchen kann, habe ich mich dazu entschieden einen neuen Versuch zu starten. Hierfür habe ich einen lokalen Nutzer, dessen Username nicht mit dem des Remote's übereinstimmt.

1. den SSH und rsync Service auf TrueNAS aktivieren.
2. In der Shell vom Webinterface su username eingeben.
3. Daraufhin ssh-keygen eingeben um die Keys zu generieren. Diese im Home Verzeichnis speichern. Vielleicht ein wichtiges Detail, aber ich habe kein Passwort für diese festgelegt.
4. Anschließend habe ich den Public-Key über eine SSH Verbindung kopiert und in das Feld "SSH Public-Key" des jeweiligen Nutzers eingefügt.
5. Zudem habe ich den Public-Key auf den Remote-Server hinterlegt.
6. SSH deaktiviert.
7. den rsync Task habe ich nun mit dem lokalen Nutzer und remoteuser@remote-host angelegt.

Das Ergebnis: Eine Fehlermeldung
Der "Remote Path" konnte nicht verifiziert werden, die Verbindung hat aber geklappt. :O
Also habe ich den Hacken bei der Verifizerung rausgenommen und gespeichert.

No ECDSA host key is known for [username.your-storagebox.de]:23 and you have requested strict checking.
Host key verification failed.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.3]

Das Ergebnis des ganzen war dann aber eher ernüchternd. Immerhin bin ich weiter gekommen als bei Versuch 1, welcher komplett auf das Webinterface gesetzt hat.

Ein kleiner Hinweis am Rande: Die Keys welche ich in der Shell erstellt habe tauchen nicht im Webinterface auf. Wenn ich diese dort manuell einfüge, wird die Fehlermeldung nicht behoben. Erstelle ich über das Webinterface eine Verbindung zum Server mit dem "Remote Host Key", so bleibt das Problem weiterhin bestehen.


Hat hier vielleicht jemand eine Idee was ich noch versuchen kann, damit die rsync-Verbindung für mein Remote-Backup klappt?


EDIT: Mit rclone hat es am Ende funktioniert. Ich weiß nicht so recht was das Problem bei rsync war, aber über rclone ging es dann. Vorausgesetzt man gibt die Ordner ab dem Homeverzeichnis an, also backup/ statt /home/backup

 

[brubbelmichi]

https://thomas-leister.de/restic-hetzner-storagebox/

Bin mir gerade nicht sicher, wie weit du gekommen bist. Hast du den Public Key in die Datei authorized_keys auf der Storage Box kopiert?

 

[madmax2010]

anlegen der keys auf der storagebox:

USER=u291234-sub5 (durch korreten user/subaccount tauschen
ssh-keygen -e -f  ~/.ssh/id_rsa.pub | grep -v "Comment:" >  ~/.ssh/id_rsa_rfc.pub
cat  ~/.ssh/id_rsa.pub >> storagebox_authorized_keys
cat  ~/.ssh/id_rsa_rfc.pub >> storagebox_authorized_keys
pwd

echo -e "mkdir .ssh \n chmod 700 .ssh \n put storagebox_authorized_keys .ssh/authorized_keys \n chmod 600 .ssh/authorized_keys" | sftp $USER@$USER.your-storagebox.de

rsync -rPu  -e 'ssh -p23'   LOCAL_FILE $USER@$USER.your-storagebox.de:/path/to/target

wenn du mit key forewarding arbeitest, nimm den pubkey mit dem du dich auch am server angemeldet hast.

SSH und ggf externe erreichbarkeit sollten auf der SB aktiv sein.

 

[ShadowDragon]

https://thomas-leister.de/restic-hetzner-storagebox/

Bin mir gerade nicht sicher, wie weit du gekommen bist. Hast du den Public Key in die Datei authorized_keys auf der Storage Box kopiert?

anlegen der keys auf der storagebox:

USER=u291234-sub5 (durch korreten user/subaccount tauschen
ssh-keygen -e -f  ~/.ssh/id_rsa.pub | grep -v "Comment:" >  ~/.ssh/id_rsa_rfc.pub
cat  ~/.ssh/id_rsa.pub >> storagebox_authorized_keys
cat  ~/.ssh/id_rsa_rfc.pub >> storagebox_authorized_keys
pwd

echo -e "mkdir .ssh \n chmod 700 .ssh \n put storagebox_authorized_keys .ssh/authorized_keys \n chmod 600 .ssh/authorized_keys" | sftp $USER@$USER.your-storagebox.de

rsync -rPu  -e 'ssh -p23'   LOCAL_FILE $USER@$USER.your-storagebox.de:/path/to/target

wenn du mit key forewarding arbeitest, nimm den pubkey mit dem du dich auch am server angemeldet hast.

SSH und ggf externe erreichbarkeit sollten auf der SB aktiv sein.

Der Public Key liegt bereits in der "authorized_keys" Datei. Versuch 2 beschreibt wie weit ich gekommen bin.

SSH und exteren Erreichbarkeit sind enabled. Dies weiß ich, weil ich via sftp vom lokalen PC erfolgreich auf die SB komme. Nur in TrueNAS klappt das nicht mit dem rsync Task.



EDIT: Mit rclone hat es am Ende funktioniert. Ich weiß nicht so recht was das Problem bei rsync war, aber über rclone ging es dann. Vorausgesetzt man gibt die Ordner ab dem Homeverzeichnis an, also backup/ statt /home/backup