Identitäten und Zugriff: Gruppen, sudo und SSH

„Der soll nur den einen Dienst neu starten dürfen“ — und eine Stunde später hat er Vollzugriff auf den Server, weil die Berechtigung über eine Gruppe vergeben wurde. Dieses Modul zeigt dir, wie Zugriff auf einem Linux-Server tatsächlich zustande kommt: wer du bist, zu wem du gehörst und was du im Einzelnen tun darfst. Du lernst, eine Berechtigung so eng zu schneiden wie die Aufgabe, zwei Fallen zu erkennen, die eine enge Regel wieder zu Vollzugriff machen, und einen Notzugang so anzulegen, dass er im Ernstfall trägt.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-03

„Zugriff“ ist keine einzelne Frage, sondern drei

Wenn jemand auf einem Linux-Server etwas tun darf, sind dafür drei Dinge zusammengekommen: Er konnte sich anmelden, das System weiß wer er ist, und für die konkrete Aktion hat er ein Privileg. Wer die drei zusammenwirft, vergibt fast immer zu viel.

Der häufigste Fehler im Alltag sieht harmlos aus: Jemand soll einen Dienst neu starten dürfen, und man nimmt ihn dafür in eine Gruppe auf, die alles darf. Die Aufgabe ist erledigt, die Berechtigung passt aber nicht mehr zur Aufgabe — und niemand merkt es, bis etwas passiert.

Vier Größen, die getrennt gehören

Anmeldeweg: Wie jemand überhaupt auf das System kommt — bei Servern fast immer SSH.
Identität: Als wer er dort ankommt. Ein eigenes Konto pro Person, kein geteiltes.
Gruppe: Womit Rechte an mehrere Konten gleichzeitig vergeben werden. Grobkörnig — eine Gruppe kennt keine einzelne Aktion.
Privileg: Die eine erlaubte Aktion mit erhöhten Rechten. Hier gehört die Aufgabe hinein, nicht in die Gruppe.

Was ein Konto auf einem Linux-System eigentlich ist

Ein Konto ist für den Kernel keine Person, sondern eine Zahl: die Benutzer-ID. Namen gibt es nur für Menschen; die Rechteprüfung passiert über die Zahl. Genauso hat jede Gruppe eine Gruppen-ID.

UID 0 — Die Benutzer-ID des Superusers. Nicht der Name root macht ein Konto allmächtig, sondern diese Zahl — ein zweites Konto mit UID 0 hat exakt dieselben Rechte, auch wenn es anders heißt.

Die Zuordnung von Namen zu Zahlen steht in /etc/passwd. Diese Datei ist für alle lesbar und enthält deshalb keine Passwörter — die liegen in /etc/shadow, die nur privilegiert lesbar ist. Gruppen und ihre Mitglieder stehen in /etc/group.

In /etc/passwd steht pro Konto außerdem die Login-Shell. Das ist der unauffälligste und wirksamste Schalter im Kontenmodell: Ein Konto, dessen Shell auf ein Programm zeigt, das jede Anmeldung ablehnt, kann von einem Dienst benutzt werden, aber niemand kann sich damit interaktiv anmelden. Genau so gehören Dienstkonten angelegt.

Menschliches Konto: Gehört einer Person, hat eine Anmelde-Shell, meldet sich per SSH an, holt sich Privilegien einzeln über sudo.
Dienstkonto: Gehört einem Programm, hat keine Anmelde-Shell, meldet sich nie interaktiv an, besitzt genau die Dateien, die der Dienst braucht.

Warum die Trennung wichtig istEin Dienst, der als eigenes Konto läuft, kann bei einer Schwachstelle nur das anfassen, was diesem Konto gehört. Läuft derselbe Dienst als root, ist jede Schwachstelle in ihm sofort eine Schwachstelle des ganzen Systems.

Gruppen: bequem, grobkörnig und leicht falsch bedient

Jedes Konto hat genau eine primäre Gruppe und beliebig viele zusätzliche. Die primäre Gruppe bekommt jede neu angelegte Datei des Kontos; die zusätzlichen dienen dazu, Rechte an mehrere Personen gleichzeitig zu vergeben — etwa Lesezugriff auf ein Verzeichnis.

Damit ist auch die Grenze klar: Eine Gruppe kann sagen „diese Leute dürfen auf diese Dateien zugreifen“. Sie kann nicht sagen „diese Leute dürfen genau diesen einen Dienst neu starten“. Sobald die Aufgabe eine Aktion ist und kein Dateizugriff, ist die Gruppe das falsche Werkzeug.

