rsync: owner & group nicht berücksichtigt

[buhtz]

Ich versuche von einem alten Server auf einen neuen Dateien zu kopieren. Auf dem alten rufe ich rsync auf.
Die relevanten Nutzer und Gruppen (incl. UID und GID) stimmen auf beiden Servern miteinander überein.

Code: Alles auswählen

sudo rsync ./test-src ayako@debianvm:/home/ayako --archive --hard-links --human-readable --verbose --progress -partitial --log-file=rsync.log 

Dennoch entsprechen die Eigentumsverhältnisse auf dem neuen Server dem Nutzer ayako und der dazu passenden Gruppe.

Hatte auch --super und --fake-super probiert, ohne genau zu wissen, was das ist und wozu es nötig sein könnte.

[Tintom]

Schau dir mal die Option -a an.
Wolltest du (lt. dem anderen Thread) explizit kein eigenes Skript schreiben?
Es gibt nämlich schon fertige und gut erprobte Skripte (der Hinweis von uname ist quasi die Standardreferenz): viewtopic.php?p=1166146#p1166146

[buhtz]

Schau dir mal die Option -a an.

Die habe ich bereits mit --archive gesetzt und die Funktion habe ich IMO auch verstanden. Die relevanten Schalter --owner und --group sind damit inkludiert.
Die Rechte werden ja auch korrekt gesetzt, aber owner und group nicht.

Wolltest du (lt. dem anderen Thread) explizit kein eigenes Skript schreiben?

Meinst du viewtopic.php?p=1255078? Dort geht es auch um eine ganz andere Maschine in einem anderen Environment und einen anderen Anwendungsfall (dort: Backup, hier: 1maliger Server-Umzug). Hat nix mit dem Thread hier zu tun.

EDIT: Bei dem Hinweis von uname sehe ich keinen relevanten Unterschied zu meinem Aufruf.

[DeletedUserReAsG]

Ziel: ayako@debianvm:/home/ayako ← Protokoll? Darunterliegendes Dateisystem? Kann der Benutzer auf dem Zielsystem seine Files einfach einer anderen UID zuweisen – das ist normalerweise aus Sicherheitsgründen nicht erlaubt?

[heisenberg]

--numeric-ids vielleicht sinnvoll?

[buhtz]

--numeric-ids vielleicht sinnvoll?

Unwahrscheinlich. Die UID und GID stimmen auf beiden Systemen überein.

Ziel: ayako@debianvm:/home/ayako ← Protokoll? Darunterliegendes Dateisystem? Kann der Benutzer auf dem Zielsystem seine Files einfach einer anderen UID zuweisen – das ist normalerweise aus Sicherheitsgründen nicht erlaubt?

Beides ist ein Debian 10 mit default Dateisystem (ext4?).
Protokoll? Default - was rsync da halt nimmt. Vermutlich SSH. Gibts Alternativen für?

Natürlich hat Ziel-ayako nicht solche Rechte.

Wie denken sich die rsync-EntwicklerInnen das dann? Ich soll diesen user sicherlich nicht temporär zur Gruppe root hinzufügen, oder?
Welche Bedinungen müssen gegeben sein, damit die Nutzer- und Gruppennamen geändert werden können. Was passiert überhaupt auf dem Zielsystem? Vermutlich läuft dort ein rsync-daemon? Mit welchen Rechten läuft der?

[Tintom]

Laut Manpage ist die Syntax rsync <Option> <QUELLE> <ZIEL>. Was passiert, wenn du die Optionen vor <Quelle> ziehst?

[smutbert]

Wo die Option steht ist egal.

Wie denken sich die rsync-EntwicklerInnen das dann?

in der Beziehung denken die rsync-Entwickler imho gar nichts, müssen sie auch nichts und wie sie etwas ändern könnten wüßte ich auch nicht.

