Hallo zusammen,
ich habe vor einiger Zeit ein hidrive als externes backup Ziel eingebunden. Grundsätzlich funktioniert das auch aber hyperbackup dorthin auch. Das hidrive Laufwerk wird via ssh eingebunden und Sicherungen werden geschrieben.
Jetzt habe ich mir das noch mla in punkto Sicherheit angeschaut und wollte eigentlich auf ssh key wechseln (u.a. um MFA für den Backup User aktivieren zu können), aber das hat bei mir nicht geklappt. Zwar kann ich per konsole ohne passwort mit dem hidrive ssh Server verbinden, aber hyperbackup akzeptiert das Set-Up nicht ohne Angabe eines Passworts. Dazu habe ich auch im synology Forum einen Bericht gefunden: https://community.synology.com/enu/forum/1/post/188372
Daher meine erste Frage: weiß jemand ob und wie man hyperbackup mit ssh-key unter aktuellem DSM ans Laufen bekommen kann?
Da ich das jedenfalls erst mal nicht hinbekommen habe, wollte ich für den User ein langes Passwort verwenden. Ich habe eines mit den bei hidriv maximal möglichen 128 Zeichen verwendet. Allerdings verbindet sich hyperbackup dann nicht mehr. Ich habe lange nach einem möglichen Fehler gesucht, auch rsync als Backup Ziel ausprobiert und die Serverdaten von hidrive manuell eingegeben. Es ging dann erst als ich das Passwort auf ca. 40 Zeichen verkürzt hatte. ... Ich habe auch passphrases ohne besondere Sonderzeichen probiert, das scheint keinen unterschied zu machen.
Meine zweite Frage: kennt jemand dazu Hintergünde oder noch besser möglichkeiten DSM zu überreden ein langes Passwort zu akzeptieren?
Ich überlege jetzt als Alternative einen Rapserry PI, der hier eh werkelt als eine art "Bridge" zu verwenden, der einerseits die Verbindung zum RSYNC auf hidrive aufmacht, mit SSH Key abgesichert und intern einen RSYNC mit einem passenen Passwort oder das als Laufwerk bereitstellt ... ist aber irgendwie ein merkwürdiger Workarround. Ich habe auch noch keine Ahnung, wie ich den Rasperry dazu bringe, den Traffic an rsync weiterzureichen, da müsste ich vermutlich etwas rumbasteln, meine Skriptfähikeiten sind leider etwas eingerostet.
ich habe vor einiger Zeit ein hidrive als externes backup Ziel eingebunden. Grundsätzlich funktioniert das auch aber hyperbackup dorthin auch. Das hidrive Laufwerk wird via ssh eingebunden und Sicherungen werden geschrieben.
Jetzt habe ich mir das noch mla in punkto Sicherheit angeschaut und wollte eigentlich auf ssh key wechseln (u.a. um MFA für den Backup User aktivieren zu können), aber das hat bei mir nicht geklappt. Zwar kann ich per konsole ohne passwort mit dem hidrive ssh Server verbinden, aber hyperbackup akzeptiert das Set-Up nicht ohne Angabe eines Passworts. Dazu habe ich auch im synology Forum einen Bericht gefunden: https://community.synology.com/enu/forum/1/post/188372
Daher meine erste Frage: weiß jemand ob und wie man hyperbackup mit ssh-key unter aktuellem DSM ans Laufen bekommen kann?
Da ich das jedenfalls erst mal nicht hinbekommen habe, wollte ich für den User ein langes Passwort verwenden. Ich habe eines mit den bei hidriv maximal möglichen 128 Zeichen verwendet. Allerdings verbindet sich hyperbackup dann nicht mehr. Ich habe lange nach einem möglichen Fehler gesucht, auch rsync als Backup Ziel ausprobiert und die Serverdaten von hidrive manuell eingegeben. Es ging dann erst als ich das Passwort auf ca. 40 Zeichen verkürzt hatte. ... Ich habe auch passphrases ohne besondere Sonderzeichen probiert, das scheint keinen unterschied zu machen.
Meine zweite Frage: kennt jemand dazu Hintergünde oder noch besser möglichkeiten DSM zu überreden ein langes Passwort zu akzeptieren?
Ich überlege jetzt als Alternative einen Rapserry PI, der hier eh werkelt als eine art "Bridge" zu verwenden, der einerseits die Verbindung zum RSYNC auf hidrive aufmacht, mit SSH Key abgesichert und intern einen RSYNC mit einem passenen Passwort oder das als Laufwerk bereitstellt ... ist aber irgendwie ein merkwürdiger Workarround. Ich habe auch noch keine Ahnung, wie ich den Rasperry dazu bringe, den Traffic an rsync weiterzureichen, da müsste ich vermutlich etwas rumbasteln, meine Skriptfähikeiten sind leider etwas eingerostet.