Die teuerste Tippfehler-Falle im KontenmodellBeim Ändern der Gruppenmitgliedschaft ersetzt die Option -G die Liste der zusätzlichen Gruppen vollständig. Ist ein Konto Mitglied einer Gruppe, die nicht mit aufgezählt wird, wird es daraus entfernt. Nur zusammen mit -a (für „append“) wird die genannte Gruppe hinzugefügt. Wer das -a vergisst, nimmt einem Konto in einem Zug alle anderen Mitgliedschaften weg — und merkt es erst, wenn irgendwo ein Zugriff fehlschlägt.

Zwei Befehle beantworten im Alltag die Ausgangsfrage. id zeigt dein Konto, deine primäre und alle zusätzlichen Gruppen — und zwar mit Zahlen und Namen. Und eine geänderte Mitgliedschaft wirkt nicht sofort: Sie gilt für die nächste Anmeldung, weil die Gruppen einer laufenden Sitzung beim Anmelden festgelegt wurden.

sudo: ein Befehl, nicht ein Zustand

sudo — Ein Programm, das einen einzelnen Befehl mit den Rechten eines anderen Benutzers ausführt — meist root. Wer was darf, steht in Regeldateien; sudo führt nichts aus, was dort nicht erlaubt ist.

Der Unterschied zu „root werden“ ist wichtig. sudo <befehl> führt genau diesen einen Befehl privilegiert aus und schreibt ihn ins Protokoll. Eine Root-Shell dagegen ist ein Zustand: Alles, was danach getippt wird, läuft privilegiert, und im Protokoll steht nur, dass jemand eine Shell geöffnet hat — nicht, was er darin getan hat.

sudo -l zeigt, welche Befehle du über sudo ausführen darfst, Zeile für Zeile, so wie die Regel wirklich formuliert ist. Das ist auch das ehrlichste Prüfwerkzeug für eine Regel, die du gerade geschrieben hast: Was dort nicht auftaucht, funktioniert nicht; was dort breiter aussteht als gedacht, ist breiter.

MerksatzEine Gruppe beantwortet „zu wem gehörst du“. Eine sudo-Regel beantwortet „was darfst du tun“. Wer eine Aufgabe über die Gruppe löst, vergibt die Aufgabe und alles andere gleich mit.

Die Regel so eng schneiden wie die Aufgabe

Regeln gehören nicht in die Hauptdatei, sondern als eigene Datei nach /etc/sudoers.d/. Das hält Änderungen nachvollziehbar und ein Fehler betrifft nur eine Datei. Bearbeitet wird sie mit visudo, nie mit einem normalen Editor: visudo sperrt die Datei gegen gleichzeitige Änderungen, prüft die Syntax und verweigert das Speichern, wenn sie fehlerhaft ist. visudo -c prüft eine bestehende Konfiguration, ohne etwas zu ändern.

Warum das kein Formalismus istEine kaputte sudo-Konfiguration wird von sudo komplett abgelehnt. Dann darf niemand mehr etwas über sudo tun — auf einem Server ohne zweiten Zugang ist das ein Ausschluss aus dem eigenen System.

In der Regel selbst gehört jeder Befehl mit vollem Pfad. Steht dort nur systemctl, entscheidet die Suchreihenfolge des aufrufenden Benutzers, welches Programm tatsächlich startet — und die kann er beeinflussen. Der volle Pfad nagelt fest, was gemeint ist.

Ein Dienst-Neustart für das On-Call-Team

Szenario

Das Team soll nginx neu starten und dessen Status lesen dürfen. Keine Shell als root, keine Paketverwaltung, keine anderen Dienste.

Anforderungen

Jede Person mit eigenem Konto, damit jede Aktion zuordenbar bleibt
Nur die beiden benötigten Aktionen, nichts darüber hinaus
Prüfbar, bevor sich jemand darauf verlässt

Schritte

Eine Gruppe für das Team anlegen und die individuellen Konten hineinnehmen — mit der Append-Option, damit bestehende Mitgliedschaften erhalten bleiben.
Eine Regeldatei unter /etc/sudoers.d/ anlegen, die dieser Gruppe genau die beiden Kommandos erlaubt — jeweils mit vollem Pfad und dem konkreten Dienstnamen als Argument.
Mit visudo bearbeiten, damit ein Syntaxfehler gar nicht erst gespeichert werden kann.
Neu anmelden, damit die Gruppenmitgliedschaft in der Sitzung wirksam ist.
Mit sudo -l aus einem Konto des Teams gegenprüfen, dass genau diese zwei Zeilen erscheinen — und nichts sonst.

Merksatz: Die Gruppe sammelt Personen, die Regel vergibt Rechte. Was sudo -l anzeigt, ist die Wahrheit — nicht das, was du zu schreiben glaubtest.

Zwei Wege, auf denen eine enge Regel doch Root verschenkt

