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

[luddi]

So war es bisher jedenfalls immer gewesen.

Dann scheint es wohl heute nicht mehr so zu sein, ich habe dies soeben versucht.
Default "admin" aktiviert, berechtigungen für rsync erteilt und den Befehl wie bereits erwähnt mit "root@...." rsync via SSH den Befehl auszuführen.

Ich bekomme hier einen error code 12.
rsync error: error in rsync protocol data stream (code 12)

 

[framp]

Dann scheint es wohl heute nicht mehr so zu sein, ich habe dies soeben versucht.

Ich bekomme es auch nicht hin. Man kann bei der Config des rsync Servers noch Benutzer mit UID und PWD definieren. Dann dort die authorized_keys entsprechend updaten und dann koennte es vielleicht klappen. Die Frage ist nur welche Benutzer muss da drin stehen? root? admin? Ist leider ne ziemliche Probiererei ...

 

[Tommes]

Dann frage ich mich aber, warum das bei @Benutzername_ genau so funktioniert hat...

Da wäre ich nie drauf gekommen... aber es scheint zu funktionieren.

... und dieser "Trick" schon zu Zeiten von Ultimate Backup funktionierte. Aber hey... ich schreib’ das mal auf meine Liste mit Dingen, die noch erledigen wollte und schau mir das irgendwann mal an. Aktuell suche ich nach einer Lösung, warum mir meine AutoPilot Funktion in Basic Backup einen Exit Code 32 beim umount auswirft. Das ist echt zum Haare raufen. Da schreibt man Nächte lang an etwas rum, probiert es 1000 mal aus, schreibt wieder etwas um und testet es noch 500 mal... dann veröffentlich man es und schuppdiwupp... hagelt es Fehler und Probleme. Grrrrrrrr....

 

[Benutzername_]

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.

Brauchst du nicht. Kann ich bestätigen.
Mein ursprüngliches Problem ist damit gelöst. Es sind damit (verständlicherweise da root) auch keine Berechtigungsprobleme auf dem Zielsystem aufgetreten. Vielen Dank noch mal für die schnelle Hilfe an alle.

Edit: Ups, habe die Posts auf Seite 2 übersehen. Ich schreibe noch mal sauber zusammen was ich gemacht habe, damit es geht:

 

[luddi]

Kann ich bestätigen.

Weshalb funktiioniert das bei dir? Ich hatte dies selbst probiert und in Beitrag #21 geschildert.
Was genau hast du getan damit rsync mit "root" funktioniert? Würde mich mal grundsätzlich interessieren.

 

[Benutzername_]

Ich habe folgendes getan, damit es geht:

1. User "admin" per DSM Oberfläche aktivieren und PW setzen.
2. Auf dem Zielsystem in der: /etc/ssh/sshd_config
   

   PermitRootLogin yes

3. sudo systemctl restart sshd.service
4. Als root SSH PSK generieren (nur ohne Passphrase getestet)
   ssh-keygen -b 4096
5. cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
6. id_rsa auf Quellsystem ziehen
7. Vom Quellsystem: rsync -avpzRe "ssh -p 22 -i /path/to/id_rsa" /volume1/dir_1/ root@zielsystem:/volume1/backup_dir/

Und so läuft es gerade bei mir.

Vielleicht ist es das Passwort-Setzen für den Admin-User?

 

[Benutzername_]

Ich bekomme es auch nicht hin. Man kann bei der Config des rsync Servers noch Benutzer mit UID und PWD definieren. Dann dort die authorized_keys entsprechend updaten und dann koennte es vielleicht klappen. Die Frage ist nur welche Benutzer muss da drin stehen? root? admin? Ist leider ne ziemliche Probiererei ...

In meiner authorized_keys habe ich:
ssh-rsa [... key ...] root@hostname_zielsystem

 

[luddi]

Vielleicht ist es das Passwort-Setzen für den Admin-User?

Das könnte natürlich sein. Aber lässt du dann auch den Admin User im DSM "aktiviert" damit das klappt?

Bei mir jedenfalls klappt der Zugang per SSH (Login Shell) per "root" schon immer mit RSA Key und das sogar ohne PermitRootLogin yes. Aber in diesem Beispiel in Verbindung mit rsync mag das nicht.
Aber bei mir ist auch der default admin Account deaktiviert, jedoch auch für Testzwecke wie von dier sauber beschrieben klappt das bei mir nicht.

 

[Benutzername_]

Interessant. Wenn ich das PermitRootLogin entferne, geht auch der ssh Zugriff per root bei mir nicht.