Welche Bedinungen müssen gegeben sein, damit die Nutzer- und Gruppennamen geändert werden können. Was passiert überhaupt auf dem Zielsystem? Vermutlich läuft dort ein rsync-daemon? Mit welchen Rechten läuft der?

Üblicherweise läuft auf dem Zielsystem der ssh-Server, dh rsync macht alles über rsync und hat genau die Rechte, die der Benutzeraccount auf dem ssh-Server hat, den man verwendet.
Die Alternative wäre auf der Serverseite tatsächlich der rsync-Daemon, der standardmäßig in »/etc/default/rsync« deaktiviert ist. rsyncd läuft dann glaube ich als root und dürfte alles – im Gegensatz zu ssh hängt die Sicherheit dann aber allein an der Sicherheit der Netzwerkverbindung.

Ich soll diesen user sicherlich nicht temporär zur Gruppe root hinzufügen, oder?

Bei der üblichen Konstellation mit ssh, ist es verbreitet das Synchronisieren als root zu machen.

Bei dir liegt das Ziel entfernt auf dem Server, dh du könntest auf dem Quellsystem/Client ein ssh-Schlüsselpaar erzeugen und den öffentlichen Schlüssel zu den „authorized keys“ von root auf dem Server hinzufügen. Dann funktioniert die Anmeldung via ssh als root auf dem Server ohne Passworteingabe, bzw. nur mit der Eingabe der Passphrase, die du bei der Schlüsselerstellung angeben kannst.

Also hier Schritt 1-5 auf dem Client und dann den öffentlichen Schlüssel, zB id_rsa.pub auf dem Server in die Datei »/root/.ssh/authorized_keys« schreiben (die Hilfsmittel wie ssh-copy-id funktionieren üblicherweise nicht, weil der ssh-login als root mit Paswort deaktiviert ist)
https://www.heise.de/tipps-tricks/SSH-K ... 00280.html


Eine andere Variante wäre rsync auf dem Server auszuführen, wenn man Client der ssh-Server installiert ist, geht es ja genauso und zB mit sudo dafür sorgen, dass man den rsync-Befehl auf dem Server als root ausführen darf.
Damit keine Passworteingabe notwendig ist, kann man wieder, diesmal auf dem Server, ein ssh-Schlüsselpaar erzeugen, mit dem Vorteil, dass bei Verwendung dank sudo kein ssh-Login als root notwendig ist.


Und natürlich, das hat Tintom ja schon geschrieben die Option -a von rsync, damit die Metadaten erhalten bleiben oder auch nur -og (für owner und group also das Beibehalten von Benutzer und Gruppe). -a „enthält“ noch mehr Optionen zum Beibehalten von Dateieigenschaften - hier hilft die manpage von rsync

[MSfree]

Die Alternative wäre auf der Serverseite tatsächlich der rsync-Daemon, der standardmäßig in »/etc/default/rsync« deaktiviert ist.

Das ist nicht die einzige Möglichkeit. Man sich auch als root@zielrechner über ssh verbinden, dann hat man root-Rechte auf dem Server.

rsyncd läuft dann glaube ich als root und dürfte alles – im Gegensatz zu ssh hängt die Sicherheit dann aber allein an der Sicherheit der Netzwerkverbindung.

Es ist vor allem unverschlüsselt.

Was rsyncd dann alles darf, bzw. was der Gegenüber dann alles darf, kann man mit der Datei /etc/rsyncd.conf steuern. Z.B. sind die rsyncd-Instanzen, mit denen man einen Debianmirror klonen kann, immer Read/Only, ich darf da also keinen Blödsinn hochladen.

[buhtz]

Hab da ein kleines Problem.

Ich kann nicht ssh root@debianvm machen. Ebenso kann ich direkt am login-promt der debianvm mich nicht als root anmelden.
Der root Account wurde bei der Installation deaktiviert, da ich kein Password angegeben habe.
sudo su geht aber.

Was wäre jetzt eine ordentliche debianoide Vorgehensweise? Ich wüsste nicht mal, wie ich root temporär aktivieren könnte.

