Owner UID & Group GID auf zwei Servern identisch

Titelbild: Image by Raphael Silva from Pixabay

Hier geht’s um Grundlagen zum Thema rechnerübergreifendender Datentausch – mit sechs Übungen – quick and dirty.

LDAP

Zur Verwaltung und Authentifizierung von Benutzern und Gruppen, also beim Mehrbenutzerbetrieb in IT-Infrastrukturen ist in der Regel LDAP (Lightweight Directory Access Protocol), ein zentraler Verzeichnisdienst, die angesagte Wahl. Dieser Ansatz ermöglicht es, viele Benutzer und Gruppen effizient zentral zu verwalten, Berechtigungen zu steuern und Authentifizierung sowie Single Sign-On über mehrere Systeme zu realisieren.

Zum weiteren Verständnis sollte der Inhalt des vorherigen Beitrags Rechteverwaltung dir geläufig sein.

Szenario q&d

Sind die User- und Gruppenzahlen eher sehr klein und auch die Anzahl der beteiligten Rechner ebenso sehr niedrig, erscheint ein LDAP oft zu aufwendig. Ich verwende in solchen Fällen gerne eine einfache und weniger aufwendige „quick and dirty“ Lösung.

Die Grundidee dabei ist auf den (beiden) beteiligten Rechnern die (zwei) gleiche User (gleiche UID) mit ihrer gleichen Hauptgruppe (Primär-Gruppe) (gleiche GID) anzulegen, um beim späteren Datenaustausch über die jeweiligen Rechnergrenzen hinweg keine Konflikte mit abweichenden Besitzer- und Gruppen-Rechten zu bekommen.

Um die UID und GID für einen Benutzer auf zwei Rechnern gleich zu machen, musst du die Werte gezielt angleichen. Das ist besonders wichtig für Dateizugriffe über NFS, rsync, oder andere Sync-Tools, damit die Besitzrechte korrekt zugeordnet werden.

Systematisches und konzentriertes Vorgehen ist dabei unabdingbar. Wir gehen Schritt für Schritt vor.

Hier die Beteiligten

• mein.server-eins.de (server1)
• mein.server-zwei.de (server2)
• User otto und Group otto soll‘s letztendlich auf beiden Rechner mit jeweils gleicher UID und GID geben.
• außerdem soll es noch eine Gruppe zugriff mit gleicher GID auf beiden Rechnern geben
  in dieser Gruppe zugriff sind jeweils die User otto Mitglied
• mein.server-eins.de hat u.a. folgendes Verzeichnis ~/erste_spielwiese dort liegt u.a. die Datei erste_textdatei.txt
• mein.server-zwei.de hat u.a. folgendes Verzeichnis ~/zweite_spielwiese dort liegt u.a. die Datei zweite_textdatei.txt
• auf mein.server-eins.de (server1) soll es unter /opt direkt einen Ordner temp1 geben mit den Rechten
  rwxrwx—- root zugriff
• auf mein.server-zwei.de (server2) soll es einen zentralen Ordner temp2 unter /opt/bu-gustav/temp2 geben
  auf diesen Ordner hat der user root die Rechte rwx und die Gruppe zugriff hat die Rechte – r-x alle anderen haben —x
• der Ordner nebst Inhalt von mein.server-zwei.de/opt/bu-gustav/temp2 soll nach mein.server-eins.de/opt/temp1 unter Beibehaltung der Rechte kopiert werden

Deine/unsere Aufgaben sind:

1. User otto soll mit gleicher UID auf beiden Rechnern existieren
2. Group otto soll mit gleicher GID auf beiden Rechnern existieren
3. Group zugriff soll mit gleicher GID auf beiden Rechnern existieren
   Mitglieder sind otto
4. SSH ohne Passworte und via Zertifikate abgesichert
5. Die Datei zweite_textdatei.txt soll von Rechner mein.server-zwei.de auf den ersten Rechner mein.server-eins.de kopiert werden und zwar in das Verzeichnis /home/otto/erste_spielwiese
6. Der Ordner nebst Inhalt von mein.server-zwei.de/opt/bu-gustav/temp2 soll nach mein.server-eins.de/opt/temp1 unter Beibehaltung der Rechte kopiert werden