Den Admin User muss aktiv bleiben. Wenn ich ihn wieder deaktiviere bekomme ich wieder ein:
rsync error: wrong password (code 44) at io.c(254) [sender=3.1.2]

 

[luddi]

Interessant. Wenn ich das PermitRootLogin entferne, geht auch der ssh Zugriff per "root" bei mir nicht.

Ich habe gerade nochmals das sshd_config in Ruhe angeschaut.

Bei mir ist der aktuelle Zustand der config (und war auch bisher immer so) wie folgt:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

Für diesen Test hatte ich die Raute # um aus dem Kommentar den Eintrag explizit zu machen.
Aber da fiel mir ein dass der Parameter bereits mit yes im Kommentar stand. Daraus lässt sich für mich implizit ableiten, dass diese Option per default bereits auf "yes" steht ohne diesen Modifier explizit zu machen.

Den Admin User muss aktiv bleiben. Wenn ich ihn wieder deaktiviere bekomme ich wieder ein:

Okay dann hat sich das für mich ohnehin erledigt. Den möchte ich nicht unbedingt aktiviert lassen.

 

[Benutzername_]

Für diesen Test hatte ich die Raute # um aus dem Kommentar den Eintrag explizit zu machen.
Aber da fiel mir ein dass der Parameter bereits mit yes im Kommentar stand. Daraus lässt sich für mich implizit ableiten, dass diese Option per default bereits auf "yes" steht ohne diesen Modifier explizit zu machen.

Das scheint bei mir aber anders zu sein bzw. dann noch an an weiteren Parametern/Configs zu hängen. Ich habe es nie mit einem expliziten no getestet, sondern immer die Zeile auskommentiert. So wie ich es meiner Erinnerung nach auch im default war. Und wenn sie bei mir auskommentiert ist, geht der Login per root gar nicht.

 

[Benutzername_]

Es hängt vielleicht auch mit dem Modell zusammen: Auf dem Quellsystem in meinem Szenario (DS 923+) ist die sshd_config noch unbearbeitet und hat ein #PermitRootLogin prohibit-password eingetragen.

 

[Tommes]

Ich pack die sshd_config überhaupt nicht an, sonder lasse immer alles auf den Standardeinstellungen

 

[Tommes]

Normalerweise ist das so.

• Einrichtung der SSH-Ordnerstruktur (~/.ssh) für einen Administrator oder besser noch, für root. Erstellen der RSA-keys ohne Eingabe eines Passwortes (passwortlose RSA Schlüssel Authentifizierung) sowie einstellen der Ordner- und Dateirechte auf der lokalen DS.
• Den Standard „admin“ Account auf der Remote DS aktivieren und ggf. ein Passwort vergeben. Unter Umständen ist das Passwort identisch mit dem bereits neue angelegten, alternativen Administrator.
• Einrichtung der SSH-Ordnerstruktur (~/.ssh) für root, anlegen der Datei authorized_keys sowie einstellen der Ordner- und Dateirechte auf der Remote DS.
• Ggf. einen ersten Handshake zwischen lokaler und Remote DS ausführen.
• Austausch des öffentlichen .pub RSA-Schlüssels von der lokalen DS in Richtung Remote DS mit z.B. cat ~/.ssh/[FILENAME].pub | ssh -p [PORT] root@[SERVER-ADDRESS] "cat >> ~/.ssh/authorized_keys"
• Abschließend testen, ob alles funktioniert mit z.B. ssh -p [PORT] root@[SERVER-ADDRESS]
• Und der Drops sollte gelutscht sein.

Darüber ist es letztendlich möglich einen rsync per ssh abzufeuern, der an den root der Remote DS gerichtet ist. Ganz ohne eine Anpassung der sshd_config o.ä.

Tommes

 

[luddi]

• Abschließend testen, ob alles funktioniert mit z.B. ssh -p [PORT] root@[SERVER-ADDRESS]

All das was du hier so ausführlich beschreibst ist alles verständlich und auch längst bei mir gängige Praxis auf jeglichen Systemen. Dennoch kann ich auf meinem System kein rsync mit root ausführen obwohl der Zugang per Login-Shell als "root" problemlos möglich ist.

Darüber ist es letztendlich möglich einen rsync per ssh abzufeuern, der an den root der Remote DS gerichtet ist.

Ist aber bei mir nicht möglich, selbst wenn der default "admin" aktiviert ist.

Bezüglich der config findet man unterschiedliche Versionen von sshd_config(5). Hier mal zwei Besipiele...