Nebenbei:
In /etc/ssh/sshd_config habe ich das SSH-Anmelden als root bereits erlaubt.

Code: Alles auswählen

PermitRootLogin yes
PasswordAuthentication yes

[smutbert]

root kann sich vermutlich nur deswegen nicht anmelden, weil root kein Passwort hat. Nach einem

Code: Alles auswählen

sudo passwd

und zweimaliger Eingabe eines neuen Root-Passworts sollte es mit der Anmeldung als root klappen.

An der sshd-Konfiguration hättest du gar nichts ändern müssen - die verbietet in debian per default nur den login als root mit Passwort. Wenn du die Authentifizierung mit ssh-Schlüsseln machst, stört das nicht.
(Du hättest dann nur sudo benötigt um den Schlüssel auf dem ssh-Server in die authorized_keys von root zu bekommen. Mit aktiviertem root-Account geht es halt auch etwas direkter mit ssh-copy-id.)

Das ist nicht die einzige Möglichkeit. Man sich auch als root@zielrechner über ssh verbinden, dann hat man root-Rechte auf dem Server.

Das habe ich doch auch gemeint bzw. zu beschreiben versucht (der Teil mit »/root/.ssh/authorized_keys«).

Was wäre jetzt eine ordentliche debianoide Vorgehensweise? Ich wüsste nicht mal, wie ich root temporär aktivieren könnte.

Da ist nichts debian-spezifisches dabei, aber ich würde es beispielsweise so machen.

1. wie beschrieben auf dem ssh-Server den root-Account aktivieren

   Code: Alles auswählen

   ssh ayako@debianvm
   sudo passwd
   

2. auf dem Client (nicht mehr in ssh) das ssh-Schlüsselpaar erzeugen

   Code: Alles auswählen

   ssh-keygen
   

   wenn du nicht später, getrennt weitere Schlüsselpaare für andere ssh-Server erzeugen willst, kannst du den vorgeschlagenen Namen (~/.ssh/id_rsa) einfach mit Enter bestätigen. Das Erzeugen der Schlüssel dauert ein paar Sekunden und am Ende wirst du noch nach einer Passphrase gefragt.
   Die passphrase kannst du auch leer lassen, aber wenn du es nicht tust, musst du sie später eingeben, um eine ssh-Verbindung zum ssh-Server herzustellen, also auch beim Start von rsync.
3. Den ssh-Server mit dem eben erzeugten öffentlichen ssh-Schlüssel bekannt machen, ihn also auf dem ssh-Server in die Datei »/root/.ssh/authorized_keys« schreiben.
   Das geht (vom Client aus) mit dem Befehl

   Code: Alles auswählen

   ssh-copy-id -i ~/.ssh/id_rsa root@debianvm
   

   Dabei wird nachgefragt ob du dich tatsächlich mit dem Server verbinden willst und außerdem musst du dich mit dem im ersten Schritt vergegebenen root-Passwort authentifizieren.
   
   Nachdem das erledigt ist, klappt es aber ohne Passworteingabe und du kannst den root-Account wieder deaktivieren (root wieder ein leeres Passwort geben) und du kannst auch in sshd die Passwortauthentifizierung wieder deaktivieren, wenn du willst.

[buhtz]

Mit Aktivierung von root geht es wie erwartet. Vielen Dank!
De-Aktivierung geht übrigens mit passwd -l root.

Schlüsseltausch?
Das mache ich nur bei Accounts die ich regelmäßig nutze.
Viel zu gefährlich - wegen mir selbst. Ich logge mich ja nicht mal lokal als root ein - aus gutem Grund.
Breche mir keinen Zacken aus der Krone, wenn ich da mal n passwort eingebe. Das rsync-run läuft ja nur 1x, um Daten von einem schrottreifen Server auf einen neuen zu replizieren.

Gute Nacht Allerseits.