Realisierung

Zunächst sichere ich als root (sudo su -) oder mit root rechten vorsichtshalber mit copy (cp) die Dateien password und group im Ordner /etc

root@server1:# cp /etc/passwd /etc/passwd_backup 
root@server1:# cp /etc/group /etc/group_backup
root@server2:# cp /etc/passwd /etc/passwd_backup
root@server2:# cp /etc/group /etc/group_backup 

zu 1 und 2: User otto und Group otto

Zunächst lege ich als root auf beiden Servern den User otto an. Das leite ich ein mit dem Befehl adduser:

root@server1:# adduser otto
root@server2:# adduser otto

Ich beantworte die Fragen und vervollständige damit die Etablierung der neuen user. Dann navigiere ich schon mal zum home-Verzeichnis des neuen User und frage mit id user jeweils die UI GID und GRUPS ab:

root@server1:# cd /home/otto
root@server1:/home/otto# id otto
uid=1002(otto) gid=1002(otto) groups=1002(otto)

root@server2:# cd /home/otto
root@server2:/home/otto# id otto
uid=1001(otto) gid=1001(otto) groups=1001(otto)  

Wie man erkennt sind die auf den Servern ungleich. Ich entscheide mich auf dem server2 die UID auf 1002 usw. zu ändern. Dazu muss ich zuerst prüfen ob auf server2 die UID=1002, GID=1002 und GROUPS=1002 frei ist. Das mache ich so:

root@server2:/# grep ':1001:' /etc/passwd
otto:x:1001:1001:Otto Mustermann,,,:/home/otto:/bin/bash
root@server2:/# grep ':1002:' /etc/passwd

Zeile 1 ich frage erst via grep nach einer belegten UID
Zeile 2 der server2 antwortet positiv, also ich bin hier erst mal richtig mit dem Syntax
Zeile 3 ich wiederhole die grep Abfrage jetzt mit meiner Wunsch UID, wenn der server2 nix ausgibt ist diese frei.

Alternativ könnte man auch alle vergebenen UIDs sortiert auflisten mit

root@server2:/# cut -d: -f3 /etc/passwd | sort -n

Die Suche nach einer freien GID wiederhole ich entsprechend:

root@server2:/# cut -d: -f3 /etc/group | sort -n

Also meine Wunsch UID 1002 und GID 1002 sind auf server2 frei!

Um die UID (User ID) und GID (Group ID) eines Benutzers (otto) unter Linux zu ändern, werden in der Regel die Befehle usermod und groupmod verwendet. Wichtig ist, nach der Änderung alle Dateizugehörigkeiten systemweit anzupassen, damit bestehende Dateien weiter korrekt zugeordnet werden.
Standardvorgehen für UID-Änderung: sudo usermod -u NEUE_UID BENUTZERNAME

root@server2:/# usermod -u 1002 otto

GID (der primären Gruppe) ändern:
sudo groupmod -g NEUE_GID GRUPPENNAME
sudo usermod -g NEUE_GID BENUTZERNAME

root@server2:/# groupmod -g 1002 otto
root@server2:/# usermod -g 1002 otto

Dateien der alten UID/GID anpassen: !!!
sudo find / -user ALTE_UID -exec chown -h NEUE_UID {} \;
sudo find / -group ALTE_GID -exec chgrp -h NEUE_GID {} \;

root@server2:/# find / -user 1001 -exec chown -h 1002 {} \;
root@server2:/# find / -group 1001 -exec chgrp -h 1002 {} \;

Damit sind die Punkte 1. und 2. abgearbeitet:

root@server1:# cd /home/otto
root@server1:/home/otto# id otto
uid=1002(otto) gid=1002(otto) groups=1002(otto)

root@server2:# cd /home/otto
root@server2:/home/otto# id otto
uid=1002(otto) gid=1002(otto) groups=1002(otto) 

Testweise logge ich mich via SSH mit zwei weiteren Terminalsitzungen als User otto mit Password jeweils auf server1 und server 2 ein und frage anschließend mit dem Befehl pwd das jeweilige Homeverzeichnis ab:

