Rsync als root per ssh auf Synology: wrong password (code 44)

[Benutzername_]

Hallo zusammen,

ich möchte per rsync Dateien von einer Synology DS923+ auf eine DS213j sichern. Leider klappt der Login als root über rsync nicht. Hat jemand eine Idee?

SSH PSK ist erstellt und funktioniert grundsätzlich:

user@syno_ds923:~# ssh -i ~/.ssh/root@syno_ds213_psk root@syno_ds213 root@syno_ds213:~#

Damit das funktioniert:
/etc/ssh/sshd_config auf syno_ds213
PermitRootLogin yes

Wenn ich allerdings rsync nutze, funktioniert die Authentifizierung weder per Key, noch per Passwort.

user@syno_ds923:~# rsync --stats --delete -avpzRe "ssh -p 22 -i ~/.ssh/root@syno_ds213_psk" /volume1/dir_1/ root@syno_ds213:/volume1/backup_dir/ sending incremental file list rsync error: wrong password (code 44) at io.c(254) [sender=3.1.2] user@syno_ds923:~# rsync --stats --delete -avpzRe "ssh -p 22" /volume1/dir_1/ root@syno_ds213:/volume1/backup_dir/ root@syno_ds213's password: sending incremental file list rsync error: wrong password (code 44) at io.c(254) [sender=3.1.2]

Warum brauche ich root auf der syno_ds213?

Aus irgendeinem Grund bekomme ich haufenweise Berechtigungsfehler auf der syno_ds213 obwohl "backup_dir" dem user@syno_ds213 gehört.
user@syno_ds923:~# rsync --stats --delete -avpzRe "ssh -p 22 -i ~/.ssh/user@syno_ds213_psk" /volume1/dir_1/ user@syno_ds213:/volume1/backup_dir/ *** Skipping any contents from this failed directory *** rsync: recv_generator: mkdir "/volume1/backup_dir/sub_dir/sub_dir/sub_dir" failed: Permission denied (13) *** Skipping any contents from this failed directory ***

Mögliche Alternative, die ich versucht habe aber auch nicht zielführend war:

user@syno_ds923:~#sudo rsync --stats --delete --rsync-path "sudo /bin/rsync" -avpzRe "ssh -p 22 -i /root/.ssh/user@syno_ds213_psk" /volume1/dir_1/ user@syno_ds213:/volume1/backup_dir/ sending incremental file list rsync error: wrong password (code 44) at io.c(254) [sender=3.1.2]

/etc/sudoes auf syno_ds213
user ALL= NOPASSWD:/bin/rsync

Eckdaten
DS923+
DSM 7.1.1-42962 Update 3
rsync version 3.1.2 protocol version 31

DS213j
DSM 7.1.1-42962 Update 1
rsync version 3.1.2 protocol version 31

 

[Tommes]

Hi!

Könntest du deine Codeschnipsel bitte als zusammenhängen Code formatieren...

Danke!

 

[Tommes]

Warum müsst ihr immer alle in der /etc/ssh/sshd_config und in der sudoers rumspielen?

Um sich per SSH direkt als root aufschalten zu können um darüber dann einen rsync abzufeuern, bedarf es einer passwortlosen SSH Authentifizierung. Ich hab den Weg hier irgendwo auch mal beschrieben. Einfacher wäre es jedoch, wenn du dir mal meine App Basic Backup installierst, dir dort dann die Hilfe zur Einrichtung einer SSH Verbindung durchliest und diese entsprechend abarbeitest. Du musst Basic Backup auch nicht nutzen, auch wenn es genau das macht, was du vor hast. Aber das liegt ganz bei dir.

 

[Tommes]

Da fällt mir grad noch was ein.

Eigentlich kann man sich garnicht mehr als root auf eine DS aufschalten um, wie in deinem Fall, einen rsync abzufeuern. Der rsync Error Code 44 ploppt deshalb auf, weil der Benutzer „admin“ in deiner DS deaktiviert ist. Da der Error Code nicht sehr aussagekräftig ist, habe ich das in meiner App mal so beschrieben…