Eine Regel kann eng aussehen und es trotzdem nicht sein. Der erste Weg ist der Platzhalter. sudo vergleicht Kommandozeilen-Argumente mit denselben Mustern wie die Shell — ein * steht für beliebigen Text. Eine Regel, die systemctl restart * erlaubt, erlaubt damit nicht „einen Dienst“, sondern jeden Dienst; und je nach Muster auch Argumente, an die niemand gedacht hat.

Der zweite Weg sind Programme, die selbst Befehle starten können. Fast jeder Editor und die meisten Pager können aus sich heraus eine Shell öffnen. Wer einen Editor über sudo erlauben darf, hat damit eine Root-Shell erlaubt — unabhängig davon, welche Datei in der Regel steht. Das sudoers-Handbuch nennt genau das als Risiko und rät, Benutzern keine Kommandos zu geben, mit denen sie beliebige Befehle ausführen können.

sudoedit — Der vorgesehene Weg, eine geschützte Datei bearbeiten zu lassen: Der Editor läuft mit den normalen Rechten der Person, nur das Zurückschreiben der Datei passiert privilegiert. Laut sudoers-Handbuch die bessere Lösung, als einen Editor über sudo zu erlauben.

Dasselbe Muster gilt für vieles andere: ein Paketmanager darf beliebige Skripte ausführen, ein Archivierer kann Dateien überall hinschreiben, ein Interpreter führt ohnehin alles aus. Die Frage bei jeder Regel lautet deshalb nicht „welche Datei steht da“, sondern „was kann dieses Programm alles tun, wenn es als root läuft“.

Kurzcheck

Eine Regel erlaubt dem Team sudo /usr/bin/vi /etc/nginx/nginx.conf — nur diese eine Datei. Wo ist das Problem?

Der Editor läuft als root und kann aus sich heraus eine Shell öffnen — damit ist jeder Befehl als root möglich, nicht nur diese Datei.
Der Pfad /etc/nginx/nginx.conf müsste in Anführungszeichen stehen, sonst wertet sudo ihn als Muster aus.
vi müsste ohne vollen Pfad geschrieben werden, damit sudo die richtige Programmversion findet.

Treffer. Genau. Die Regel begrenzt die Datei, nicht das Programm. Für diesen Fall gibt es sudoedit: der Editor läuft dann als du selbst, nur das Speichern erfolgt privilegiert.

SSH: der Weg ins System

Bei einem Server entscheidet SSH über den Anmeldeweg. Drei Einstellungen in der Konfiguration des SSH-Dienstes tragen den größten Teil der Wirkung: ob sich root direkt anmelden darf (PermitRootLogin), ob Passwörter überhaupt erlaubt sind (PasswordAuthentication) und wer sich anmelden darf (AllowGroups).

Das Zielbild dahinter ist dasselbe wie bei sudo: getrennte Ebenen. Man meldet sich als man selbst an — mit einem Schlüssel statt einem Passwort — und holt sich Root-Rechte danach für die einzelne Aktion. Eine direkte Root-Anmeldung führt beide Schritte zusammen und macht sie unzuordenbar.

Schlüsselpaar — Zwei zusammengehörige Dateien: Der private Schlüssel bleibt auf deinem Rechner und verlässt ihn nie. Der öffentliche darf überall stehen — auf dem Server landet er in der Liste der zugelassenen Schlüssel des jeweiligen Kontos.

Warum das sicherer ist als ein Passwort: Der private Schlüssel wird bei der Anmeldung nicht übertragen. Der Server stellt eine Aufgabe, die nur mit dem privaten Schlüssel lösbar ist; über die Leitung geht nur die Lösung. Ein mitgelesenes Passwort ist sofort verwendbar — eine mitgelesene Lösung ist es nicht.

Warum ein korrekter Schlüssel trotzdem abgelehnt wirdDer SSH-Dienst prüft nicht nur den Schlüssel, sondern auch die Rechte auf dem Weg dorthin. Sind die Schlüsseldatei, das .ssh-Verzeichnis oder das Home-Verzeichnis für andere Benutzer beschreibbar, könnte ein Fremder die Liste der zugelassenen Schlüssel austauschen. In diesem Fall verweigert der Dienst die Nutzung der Datei. Das ist die häufigste Ursache für „mein Schlüssel funktioniert nicht“ — und die Lösung ist, die Rechte zu verengen, nicht die Prüfung abzuschalten.

Vor dem Neustart prüfenEine fehlerhafte SSH-Konfiguration sperrt dich beim nächsten Verbindungsversuch aus. Der SSH-Dienst kann seine Konfiguration deshalb im Testmodus prüfen, bevor sie aktiv wird — und eine zweite, noch offene Sitzung ist der billigste Rückweg, den es gibt.