Quelle: https://linux.die.net/man/5/sshd_config
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument must be ''yes'', ''without-password'', ''forced-commands-only'', or ''no''. The default is ''yes''.

If this option is set to ''without-password'', password authentication is disabled for root.

[...]

Wohingegen diese Version folgendes bechreibt:

Quelle: https://manpages.ubuntu.com/manpages/bionic/man5/sshd_config.5.html
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument must be yes,
prohibit-password, forced-commands-only, or no. The default is prohibit-password.

If this option is set to prohibit-password (or its deprecated alias,
without-password), password and keyboard-interactive authentication are disabled for
root.

[...]

Nachdem bei mir die Config per default so #PermitRootLogin yes aussah und auch immer noch genau so aussieht gehe ich stark davon aus dass auf meinem System dies zutrifft: The default is ''yes''

Wenn hier ein "prohibit-password" oder dessen veraltete alias "without-password" verwendet wird, so ist eine interaktive Anmeldung für root nicht möglich.

 

[Tommes]

Wie gesagt… so hat das bisher immer funktioniert. In Wirklichkeit ist mein Standard „admin“ Konto generell aber deaktiviert und ich verbinde mich bei rsync over SSH mit einem alternativen Administrator- bzw. speziellen rsync Benutzerkonto. Genauso arbeitet übrigens auch Basic Backup. Lokal wird das rsync Script als root ausgeführt, die Verbindung auf die Remote DS erfolgt über einen Benutzer mit eingeschränkten Rechten, wozu halt auch ein Administrator gehört. Damit ein Push-Backup fehlerfrei ausgeführt wird, gebe ich dem rsync die Option --chmod=ugo=rwX mit um Rechtsproblemen aus dem Weg zugehen. Das geht natürlich zu Lasten bzw. zum Verlust der Orginal Ordner- und Dateirechte… wobei Besitzrechte (-o) und Gerätedateien (-D) unter Verwendung der rsync Option -a eh nur als root ins Ziel übertragen werden.

 

[luddi]

Wie gesagt… so hat das bisher immer funktioniert.

Und wie gesagt... hat das bei mir mit rsync noch nie funktioniert
Das bringt uns aber an dieser Stelle nicht weiter wenn jeder der Meinung ist "Hat bei mir schon immer so funktioniert".

Mir persönlich geht es auch nicht primär um script basierte rsync Aufgaben, sondern eher darum dass man als root auch manuell (z.B. Config) Dateien relativ einfach über die Kommandozeile übertragen kann.
Also lieber @Tommes es geht bei rsync nicht immer nur um Backups oder anderweitige Aufgaben die im Hintergrund als Script laufen

 

[Benares]

gebe ich dem rsync die Option --chmod=ugo=rwX mit um Rechtsproblemen aus dem Weg zugehen

Ich verstehe wenig davon, aber hebelst du damit nicht die Vererbungshierarchie von Windows-ACL je nach Zielverzeichnis aus?
Ok, bin gleich wieder weg, ist mir aber grad aufgefallen.

 

[Tommes]

Und wie gesagt... hat das bei mir mit rsync noch nie funktioniert

Du bist halt was besonderes und hebst dich von der Masse ab

Aber im Ernst. Dieses Phänomen und der damit verbundene rsync-Error 44 ist uns irgendwann im Jahr 2016 oder 2017 bei Ultimate Backup bewusst aufgefallen. Seit dem verfolgt mit dieser Error Code also schon und bisher war es immer so, das wenn das Standard admin Konto aktiviert wurde, konnte man einen rsync over SSH an den Remote root übermitteln.

Was soll ich also noch dazu sagen? Mag sein, das ich zwischenzeitlich irgendwas verpasst habe, aber ich kenne das halt nur so. Ich kann ja auch nichts dafür

 

[Tommes]

@Benares
Genau aus diesem Grund habe ich diese Option in Basic Backup mit dem Hinweis „expermimentell“ versehen. Und wie das bei Optionen so ist, kann jeder für sich entscheiden, ob er diese nutzen möchte oder nicht. Da ich keine Berührungspunkte mit Windows ACL habe und auch sonst nicht jede Eventualität und jeden Seiteneffekt selber testen und bewerten kann, bin ich auf euer Feedback angewiesen. Bis heute hat sich zu diesem Thema aber noch niemand geäußert. Du darfst dich gerne damit näher auseinandersetzen und mir entsprechendes Feedback geben… wenn du magst.