Rsync meldete den Exit-Code 44: ### Falsches Passwort. Pruefen Sie, ob das Standardkonto -admin- deaktiviert ist. Dieses muss auf der Quell- und Ziel-DiskStation aktiviert sein, wenn root als SSH-Benutzer verwendet wird.

Du hast jetzt also die Wahl, ob du den admin aktivieren möchtest um das Problem zu lösen, oder ob du zukünfitg mit eingeschränkten Benutzerrechten zurecht kommst, je nachdem, ob du ein Push oder ein Pull Backup ausführen möchtest.

In Basic Backup habe ich das so gelöst, das wenn man ein Pull Backup ausführt, sich also die Daten von einem Remote Server auf die lokale DS zieht, auf der lokalen DS als root arbeiten kann und sich auf den Remote Server mit eingeschränkten Benutzerrechten per SSH verbindet Um die Daten dort abzuholen. Das geht auch mit eingeschränkten Rechten ganz gut.

Umgekehrt, wenn du ein Push Backup ausführst, du also lokale Daten auf einen Remote Server schieben möchtest, benötigst du auf den Zielserver bestenfalls auch root Rechte, was Synology jedoch durch den deaktivieren admin nicht zulässt. Daher verwende ich auch hier eine Verbindung mit eingeschränkten Rechten und hänge dem rsync die Option

--chmod=ugo=rwX

… an, damit bei einem Push Backup keine Zugriffsprobleme im Ziel der Datensicherung auftreten. Das sollte all deine Probleme in der Theorie lösen. Wie gesagt. In der Theorie

Tommes

 

[Benie]

ich möchte per rsync Dateien von einer Synology DS923+ auf eine DS213j sichern.

Gibt es einen besonderen Grund, dass Du das über ssh und die Konsole machst.

Der DSM bringt auf beiden Deiner DS bereits eine absolut einfache Möglichkeit für rsync mit. (Ohne Hyperbackup) Nutze ich seit vielen Jahren, Außerdem kannst Du ja auch Hyperbackup mit rsync nutzen.

 

[luddi]

@Benutzername_ Hast du auf der DS213j auch den rsync Service aktiviert unter Systemsteuerung -> Dateidienste -> rsync -> rsync-Dienst aktivieren?

 

[Benutzername_]

Hi!

Könntest du deine Codeschnipsel bitte als zusammenhängen Code formatieren...

Danke!

Moin Tommes,
danke für den Hinweis. Ich scheine die initialen Post nicht mehr bearbeiten zu dürfen/können. Werde ich bei den zukünftigen beachten.

 

[Benutzername_]

Warum müsst ihr immer alle in der /etc/ssh/sshd_config und in der sudoers rumspielen?

[...]

Nun... weil es grundsätzlich in einem Linux-System geht. Zugegeben, mit DSM kann es Seiteneffekte geben aber auf dem System soll neben dem File-Backup nichts laufen. Und ansonsten sind solche kleinen Änderungen auch nach einem Update schnell wieder gemacht.

[...]
Eigentlich kann man sich garnicht mehr als root auf eine DS aufschalten um, wie in deinem Fall, einen rsync abzufeuern. Der rsync Error Code 44 ploppt deshalb auf, weil der Benutzer „admin“ in deiner DS deaktiviert ist. Da der Error Code nicht sehr aussagekräftig ist, habe ich das in meiner App mal so beschrieben…
[...]

Da wäre ich nie drauf gekommen... aber es scheint zu funktionieren. Der Login an sich geht nun. Ob jetzt noch Berechtigungsprobleme auftreten, muss ich schauen. Die ersten Ordner sehen gut aus. Vielen Dank für den Hinweis!

[...]
--chmod=ugo=rwX