Was nach dem Zugriff übrig bleibt: der Nachweis

Berechtigungen haben eine zweite Aufgabe neben dem Ermöglichen: Sie sollen im Nachhinein beantworten können, wer was getan hat. Diese Eigenschaft geht leiser verloren als die erste, weil nichts kaputtgeht — es fehlt nur später die Antwort.

sudo protokolliert jeden Aufruf: welches Konto, welcher Befehl, mit welchen Argumenten, von welchem Terminal. Damit ist eine einzelne privilegierte Aktion nachvollziehbar. Genau diese Eigenschaft verliert man mit einer Root-Shell — im Protokoll steht dann eine Zeile („X hat eine Shell geöffnet“), und alles Weitere ist unsichtbar.

Einzelbefehl über sudo: Jede Aktion steht mit Konto, Kommando und Zeit im Protokoll. Zuordenbar, auch Monate später.
Root-Shell: Eine Protokollzeile für den Einstieg, danach nichts mehr. Was darin passiert ist, lässt sich nur noch aus Nebenwirkungen erschließen.
Geteiltes Konto: Das Protokoll ist vollständig — und wertlos, weil es auf eine Identität zeigt, hinter der mehrere Menschen stehen.

Daraus folgt eine unbequeme Regel: Bequemlichkeit und Nachweisbarkeit stehen hier gegeneinander. Eine Root-Shell ist im Incident schneller, kostet aber genau die Information, die man in der Nachbereitung braucht. Der Kompromiss besteht nicht darin, auf sie zu verzichten, sondern darin, sie zur bewussten Ausnahme zu machen statt zur Gewohnheit.

Für automatisierte Zugriffe gibt es eine elegantere Lösung als ein weiteres Konto mit weiten Rechten: Ein hinterlegter öffentlicher Schlüssel lässt sich einschränken. In der Liste der zugelassenen Schlüssel kann vor dem Schlüssel stehen, von welchen Adressen er benutzt werden darf und welcher einzelne Befehl bei einer Anmeldung mit ihm ausgeführt wird — unabhängig davon, was der Aufrufer schickt.

Warum das der bessere Weg istEin Automatisierungskonto mit einem uneingeschränkten Schlüssel darf alles, was das Konto darf. Derselbe Schlüssel mit einer festen Befehlsbindung darf genau eine Sache — und ein gestohlener Schlüssel ist damit deutlich weniger wert. Der Preis: Jede Änderung am Ablauf verlangt eine Änderung an der Schlüsselzeile.

Der Notzugang, der im Ernstfall wirklich trägt

Wenn der zentrale Anmeldedienst ausfällt, funktioniert der normale Weg nicht mehr. Dafür gibt es den Notzugang — und der ist nur dann etwas wert, wenn er vorher getestet wurde. Ein Notzugang, den niemand je abgerufen hat, ist im Incident eine Vermutung.

Er ist außerdem das Gegenteil des Alltagszugangs: Der Alltag soll eng und bequem sein, der Notzugang breit und unbequem. Genau deshalb braucht er eine Freigabe vor der Nutzung, einen geschützten Aufbewahrungsort, eine Protokollierung und eine Nachbereitung — sonst wird aus der Ausnahme still der neue Normalweg.

Die Nachbereitung ist der Teil, der am häufigsten ausfällt. Nach der Nutzung gehört geprüft, was mit dem Zugang getan wurde, ob das Geheimnis gewechselt werden muss und ob der Weg überhaupt so funktioniert hat wie beschrieben. Ohne diesen Schritt weiß beim nächsten Mal niemand, ob der Notzugang noch trägt.

Der PreisDiese Pflege kostet Zeit für etwas, das im Idealfall nie gebraucht wird. Wer sie einspart, spart genau an dem Tag, an dem alles andere schon kaputt ist.

Die Reihenfolge, in der du eine Berechtigung baust

Aufgabe benennen: welche Aktion genau, auf welchem Objekt→Identität klären: eigenes Konto, keine geteilte Anmeldung→Regel so eng schneiden wie die Aufgabe und mit visudo speichern→Mit sudo -l gegenprüfen, was wirklich erlaubt ist→Ausnahmeweg getrennt halten, schützen und testen

Jede Stufe beantwortet eine eigene Frage. Wer eine überspringt, beantwortet sie trotzdem — nur unbewusst und meistens großzügiger als nötig.

Was du mitnehmen solltestZugehörigkeit ist keine Erlaubnis. Eine Erlaubnis ist so groß wie ihr großzügigster Bestandteil, nicht wie ihre Absicht. Und ein Ausnahmeweg, der nie geprobt wurde, ist kein Weg, sondern eine Hoffnung.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität9 Primärquellen · zuletzt geprüft: 2026-09-03