otto@server1:~$ 
otto@server1:~$ pwd
/home/otto

otto@server2:~$ 
otto@server2:~$ pwd
/home/otto

Die Einrichtung des passwortlosen SSH-Zugangs mit keys erläutere ich später hier im Beitrag.

zu3. Gruppe zugriff und Verzeichnis temp1 und temp2

Ich prüfe mit den im vorstehenden Abschnitt gezeigten Methoden ob die gewünschte GID=1111 frei ist. Mit dem nächsten Befehl erstelle ich die Gruppe zugriff und weise ihr die GID=1111 zu:

sudo groupadd -g 1111 zugriff

Falls die GID bereits vergeben wäre, würdest du eine Fehlermeldung erhalten, das ist in unserem Szenario aber nicht zu erwarten, da wir die GID vorher geprüft haben.

Direkt nach dem Anlegen prüfe ich das Ergebnis mit getent und erhalte das Ergebnis in der dritte Zeile:

root@server2:/# groupadd -g 1111 zugriff
root@server2:/# getent group 1111
zugriff:x:1111:

Die gleichen Schritte wiederhole ich auf mein.server-eins.de

root@server1:/# getent group 1111
root@server1:/# groupadd -g 1111 zugriff
root@server1:/# getent group zugriff
zugriff:x:1111:

Nun füge ich auf beiden Rechnern jeweils den User otto der Gruppe zugriff hinzu, ohne das er aus anderen Gruppen entfernt wird. Dafür sorgen die Parameter -a -G

sudo usermod -a -G zugriff otto

Und prüfe die Gruppenzugehörigkeit des users otto

root@server1:/# usermod -a -G zugriff otto
root@server1:/# groups otto
otto : otto zugriff

Um auf server1 nun den Ordner temp1 unter dem Verzeichnis /opt anzulegen und der User otto als Besitzer und die Gruppe zugriff zuzuweisen sowie die Rechte auf rwxrwx— (770) zu setzen, verwende ich folgende Befehle:

root@server1:/# cd/opt
root@server1:/opt# mkdir temp1
root@server1:/opt# chown otto:zugriff /opt/temp1
root@server1:/opt# chmod u=rwx,g=rwx,o= /opt/temp1
root@server1:/opt# ls -lachs
total 16K
4.0K drwxr-xr-x.  4 root root    4.0K Nov 12 09:30 .
4.0K dr-xr-xr-x. 20 root root    4.0K Nov 12 06:59 ..
4.0K drwx--x--x.  4 root root    4.0K Oct  4 19:34 containerd
4.0K drwxrwx---.  2 otto zugriff 4.0K Nov 12 10:19 temp1
root@server1:/opt#

Um auf server2 nun den Ordner temp2 unter dem Verzeichnis /opt/bu-gustav anzulegen und der User otto als Besitzer und die Gruppe zugriff zuzuweisen sowie die Rechte auf rwx r-x —- (750) zu setzen, verwende ich folgende Befehle:

root@server2:/# cd/opt/bu-gustav
root@server2:/opt/bu-gustav# mkdir temp2
root@server2:/opt/bu-gustav# chown otto:zugriff /opt/bu-gustav/temp2
root@server2:/opt/bu-gustav# chmod u=rwx,g=rx,o= temp2
root@server2:/opt/bu-gustav# ls -lachs
total 20K
4,0K drwxr-xr-x 4 root root    4,0K Nov 12 08:18 .
4,0K drwxr-xr-x 5 root root    4,0K Nov  4 08:00 ..
4,0K -rwxr-xr-x 1 root root     395 Nov  5 23:52 bulocal.sh
4,0K drwxr-xr-x 3 root root    4,0K Nov  7 19:52 temp
4,0K drwxr-x--- 2 otto zugriff 4,0K Nov 12 10:24 temp2
root@server2:/opt/bu-gustav#

done.

zu 4. Passwordlosen SSH-Zugang einrichten.

