Sudo auf Debian installieren und nutzen

Sudo führt einzelne Befehle mit Root-Rechten aus, ohne dass du dich als Root anmelden musst. Das bringt zwei Dinge, die eine dauerhaft offene Root-Shell nicht bietet: Jeder Aufruf landet im Systemprotokoll, und die Rechte lassen sich pro Konto und pro Befehl begrenzen.

Diese Anleitung zeigt, wie du Sudo auf Debian installierst, ein Konto dafür freischaltest und die Konfiguration änderst, ohne dich auszusperren. Die Angaben beziehen sich auf Debian 12 („Bookworm“) mit sudo 1.9.13p3 und Debian 13 („Trixie“, erschienen am 9. August 2025) mit sudo 1.9.16p2, nachzusehen in der Debian-Paketverfolgung.

Voraussetzungen für Sudo auf Debian

Ob Sudo auf einem Debian-System überhaupt vorhanden ist, entscheidet sich schon bei der Installation. Der Installer fragt nach einem Root-Passwort, und die Antwort darauf legt zwei verschiedene Systeme an.

Feld leer gelassen: Das Root-Konto wird gesperrt, das Paket sudo kommt mit, und der zuerst angelegte Benutzer darf es verwenden. Das Debian-Installationshandbuch schreibt dazu: „Wenn Sie hier kein Passwort für den ‚root‘-Benutzer festlegen, führt das zur Deaktivierung dieses Kontos, aber später wird das sudo-Paket installiert, damit administrative Aufgaben auf dem neuen System durchgeführt werden können.“

Root-Passwort vergeben: Root bleibt normal nutzbar, dafür fehlt Sudo unter Umständen ganz, und jedes weitere Konto entsteht ohne Sudo-Rechte. Für diesen zweiten Fall ist der Rest der Anleitung geschrieben.

Ob das Paket bereits da ist, beantwortet ein Aufruf ohne jede Nebenwirkung:

sudo --version | head -n 1

Antwortet die Shell mit sudo: command not found, fehlt das Paket. Die Installation braucht dann eine Root-Shell, denn das Werkzeug, das sie sonst besorgen würde, ist ja gerade das fehlende:

su -

Ist auch das Root-Passwort unbekannt, führt kein Weg an einem Rettungssystem oder dem Einzelbenutzermodus vorbei. Alles Weitere setzt voraus, dass eine Root-Shell erreichbar ist.

Sudo-Paket installieren und ein Konto freischalten

Drei Schritte als root genügen.

1. Paketquellen aktualisieren:

apt update

2. Sudo installieren:

apt install sudo -y

3. Das Konto in die Gruppe sudo aufnehmen. Debians Standardkonfiguration räumt jedem Mitglied dieser Gruppe volle Rechte ein. Ersetze Benutzername durch den Namen des Kontos:

usermod -aG sudo Benutzername

Das -a ist dabei kein Schmuck. Ohne dieses Flag ersetzt usermod -G die bestehenden Nebengruppen, statt eine hinzuzufügen; die Handbuchseite sagt das ausdrücklich. Ein vergessenes -a wirft ein Konto also aus allen Gruppen, in denen es vorher stand. Debians eigenes Werkzeug adduser kennt dieses Risiko nicht, weil es die Gruppe als zweites Argument nimmt:

adduser user sudo

Die neue Gruppe wirkt erst nach einer neuen Anmeldung

An dieser Stelle scheitert die Einrichtung am häufigsten: Das Konto steht in der Gruppe, sudo verweigert trotzdem den Dienst. Das liegt nicht an Sudo. Die Nebengruppen eines Prozesses stehen ab dem Anmelden fest, Kindprozesse erben sie lediglich (credentials(7)). Eine Shell, die schon offen war, erfährt von der neuen Gruppe nichts mehr.

Abmelden und neu anmelden löst das. Für einen schnellen Test genügt eine frische Login-Shell, etwa über su - oder eine neue SSH-Sitzung. newgrp sudo setzt die Gruppe ebenfalls, aber nur für die aufrufende Shell (newgrp(1)).

su - Benutzername
sudo -v

sudo -v beantwortet nur, ob der Aufruf grundsätzlich zulässig ist, und verlängert dabei den Zwischenspeicher für die Passworteingabe. Der liegt laut sudoers(5) voreingestellt bei 15 Minuten, sudo -k verwirft ihn sofort. Was genau erlaubt ist, sagt erst sudo -l:

sudo -l

