Linux-Benutzer und Gruppen verwalten

1. Warum Benutzerverwaltung über die Sicherheit eines Servers entscheidet

Ein Linux-Server, auf dem mehrere Personen dasselbe Root-Passwort teilen oder auf dem alte Konten ehemaliger Mitarbeiter noch aktiv sind, ist strukturell unsicher, egal wie gut Firewall und Patch-Level gepflegt werden. Jeder Benutzer und jede Gruppe auf einem System repräsentiert eine Berechtigungsgrenze. Wird diese Grenze unsauber gezogen, entstehen genau die Lücken, die bei einem Sicherheitsvorfall zur lateralen Bewegung durch das System genutzt werden. Eine saubere Benutzerverwaltung ist deshalb kein administratives Beiwerk, sondern eine der wirksamsten Sicherheitsmaßnahmen überhaupt.

In der Praxis zeigt sich das Problem selten am ersten Tag, sondern nach Monaten oder Jahren im Betrieb: Ein Entwickler bekommt für ein Deployment kurzfristig sudo-Rechte, die nie wieder entzogen werden. Ein Dienst läuft aus Bequemlichkeit unter dem Benutzer root, weil das anfangs schneller ging. Genau diese kleinen Abkürzungen summieren sich zu einem Server, dessen tatsächliche Berechtigungsstruktur niemand mehr vollständig überblickt. Die folgenden Abschnitte zeigen die Werkzeuge und Prinzipien, mit denen sich dieser Zustand von Anfang an vermeiden oder nachträglich systematisch bereinigen lässt.

2. useradd Grundlagen: Optionen, Defaults und Home-Verzeichnis

Das Kommando useradd ist das grundlegende Werkzeug zum Anlegen neuer Konten unter Linux, arbeitet aber ohne Zusatzoptionen sehr minimal: Ohne -m wird kein Home-Verzeichnis erstellt, ohne -s bleibt die Login-Shell oft auf einem Systemstandard stehen, der nicht zur eigentlichen Nutzung passt. Wichtige Optionen sind -m für das Home-Verzeichnis, -d für einen abweichenden Pfad, -s für die Shell, -c für einen Kommentar mit Klartextnamen und -G für zusätzliche sekundäre Gruppen direkt beim Anlegen. Die systemweiten Defaults, etwa welche Shell ohne -s gesetzt wird, stehen in /etc/default/useradd und lassen sich mit useradd -D anzeigen und anpassen.

Debian-basierte Systeme bieten zusätzlich adduser, ein interaktives Perl-Skript, das useradd mit sinnvollen Rückfragen umhüllt und automatisch ein Home-Verzeichnis samt Skeleton-Dateien aus /etc/skel anlegt. Für automatisierte Deployments über Ansible oder Shell-Skripte ist useradd trotzdem meist die bessere Wahl, weil es deterministisch ohne Interaktion läuft und auf praktisch jeder Distribution identisch funktioniert. Wichtig: Jeder neue Benutzer benötigt zwingend ein initiales Passwort oder eine deaktivierte Login-Möglichkeit, sonst bleibt das Konto in einem unklaren Zwischenzustand.

# Regulären Benutzer mit Home-Verzeichnis und Bash-Shell anlegen
useradd -m -d /home/jdoe -s /bin/bash -c "Jane Doe" jdoe

# Passwort interaktiv setzen (niemals als Klartext-Parameter übergeben)
passwd jdoe

# Benutzer direkt mit sekundären Gruppen anlegen
useradd -m -s /bin/bash -G sudo,docker jdoe

# Systemweite Defaults für neue Benutzer anzeigen
useradd -D

# Home-Verzeichnis-Vorlage anpassen, bevor neue Benutzer angelegt werden
ls -la /etc/skel/

# Neuen Benutzer ohne Login-Shell für reine Datei-Zugriffe anlegen
useradd -m -s /usr/sbin/nologin sftpuser

3. usermod und userdel: Bestehende Konten pflegen und entfernen

usermod ändert Eigenschaften eines bereits existierenden Kontos, ohne dass ein Neuanlegen nötig wäre. Die häufigsten Anwendungsfälle sind das Hinzufügen zu einer Gruppe mit usermod -aG gruppe benutzer, das Ändern der Shell mit -s und das Umbenennen mit -l. Entscheidend ist dabei die Option -a für "append": Wird sie vergessen, ersetzt usermod -G sämtliche bisherigen sekundären Gruppen durch die neu angegebene Liste, statt sie zu ergänzen. Dieser Fehler ist einer der häufigsten in der Linux-Administration und führt dazu, dass ein Benutzer unbemerkt aus wichtigen Gruppen wie docker oder sudo entfernt wird.