User otto von server1 verbindet sich via SSH und User otto von server2 und landet in seinem Home-Verzeichnis auf Server2. Voraussetzung ist natürlich, dass die jeweiligen Keys zum Beispiel unterhalb des Home Verzeichnises ~/.ssh des jeweiligen users hinterlegt und durch die empfohlenen Dateiberechtigungen geschützt sind, wie im Beitrag Public & Private Key beschrieben.

Treten während des Verbindungsaufbaus Fehlermeldungen, wie z.B. „Permission denied (publickey)“ oder ähnlich sind die Schlüsselpaare nicht in den richtigen Verzeichnissen ~/.ssh oder haben die falschen Rechte. Korrigiere das.

Weiter hab ich für den User Otto jeweils das login mit Key und ohne Password durch eine Modifikation der SSH Servereinstellungen festgelegt. Dazu editiere ich mit Root-Rechten die SSH-Konfigurationsdatei sshd_config im Abschnitt Match User Otto:

root@server2:/# nano /etc/ssh/sshd_config

Match User otto
     PasswordAuthentication no
     PubkeyAuthentication yes

Gehe konzentriert vor, damit Du dich respektive otto nicht aussperrst. Danach bitte den SSH-Dienst mit root Rechten neu starten:

root@server2:/# systemctl restart ssh 

Jetzt eine SSH-Verbindung aufbauen und ggf. bei ersten mal die Nachfrage bestätigen, wenn Du sicher bis das du den richtigen Server adressiert hast und der angezeigte Fingerprint (PubKey des Servers) dazu korrekt ist.

otto@server1:~$ ssh otto@mein.server-zwei.de

Last login: Thu Nov 13 03:52:57 2025 from 188.95.65.41
otto@server2:~$ ls -l
total 4
drwxr-xr-x 2 otto otto 4096 Nov 11 12:04 zweite_spielwiese
otto@server2:~$ exit
logout
Connection to mein.server-zwei.de closed.

otto@server1:~$

Das gleiche nun für otto auf server2

otto@server2:~$ ssh otto@mein.server-eins.de

Last login: Thu Nov 13 05:37:21 2025 from 188.95.65.41
otto@server1:~$ ls -l
total 4
drwxr-xr-x 2 otto otto 4096 Nov 10 21:32 erste_spielwiese
otto@server1:~$ exit
logout
Connection to mein.server-eins.de closed.

otto@server2:~$

In diesem Abschnitt haben wir also eine SSH-Schlüssel-basierte Authentifizierung eingerichtet und kurz erprobt.

zu 5. Rechner übergreifend eine Datei kopieren

Ich arbeite hier zunächst mit dem Linux Befehl, scp (Secure Copy Protocol). Damit können Dateien und Verzeichnisse über Rechnergrenzen hinweg verschlüsselt kopiert werden. Das funktioniert für Server-Client-Verbindungen als auch für Server-Server-Verbindungen.

Der grundlegende Syntax für SCP

scp [Optionen] Quelle Ziel

Und für remote Rechner zu remote Rechner sieht der prinzipielle Syntax so aus:

scp user1@rechner1:pfad/zur/datei/file.txt  user2@rechner2:/pfad/zum/ziel 

Voraussetzungen / meine Empfehlung für scp

• SSH-Zugriff

• SSH-Schlüssel-basierte Authentifizierung (ohne Passwörter),
  um die spätere Automatisierung zu erleichtern

Sicherheitshinweis: Private Schlüssel (PrivKey) ohne Password sind für eine automatisierte Anmeldung an einem fernen Rechner sehr hilfreich. Wird solch ein PrivKey gestohlen kann das natürlich extrem fatale Folgen haben. Deshalb sichere den PrivKey rechtmäßig gewissenhaft ab und sei äußerst sorgfältig.

Aufgabenstellung in diesem Beispiel
Die Datei zweite_textdatei.txt soll von Rechner mein.server-zwei.de auf den ersten Rechner mein.server-eins.de kopiert werden und zwar in das Verzeichnis /home/otto/erste_spielwiese

Machen wir uns noch mal die genaue Lage der beteiligten Verzeichnisse und der Datei klar:

Quellrechner, Quellverzeichnis Quelldatei: mein.rechnner-zwei.de /home/otto/zweite_spielwiese/zweite_textdatei.txt