Die Ausgabe listet jede Regel auf, die für das aufrufende Konto auf diesem Rechner gilt (sudo(8)). Steht dort nichts, ist entweder die Gruppe noch nicht wirksam oder es gibt schlicht keinen passenden Eintrag. id zeigt, welche Gruppen die laufende Sitzung tatsächlich mitbringt.

Sudo-Rechte gezielt vergeben: die sudoers-Datei

Die Gruppe sudo kennt nur zwei Zustände: alles oder nichts. Wer einem Konto genau einen Befehl erlauben will und sonst keinen, kommt an der Konfiguration nicht vorbei.

Bearbeitet wird sie nie mit einem gewöhnlichen Editor. visudo sperrt die Datei gegen gleichzeitige Änderungen und prüft sie vor dem Speichern auf Syntaxfehler (visudo(8)). Ein Tippfehler in /etc/sudoers macht sonst jeden Sudo-Aufruf auf dem System unbrauchbar, auch den, mit dem der Fehler zu beheben wäre.

sudo visudo

Eine Zeile für ein einzelnes Konto sieht so aus:

Benutzername ALL=(ALL:ALL) ALL

Die Felder bedeuten der Reihe nach: das Konto, die Rechner, für die die Regel gilt, dann in Klammern die Benutzer und Gruppen, in deren Namen gehandelt werden darf, und zuletzt die erlaubten Befehle. Vier ALL gewähren also genau das, was auch die Gruppenmitgliedschaft gibt.

Eigene Regeln gehören trotzdem nicht in /etc/sudoers selbst, sondern in eine eigene Datei daneben. sudoers(5) sieht dafür die Anweisung @includedir /etc/sudoers.d vor: Sudo liest dann jede Datei in diesem Verzeichnis, überspringt aber Namen mit einem Punkt oder einer Tilde, damit Sicherungskopien des Paketmanagers keine Regeln aktivieren. Der Dateiname darf deshalb keine Endung tragen. visudo bearbeitet solche Dateien nur, wenn man sie ausdrücklich benennt:

sudo visudo -f /etc/sudoers.d/wartung

Inhalt zum Beispiel:

wartung ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

Damit darf das Konto wartung diesen einen Befehl ausführen, und zwar ohne Passwortabfrage. NOPASSWD ist bequem und kostet zugleich den Schutz, für den Sudo da ist: Wer die Sitzung übernimmt, hat den Befehl ohne weitere Hürde. Für Skripte und Cronjobs ist so ein Eintrag sinnvoll, für ein Konto, an dem ein Mensch sitzt, selten.

Ob die gesamte Konfiguration syntaktisch in Ordnung ist, prüft ein Aufruf, der nichts verändert:

sudo visudo -c

Sudo schreibt jeden Aufruf mit, den erfolgreichen wie den abgelehnten. Wo das landet, hat sich geändert: Seit Debian 12 gehört rsyslog nicht mehr zur Standardinstallation, /var/log/auth.log existiert auf einem frisch aufgesetzten System also nicht zwangsläufig (Release Notes zu Bookworm, Abschnitt 5.1.7). Gelesen wird stattdessen im Journal:

journalctl -t sudo -n 20

-t filtert nach der Kennung, unter der ein Dienst protokolliert (journalctl(1)). Dieselbe Spur hilft auch bei Diagnosen, die ohnehin Root-Rechte verlangen, etwa wenn zu offenen Ports der zugehörige Prozess angezeigt werden soll.

Ein letzter Stolperstein betrifft alle, die mit Aliasen arbeiten. Sudo ist kein Shell-Befehl, deshalb löst die Shell das Wort dahinter nicht mehr als Alias auf. Die Bash macht eine Ausnahme, wenn der Alias selbst auf ein Leerzeichen endet: Dann prüft sie auch das folgende Wort (Bash-Handbuch). Genau darauf beruht der verbreitete Eintrag alias sudo='sudo '.

Fazit

Sudo ist auf Debian in wenigen Minuten eingerichtet: Paket installieren, Konto in die Gruppe sudo aufnehmen, neu anmelden. Die Stellen, an denen es trotzdem klemmt, sind immer dieselben drei. Die Gruppenmitgliedschaft greift erst in einer neuen Sitzung. /etc/sudoers wird nur mit visudo geändert. Und jede NOPASSWD-Regel gibt genau den Schutz preis, den die Umstellung gebracht hat. Wer diese drei Punkte kennt, kann das Root-Konto gesperrt lassen und verliert dabei nichts.

FAQs