… an, damit bei einem Push Backup keine Zugriffsprobleme im Ziel der Datensicherung auftreten. Das sollte all deine Probleme in der Theorie lösen. Wie gesagt. In der Theorie

Sieht auf den ersten Blick etwas radikal aus . Grundsätzlich ist der --perms Parameter ja eine feine Sache. Aber wenn man nur die Files an sich braucht, dann wohl eine Option.

 

[Benutzername_]

Gibt es einen besonderen Grund, dass Du das über ssh und die Konsole machst.

Der DSM bringt auf beiden Deiner DS bereits eine absolut einfache Möglichkeit für rsync mit. (Ohne Hyperbackup) Nutze ich seit vielen Jahren, Außerdem kannst Du ja auch Hyperbackup mit rsync nutzen.

Ich bin einfach Purist und habe bereits diverse Backup-Skripte zur Sicherung von anderen Linux-Systemen per rsync liegen und laufen. Diese habe ich einfach modifiziert und per Cron eingerichtet. Das lässt sich wunderbar einfach von System zu System transportieren und "sichern" (Stichwort git).

 

[Benutzername_]

@Benutzername_ Hast du auf der DS213j auch den rsync Service aktiviert unter Systemsteuerung -> Dateidienste -> rsync -> rsync-Dienst aktivieren?

Ist aktiviert und läuft.

 

[framp]

Der rsync Error Code 44 ploppt deshalb auf, weil der Benutzer „admin“ in deiner DS deaktiviert ist.

Kleiner Kommentar von mir: Bei mir ist der "admin" deaktiviert und ich habe einen anderen Benutzernamen mit Adminrechten angelegt. Gibt ein bischen mehr Zugriffssicherheit jedenfalls komme ich auch ohne den "admin" Nutzer ohne Probleme per ssh und keys in die Syno rein.

 

[Tommes]

Ich habe das selbe Setup wie du und wenn ich mich von meinem Linux Mint Terminal aus, direkt per SSH als root mit einem Passwortlosen RSA-Key auf der DS aufschalte, dann klappt das auch. Das funktioniert jedoch nicht, wenn das ein Script versucht. So war es jedenfalls bisher - und auch schon unter DSM 6 gewesen. Da der Exit Code 44 auch nicht wirklich aussagekräftig ist, haben wir damals auch lange nach einer Lösung gesucht, bis uns das mit dem deaktivieren admin aufgefallen ist

Tommes

 

[framp]

Das funktioniert jedoch nicht, wenn das ein Script versucht.

Stimmt. ich hatte gedacht wenn ssh der Zugriff funktioniert dann auch mit rsync