Zum vollständigen Entfernen eines Kontos dient userdel, standardmäßig ohne das Home-Verzeichnis zu löschen. Erst userdel -r entfernt zusätzlich Home-Verzeichnis und Mail-Spool. Vor dem Löschen lohnt sich immer eine Prüfung mit find / -user benutzername, um herrenlose Dateien außerhalb des Home-Verzeichnisses zu finden, etwa in Cron-Jobs oder Anwendungsverzeichnissen. Wer ein Konto nicht sofort löschen, aber sperren will, nutzt stattdessen usermod -L für das Sperren des Passworts oder usermod -e 1 für ein sofortiges Ablaufdatum in der Vergangenheit.

# Benutzer zu Gruppe hinzufuegen, OHNE bestehende Gruppen zu verlieren
usermod -aG docker jdoe

# FALSCH: ersetzt alle sekundären Gruppen ohne Vorwarnung
usermod -G docker jdoe

# Konto sofort sperren, ohne es zu löschen
usermod -L -e 1 jdoe

# Vor dem Löschen: herrenlose Dateien außerhalb des Home-Verzeichnisses finden
find / -xdev -user jdoe -not -path "/home/jdoe/*" 2>/dev/null

# Benutzer inklusive Home-Verzeichnis und Mail-Spool vollständig entfernen
userdel -r jdoe

# Aktuelle Gruppenmitgliedschaften eines Benutzers prüfen
id jdoe

4. Gruppen mit groupadd, groupmod und gpasswd verwalten

Gruppen fassen mehrere Benutzer zu einer gemeinsamen Berechtigungseinheit zusammen und sind das zentrale Werkzeug, um Dateizugriffe zu steuern, ohne für jeden Einzelfall eine ACL zu pflegen. groupadd deploy legt eine neue Gruppe an, groupmod -n neuername altname benennt sie um, groupdel entfernt sie wieder, sofern kein Benutzer mehr diese Gruppe als primäre Gruppe nutzt. Jeder Benutzer hat genau eine primäre Gruppe, meist eine gleichnamige Gruppe, die beim Anlegen automatisch entsteht, aber beliebig viele sekundäre Gruppen, über die zusätzliche Rechte gewährt werden.

Für gezieltes Hinzufügen und Entfernen einzelner Mitglieder ohne die restliche Konfiguration zu berühren, eignet sich gpasswd -a benutzer gruppe zum Hinzufügen und gpasswd -d benutzer gruppe zum Entfernen, funktional äquivalent zu usermod -aG, aber semantisch klarer, weil es die Gruppe statt den Benutzer in den Mittelpunkt stellt. Für Serverumgebungen mit klar getrennten Verantwortlichkeiten, etwa deploy, backup und monitoring, ersetzt eine durchdachte Gruppenstruktur oft mehrere individuelle sudo-Regeln durch eine einzige Gruppenregel.

5. System-User vs. reguläre Benutzer: UID- und GID-Bereiche

Linux unterscheidet zwischen Systembenutzern und regulären Benutzern anhand der numerischen User-ID, nicht anhand eines expliziten Flags. Auf den meisten Distributionen sind UIDs von 0 bis 999 für Systembenutzer und Dienste reserviert, ab UID 1000 beginnen reguläre, interaktive Benutzerkonten. Der genaue Schwellenwert steht in /etc/login.defs unter UID_MIN und UID_MAX beziehungsweise SYS_UID_MIN und SYS_UID_MAX und kann distributionsabhängig leicht variieren, RHEL-basierte Systeme setzen die Grenze historisch bei 200 statt 1000.

Systembenutzer wie www-data, mysql oder redis erhalten mit der Option useradd -r automatisch eine UID aus diesem reservierten Bereich, meist ohne eigenes Home-Verzeichnis und ohne interaktive Login-Shell. Diese Trennung ist mehr als Kosmetik: Backup-Skripte, Monitoring-Tools und Security-Scanner verlassen sich auf die UID-Grenze, um zwischen echten Personen-Konten und technischen Dienstkonten zu unterscheiden. Ein Systemdienst mit UID über 1000 verwirrt diese Automatisierungen und erschwert spätere Audits erheblich.

# Ansible Playbook: dedizierten Systembenutzer je Anwendung provisionieren
- name: Application service users provisionieren
  hosts: webservers
  become: true
  tasks:
    - name: Systemgruppe für PHP-FPM Pool anlegen
      ansible.builtin.group:
        name: app-shop
        system: true
        state: present

    - name: Dedizierten Systembenutzer ohne Login-Shell anlegen
      ansible.builtin.user:
        name: app-shop
        group: app-shop
        system: true
        shell: /usr/sbin/nologin
        home: /var/www/shop
        create_home: false
        state: present

    - name: Anwendungsverzeichnis dem dedizierten Benutzer zuweisen
      ansible.builtin.file:
        path: /var/www/shop
        owner: app-shop
        group: app-shop
        mode: "0750"
        recurse: true