Zielrechner, Zielverzeichnis: mein.rechner-eins.de /home/otto/erste_spielwiese

Daraus leitet sich der (grundstätzliche) Syntax in diesem Beispiel für folgende mögliche Eingabepunkte ab:

a) Konsole eines Clients der SSH-Zugriff auf beide ferne Server hat

scp otto@mein.server-zwei.de:/home/otto/zweite_spielwiese/zweite_textdatei.txt
otto@mein.server-eins.de:/home/otto/erste_spielwiese

b) Konsole am Server 2

scp /home/otto/zweite_spielwiese/zweite_textdatei.txt otto@mein.server-eins.de:/home/otto/erste_spielwiese

c) Konsole am Server 1

scp otto@mein.server-zwei.de:/home/otto/zweite_spielwiese/zweite_textdatei.txt /home/otto/erste_spielwiese 

Die Konsole des Server1 gibt dabei den Status der Übertragung aus:

otto@server1:~$ zweite_textdatei.txt     100%      57      32.   1KB/s   00:00

Schauen wir uns im Zielverzeichnis um, sehen wir, dass der Kopiervorgang samt Rechten erfolgreich war. Schönheitsfehler ist jedoch, dass die zweite_textdatei jetzt das Datum der Übertragung und nicht mehr das ursprüngliche Datum trägt.

otto@server1:~$ cd erste_spielwiese
otto@server1:~/erste_spielwiese$ ls -lachs
total 16K
4.0K drwxr-xr-x. 2 otto otto 4.0K Nov 13 11:48 .
4.0K drwx------. 5 otto otto 4.0K Nov 11 00:13 ..
4.0K -rw-r--r--. 1 otto otto 21 Nov 10 21:32 erste_textdatei.txt
4.0K -rw-r--r--. 1 otto otto 57 Nov 13 11:48 zweite_textdatei.txt
otto@server1:~/erste_spielwiese$

Mit der Option -p (Dateiattribute, wie Zeitstempel und Zugriffsrechte bleiben erhalten) des scp lässt sich das jedoch (bereits bei der Erstübertragung) korrigieren:

scp -p otto@mein.server-zwei.de:/home/otto/zweite_spielwiese/zweite_textdatei.txt /home/otto/erste_spielwiese 

Der scp -p Kopiervorgang und die Prüfung mit ls-l sieht an den Prompts dann zum Beispiel so aus:

otto@server2:~/zweite_spielwiese$ scp -p ~/zweite_spielwiese/zweite_textdatei.txt otto@archiv.sommer-huenxe.net:/home/otto/erste_spielwiese
zweite_textdatei.txt

zweite_textdatei.txt                             100%   57    74.6KB/s   00:00    
otto@server2:~/zweite_spielwiese$ ls-l
total 4
-rw-r--r-- 1 otto otto 57 Nov 11 12:04 zweite_textdatei.txt

Das Datum der Datei ist jetzt korrekt und im Ziel identisch mit dem Datum der Quelldatei

otto@server1:~/erste_spielwiese$ ls -l
total 8
-rw-r--r--. 1 otto otto 21 Nov 10 21:32 erste_textdatei.txt
-rw-r--r--. 1 otto otto 57 Nov 11 12:04 zweite_textdatei.txt
otto@alma-4server1:~/erste_spielwiese$

zu 6. Verzeichnisse rechnerübergreifend kopieren

Bevor wir uns dem Kopieren von Verzeichnissen mit rsync zuwenden, weise ich kurz darauf hin, dass auch einzelne Dateien mit rsync unter Beibehaltung der Datei-Attribute kopiert, respektive synchronisiert, werden können.

Der grundlegende Syntax für rsync Ist dem von scp sehr ähnlich:

rsync [Optionen] Quelle Ziel

Und für remote Rechner zu remote Rechner sieht der prinzipielle Syntax zum kopieren einer Datei so aus:

rsync -avz user@server2:/pfad/zur/datei user@server1:/pfad/zum/zielverzeichnis/

Für ganze Verzeichnisse empfiehlt sich meist das gleiche Muster, einfach mit dem Verzeichnisnamen und ggf. dem abschließenden Slash:

rsync -avz /pfad/zum/verzeichnis/ benutzer@ferner_server:/pfad/zum/ziel/

Die Option -a sorgt für den Erhalt von Rechten und Zeitstempeln, -v für die Anzeige der übertragenen Dateien und -z für Kompression während der Übertragung. Für fortgeschrittene Nutzung empfiehlt sich zusätzlich -P für Fortschrittsanzeige und unterbrochene Übertragungen.

Aber nun zur konkreten Aufgabe: Der Ordner und sein Inhalt von mein.server-zwei.de /opt/bu-gustav/temp2 soll nach mein.server-eins.de /opt/temp1 unter Beibehaltung der Rechte kopiert werden.

Quellrechner, Quellordner: mein.server-zwei.de opt/bu-gustav/temp2/
Zielrechner, Zielordner: mein.server-eins.de /opt/temp1/

Schauen wir uns mit ls-l die Ausgangssituation jeweils an, zunächst die Quelle:

otto@server2:/$ cd /opt/bu-gustav
otto@server2:/opt/bu-gustav$ ls -l
total 12
-rwxr-xr-x 1 root root 395 Nov 5 23:52 bulocal.sh
drwxr-xr-x 3 root root 4096 Nov 7 19:52 temp
drwxr-x--- 2 otto zugriff 4096 Nov 14 05:39 temp2
otto@server2:/opt/bu-gustav$ cd temp2
otto@server2:/opt/bu-gustav/temp2$ ls -l
total 12
-rw-r--r-- 1 otto otto 1234 Nov 12 10:48 readme
-rw-rw-r-- 1 root zugriff 378 Nov 14 05:39 semiarchivfile
-rw-rw-r-- 1 otto otto 64 Nov 12 10:37 semiarchivfile2
otto@server2:/opt/bu-gustav/temp2$

und jetzt das Ziel im server1 vor dem Kopiervorgang

otto@server1-1:~$ cd /opt
otto@server1:/opt$ ls -l
total 8
drwx--x--x. 4 root root 4096 Oct 4 19:34 containerd
drwxrwx---. 2 otto zugriff 4096 Nov 12 09:30 temp1
otto@server1:/opt$ cd temp1
otto@server1:/opt/temp1$ ls -l
total 0
otto@server1:/opt/temp1$

Jetzt folgt endlich der Kopiervorgang des Verzeichnisses temp2 nebst Inhalt auf server2 nach dem Ziel auf server2, Rechte und Zeitstempel bleiben erhalten

otto@server1:~$ rsync -avz otto@mein.server-zwei.de:/opt/bu-gustav/temp2 /opt/temp1
receiving incremental file list
temp2/
temp2/readme
temp2/semiarchivfile
temp2/semiarchivfile2

sent 85 bytes  received 1,135 bytes  2,440.00 bytes/sec
total size is 1,676  speedup is 1.37
otto@server1:~$

Das schauen wir uns im Detail an:

otto@server1:~$ cd /opt/temp1
otto@server1:/opt/temp1$ ls -a
. .. temp2
otto@server1:/opt/temp1$ ls -l
total 4
drwxr-x---. 2 otto zugriff 4096 Nov 14 05:39 temp2
otto@server1:/opt/temp1$ cd temp2
otto@server1:/opt/temp1/temp2$ ls -l
total 12
-rw-r--r--. 1 otto otto 1234 Nov 12 10:48 readme
-rw-rw-r--. 1 otto zugriff 378 Nov 14 05:39 semiarchivfile
-rw-rw-r--. 1 otto otto 64 Nov 12 10:37 semiarchivfile2
otto@server1:/opt/temp1/temp2$

done! alles passt!

Ende

Hinweis: Ich bevorzuge in meinen Texten aus Gründen der besseren Lesbarkeit das Generisches Maskulinum. Weibliche und andere anderweitige Geschlechtsidentitäten werden dabei ausdrücklich mit gemeint, soweit es für die Aussage erforderlich ist.

Dieser Blog verfolgt keine kommerziellen Interessen. Etwaige Werbung ist kostenfrei! #supportyourlocal