framp@majestix:~/t$ rsync --debug=ALL synolix:/* .
opening connection using: ssh synology rsync --server --sender -e.LsfxC --debug=ALL . "/*"  (9 args)
(Server) Protocol versions: remote=31, negotiated=31
(Client) Protocol versions: remote=31, negotiated=31
server_sender starting pid=17194
[sender] send_msg(3, 33)
ERROR: user has disabled/expired
rsync error: wrong password (code 44) at main.c(817) [sender=3.1.2]
[sender] _exit_cleanup(code=44, file=main.c, line=817): about to call exit(44)
[sender] send_msg_int(86, 44)
[Receiver] send_msg(86, 0)
[Receiver] _exit_cleanup(code=44, file=io.c, line=1658): about to call exit(44)

 

[Tommes]

Verrückt, oder? Da muss man erstmal drauf kommen.

 

[luddi]

Das funktioniert jedoch nicht, wenn das ein Script versucht.

Was genau meinst du hiermit?

Ich denke du meinst folgendes:
Wenn sich "root" via SSH interaktiv mit der Login-Shell verbindet funktioniert das.
z.B. somit: ssh -p 22 -i ~/.ssh/identity root@diskstation

Wenn man aber rsync mit SSH als Transportschicht verwendet funktioniert das nicht.
z.B. somit: rsync -a -e "ssh -p 22 -i ~/.ssh/identity" root@diskstation:/volume1/share/foo ~/target/

Das ist aber unabhängig ob das ganze per Skript oder direkt aus der Kommandozeile aufgerufen wird.
Meines Erachtens liegt das nicht an SSH selbst, sondern dass "root" wohl aus welchem Grund auch immer nicht für "rsync" berechtigt ist.

Anders herum sind normale User zwar nicht berechtigt sich interaktiv mit der Login-Shell via SSH zu verbinden, aber sobald diese Benutzer für rsync berechtigt sind können sie SSH als Trasnportschicht für rsync verwenden.

Ich selbst habe auch noch keine Möglichkeit gefunden "root" für rsync zu berechtigen.

 

[framp]

@luddi So wird es sein. Vermutlich kann man das irgendwo im pam fuer rsync definieren. Mit pam habe ich aber keine Erfahrung.

root@synology:/# cat /etc/pam.d/rsync
auth    requisite                     pam_syno_autoblock.so
auth    required                      pam_syno_smartblock.so
auth    [success=3 default=ignore]    pam_unix.so
auth    [success=2 default=ignore]    pam_winbind.so
auth    [success=1 default=ignore]    pam_ldap.so
auth    [default=die]                 pam_syno_log_fail.so [Rsync]
auth    [default=done]                pam_syno_log_success.so [Rysnc] log=no
account [success=3 default=ignore]    pam_unix.so
account [success=2 default=ignore]    pam_winbind.so
account [success=1 default=ignore]    pam_ldap.so
account [default=die]                 pam_syno_log_fail.so [Rsync]
account [default=done]                pam_syno_log_success.so [Rsync] log=no

 

[Tommes]

Was genau meinst du hiermit?

Hab mich da wohl wirklich etwas schwammig bzw. unglücklich ausgedrückt. Denn du hast vollkommen recht mit deinen Aussagen. Man braucht nicht zwingend ein Script um den Exit-Code 44 zu provozieren, es reicht ein rsync Befehl, der den Aufbau einer SSH Verbindung initiieren möchte. Schließlich stammt der Exit-Code ja auch von rsync und nicht von ssh.

Ich selbst habe auch noch keine Möglichkeit gefunden "root" für rsync zu berechtigen.

Hier fällt mir halt auch nur das Aktivieren des "admin" Kontos ein.

 

[luddi]

Vermutlich kann man das irgendwo im pam fuer rsync definieren

Das muss ich mir auch mal anschauen.

@Tommes Hauptsache ICH habe diesmal "vertanden" was du gemeint hast

Aktivieren des "admin" Kontos ein.

Aber dann würde die Anmeldung auch als "admin" erfolgen und nicht als "root".
Das kann man dann aber auch mit einem alternativen Administrator Account bewerkstelligen ohne den default "admin" aktivieren zu müssen.

 

[framp]

Das muss ich mir auch mal anschauen.

Ich habe gerade mal diesen Artikel diagonal gelesen. Er gibt einen guten Ueberblick. So wie ich das verstehe ist syno-autoblock und syno_smartblock compilierter Code. D.h. wenn man da was aendern will ist das nicht einfach eine Config Dateiaenderung sondern man muss pam Code schreiben.

 

[Tommes]

@Tommes Hauptsache ICH habe diesmal "vertanden" was du gemeint hast

Haha, ja. Stimmt! Hammer

Aber dann würde die Anmeldung auch als "admin" erfolgen und nicht als "root".

Nö. Sobald du den "admin" Account im DSM aktivert hast, solltest du dein rsync Befehl rsync -a -e "ssh -p 22 -i ~/.ssh/identity" root@diskstation:/volume1/share/foo ~/target/ als root ausführen können. So war es bisher jedenfalls immer gewesen. Ich mag das grad nur nicht testen, da ich momentan einem anderen Problem auf die Schliche kommen muss. Aber so wie ich dich einschätze, wird dir das keine Ruhe lassen und wist es selbst testen.