6. Das Prinzip des dedizierten unprivilegierten Benutzers pro Anwendung

Der Webserver läuft als www-data, MySQL als mysql, Redis als redis: Dieses Muster ist kein Zufall, sondern ein zentrales Sicherheitsprinzip. Jede Anwendung sollte unter einem eigenen, unprivilegierten Benutzer laufen, der ausschließlich auf die Dateien und Ressourcen zugreifen kann, die diese eine Anwendung tatsächlich benötigt. Wird ein PHP-FPM-Pool über eine Schwachstelle kompromittiert, begrenzt der dedizierte Benutzer den Schaden auf genau diesen Anwendungsbereich, statt dem Angreifer automatisch Zugriff auf alle anderen Dienste desselben Servers zu geben.

Besonders wichtig wird dieses Prinzip bei mehreren Anwendungen auf demselben Server, etwa mehreren Magento-Shops mit eigenen PHP-FPM-Pools. Läuft jeder Shop unter demselben www-data-Benutzer, kann ein kompromittierter Shop auf die Dateien aller anderen Shops zugreifen, weil die Dateisystemberechtigungen keine Trennung vorsehen. Die Lösung: pro Anwendung ein eigener Systembenutzer, ein eigener PHP-FPM-Pool mit passendem user- und group-Eintrag, und Dateiberechtigungen, die nur genau diesem Benutzer und der zugehörigen Gruppe Schreibzugriff erlauben. Der zusätzliche Verwaltungsaufwand ist gering im Vergleich zum Risiko einer gemeinsam genutzten Identität.

7. sudo und granulare Rechtevergabe statt gemeinsamer Root-Zugänge

Ein geteiltes Root-Passwort für mehrere Administratoren ist aus Sicherheits- und Nachvollziehbarkeitssicht problematisch: Es gibt keine individuelle Zuordnung, wer welche Aktion ausgeführt hat, und beim Ausscheiden eines Teammitglieds muss das gesamte Passwort geändert werden. sudo löst beide Probleme, indem jeder Administrator mit seinem eigenen Konto arbeitet und Root-Rechte nur für konkret erlaubte Befehle temporär erhält. Jede Aktion landet protokolliert in /var/log/auth.log oder je nach Distribution im journal, inklusive Benutzername und ausgeführtem Befehl.

Statt Benutzer pauschal in die Gruppe sudo oder wheel aufzunehmen, erlauben granulare Regeln in /etc/sudoers.d/ nur genau die Befehle, die für eine Rolle tatsächlich notwendig sind. Ein Deployment-Konto braucht meist nur Rechte für systemctl restart php8.4-fpm und einige gezielte Befehle, nicht für uneingeschränkten Root-Zugriff. Die Bearbeitung erfolgt ausschließlich über visudo, das die Syntax vor dem Speichern prüft und ein defektes sudoers-File verhindert, das sonst jeden sudo-Zugriff auf dem Server blockieren würde.

8. Passwort-Richtlinien, Account-Sperren und chage

Passwort-Richtlinien greifen erst dann konsequent, wenn sie technisch erzwungen werden, statt nur in einer Dokumentation zu stehen. Die Datei /etc/login.defs definiert systemweite Standardwerte für die Passwortalterung, etwa PASS_MAX_DAYS für die maximale Gültigkeitsdauer und PASS_MIN_DAYS, um zu häufiges Zurückwechseln auf ein altes Passwort zu verhindern. Diese Werte gelten allerdings nur für neu angelegte Konten, bestehende Konten müssen individuell mit chage angepasst werden.

chage -l benutzer zeigt die aktuelle Passwort-Historie eines Kontos, inklusive letztem Änderungsdatum und Ablaufdatum. chage -M 90 benutzer erzwingt ein Passwortwechsel-Intervall von 90 Tagen, chage -E 2026-12-31 benutzer setzt ein hartes Ablaufdatum für temporäre Konten wie Praktikanten- oder Freelancer-Zugänge. Für die Komplexität selbst sorgt das PAM-Modul pam_pwquality, konfiguriert in /etc/security/pwquality.conf, das Mindestlänge, Zeichenklassen und den Abgleich gegen Wörterbuch-Listen durchsetzt, bevor ein neues Passwort überhaupt akzeptiert wird.

# /etc/login.defs (Auszug): Passwort-Alterung systemweit konfigurieren
PASS_MAX_DAYS   90
PASS_MIN_DAYS   7
PASS_WARN_AGE   14

# UID/GID-Grenzen für reguläre Benutzer
UID_MIN         1000
UID_MAX         60000
SYS_UID_MIN     100
SYS_UID_MAX     999

GID_MIN         1000
GID_MAX         60000
SYS_GID_MIN     100
SYS_GID_MAX     999

# Verschlüsselungsverfahren für neue Passwort-Hashes
ENCRYPT_METHOD  SHA512

9. Bestehende Benutzer und Gruppen auditieren und bereinigen

Auf produktiv gewachsenen Servern sammeln sich über Jahre Konten an, deren Existenzberechtigung niemand mehr erklären kann: ehemalige Mitarbeiter, Testkonten aus einem Migrationsprojekt, Dienste, die längst abgeschaltet wurden. Ein regelmäßiges Audit beginnt mit einem vollständigen Blick auf /etc/passwd und /etc/group, gefiltert nach Konten mit UID über 1000, die eine interaktive Shell besitzen. lastlog zeigt zusätzlich, welche Konten sich seit wann nicht mehr angemeldet haben, ein starkes Indiz für ein verwaistes Konto.

Ebenso wichtig ist die Prüfung, welche Konten Mitglied privilegierter Gruppen wie sudo, wheel oder docker sind, da Zugriff auf den Docker-Daemon faktisch Root-Rechten entspricht. getent group sudo listet alle Mitglieder einer Gruppe direkt, ohne die Datei manuell zu durchsuchen. Ein einfaches, wiederholbares Audit-Skript, das diese Prüfungen automatisiert und die Ergebnisse strukturiert ausgibt, verwandelt eine gelegentliche manuelle Sichtung in einen verlässlichen, wiederholbaren Prozess, der auch nach Monaten dieselben Kriterien anwendet.

{
  "audit_date": "2026-07-12",
  "host": "shop-prod-01",
  "findings": [
    {
      "user": "ex-praktikant",
      "uid": 1042,
      "shell": "/bin/bash",
      "last_login": "2025-11-03",
      "sudo_member": false,
      "recommendation": "Konto sperren und nach Rücksprache löschen"
    },
    {
      "user": "deploy-old",
      "uid": 1015,
      "shell": "/bin/bash",
      "last_login": "2024-06-12",
      "sudo_member": true,
      "recommendation": "Sofort aus sudo-Gruppe entfernen, danach sperren"
    },
    {
      "user": "app-shop",
      "uid": 998,
      "shell": "/usr/sbin/nologin",
      "last_login": "never",
      "sudo_member": false,
      "recommendation": "Kein Handlungsbedarf, dedizierter Systembenutzer"
    }
  ]
}

Die Ergebnisse eines solchen Audits lassen sich in wiederkehrende Bereinigungsmuster einteilen. Die folgende Tabelle stellt riskante Alltagspraktiken den empfohlenen Alternativen gegenüber, die sich sowohl beim Neuanlegen als auch bei der nachträglichen Bereinigung bestehender Server anwenden lassen.

Diese fünf Muster decken den Großteil der Sicherheitsprobleme ab, die bei einem Server-Audit typischerweise auffallen. Wer sie konsequent umsetzt, reduziert nicht nur die Angriffsfläche, sondern schafft auch die Grundlage für nachvollziehbare Compliance-Nachweise, falls ein Kunde oder Auditor Einsicht in die Zugriffsstruktur verlangt.

10. Zusammenfassung

Eine saubere Linux-Benutzer- und Gruppenverwaltung beginnt beim korrekten Einsatz von useradd, usermod und groupadd und endet bei einem wiederkehrenden Audit-Prozess, der verwaiste Konten und übermäßige Rechte aufdeckt. Systembenutzer im UID-Bereich unter 1000 grenzen technische Dienstkonten sauber von regulären Personen-Konten ab. Das Prinzip des dedizierten, unprivilegierten Benutzers pro Anwendung, wie es www-data oder mysql vorleben, begrenzt den Schaden einer kompromittierten Anwendung auf genau diese eine Anwendung.

Individuelle sudo-Regeln statt geteilter Root-Passwörter schaffen Nachvollziehbarkeit für jede administrative Aktion. Passwort-Richtlinien über chage und PAM sorgen dafür, dass Konten nicht unbegrenzt gültig bleiben. Der größte Hebel liegt jedoch nicht in einem einzelnen Werkzeug, sondern in der Regelmäßigkeit: Ein Server, der einmal im Quartal systematisch auf verwaiste Konten und übermäßige Gruppenrechte geprüft wird, bleibt über Jahre hinweg beherrschbar, während ein nie geprüfter Server irgendwann niemand mehr vollständig erklären kann.

11. FAQ: Linux-Benutzer und Gruppen verwalten