Benutzer mit sudo-Rechten anlegen und nicht mehr als root arbeiten

Nach der Bereitstellung eines Servers sind Sie root, und root darf alles, ohne zu fragen. Ein Tippfehler trifft sofort das ganze System, und root ist der einzige Benutzername, den jeder Angreifer sicher kennt. Diese Anleitung geht den vollständigen Weg: Benutzer anlegen, in die richtige Gruppe aufnehmen, die sudoers-Konfiguration erweitern, den öffentlichen Schlüssel übertragen und erst zum Schluss root abschalten. Der entscheidende Teil steht kurz vor dem Ende: der Nachweis, dass Sie sich nicht ausgesperrt haben.

Bezugssysteme sind Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS und Ubuntu 22.04 LTS. Wo RHEL-artige Systeme wie AlmaLinux und Rocky Linux abweichen, steht es dabei. Die Befehle sind für den Betrieb als root geschrieben; als normaler Benutzer stellen Sie jedem Befehl ein sudo voran. Die Kurzfassung steht in der Checkliste für neue Rootserver, hier folgt die Vertiefung.

Bevor Sie etwas ändern: der Rückweg

Zwei Änderungen können hier den Zugang kosten: die sudoers-Konfiguration und, ganz am Ende, die Erlaubnis für root, sich per SSH anzumelden. Eine kaputte sudoers-Datei nimmt Ihnen die Rechte, eine zu früh abgeschaltete root-Anmeldung den Ersatzweg. Drei Dinge klären Sie deshalb vorher.

Eine zweite Sitzung. Öffnen Sie ein zweites Terminalfenster mit einer aktiven SSH-Verbindung als root und schließen Sie es nicht, bis alles geprüft ist. Eine bestehende Sitzung überlebt einen Neustart des SSH-Dienstes ebenso wie eine fehlerhafte sudoers-Datei.

Der Weg an SSH vorbei. Bei KVM-Rootservern und Dedicated Servern von KernelHost öffnen Sie die VNC-Konsole im Kundenbereich. Sie hängt an der Virtualisierungsschicht beziehungsweise am Anschluss selbst, also unabhängig von SSH, Firewall und sudoers-Datei. Melden Sie sich dort einmal vorher an: Ein Rettungsweg, den man erst im Ernstfall ausprobiert, ist keiner.

Ein Passwort, das Sie kennen. Die Konsole kennt keine SSH-Schlüssel, dort melden Sie sich mit Benutzername und Passwort an oder gar nicht. Hier entstehen die meisten Aussperrungen.

Faustregel: Der Rettungsweg ist eine Konsole, und eine Konsole kennt nur Passwörter. Bevor Sie die Passwortanmeldung abschalten, muss mindestens ein Konto ein Passwort haben, das Sie kennen.

Bestandsaufnahme: Ist sudo überhaupt installiert?

Auf Ubuntu-Serverabbildern ist sudo vorhanden, auf Debian-Minimalabbildern häufig nicht. Drei Zeilen klären die Ausgangslage:

command -v sudo || echo "sudo fehlt"
getent group sudo
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $7}' /etc/passwd

Die zweite Zeile zeigt die Gruppe samt Mitgliedern, die dritte alle regulären Konten mit Kennung und Login-Shell. Auf Abbildern mit cloud-init existiert oft längst ein Konto mit sudo-Rechten. Fehlt sudo, holen Sie es nach:

apt-get update
apt-get install -y sudo
sudo -V | head -n 1

adduser oder useradd: zwei Werkzeuge, zwei Ergebnisse

Wer useradd benutzt und adduser erwartet, bekommt ein Konto ohne Heimatverzeichnis und mit einer Shell, mit der er nicht gerechnet hat.

Auf Debian und Ubuntu ist adduser die richtige Wahl:

adduser --disabled-password --gecos "" kernel

--gecos "" überspringt die Rückfragen nach Namen und Telefonnummern, --disabled-password legt das Konto ohne Passwort an. Hier lauert die erste Falle: Ein Konto ohne Passwort kann sich nicht an der VNC-Konsole anmelden, und die Passwortabfrage von sudo lässt sich nie erfolgreich beantworten. Setzen Sie deshalb direkt danach ein Passwort:

passwd kernel

Auf RHEL-artigen Systemen oder in einem Skript lautet die gleichwertige Fassung:

useradd -m -s /bin/bash kernel
passwd kernel

Erfolgskontrolle:

getent passwd kernel
ls -ld /home/kernel
passwd -S kernel

getent passwd kernel zeigt Heimatverzeichnis und Login-Shell; steht dort /bin/sh oder /usr/sbin/nologin, korrigiert usermod -s /bin/bash kernel das. passwd -S kernel gibt in der zweiten Spalte den Zustand des Passworts aus: P für nutzbar, L für gesperrt, NP für keines. Nach passwd kernel muss dort P stehen.

Die Administratorengruppe: sudo unter Debian und Ubuntu, wheel auf RHEL

Ein verbreitetes Missverständnis: Die Gruppe verleiht die Rechte nicht selbst, sondern nur deshalb, weil in /etc/sudoers eine Zeile steht, die sich auf sie bezieht. Unter Debian und Ubuntu lautet sie sinngemäß %sudo ALL=(ALL:ALL) ALL, auf RHEL-artigen Systemen %wheel ALL=(ALL) ALL. Was bei Ihnen hinterlegt ist, zeigt:

grep -E '^[^#]*%' /etc/sudoers

Unter Ubuntu erscheint zusätzlich eine Zeile für die historische Gruppe admin. Die Gruppe existiert auf aktuellen Abbildern nicht mehr, die Zeile bleibt folgenlos. Aufgenommen wird der Benutzer so:

usermod -aG sudo kernel

Das -a ist nicht optional. Ohne diesen Schalter ersetzt usermod -G sämtliche Nebengruppen durch die angegebene Liste, kommentarlos, und der Schaden fällt oft erst Wochen später auf. Der Schalter wirkt ausschließlich zusammen mit -G. Gleichwertig und weniger fehleranfällig ist gpasswd -a kernel sudo.

Erfolgskontrolle:

id -nG kernel
getent group sudo
sudo -l -U kernel

Die letzte Zeile ist die aussagekräftigste: Sie fragt sudo selbst. Erwartet wird ein Block, der auf (ALL : ALL) ALL endet. Kommt stattdessen User kernel is not allowed to run sudo on srv01., greift keine Regel.

Warum die neue Gruppe erst bei der nächsten Anmeldung gilt

Gruppenzugehörigkeiten bekommt ein Prozess bei der Anmeldung mit und danach nicht mehr. Daher zeigt id -nG kernel als root die Gruppe sudo, während dieselbe Ausgabe in der Sitzung des Benutzers sie nicht enthält. Beides ist richtig: Der eine Befehl liest die Benutzerdatenbank, der andere die laufende Sitzung. Die Lösung ist eine neue Anmeldung, kein Neustart. newgrp sudo wirkt nur in genau der Shell, in der Sie es aufrufen.

sudoers sicher bearbeiten: visudo und /etc/sudoers.d

Öffnen Sie /etc/sudoers niemals direkt mit einem Editor. Ein Syntaxfehler macht sudo für alle Benutzer unbrauchbar, und wenn root schon abgeschaltet ist, bleibt nur die Konsole. visudo sperrt die Datei gegen gleichzeitige Änderungen und prüft die Syntax vor dem Speichern. Findet es einen Fehler, fragt es nach:

>>> /etc/sudoers: syntax error near line 22 <<<
What now?
Options are:
  (e)dit sudoers file again
  e(x)it without saving changes to sudoers file
  (Q)uit and save changes to sudoers file (DANGER!)

Die richtige Antwort ist e; das große Q speichert die fehlerhafte Datei. Welchen Editor visudo startet, entscheidet unter Debian und Ubuntu das Alternativen-System: dauerhaft über update-alternatives --config editor, einmalig über EDITOR=nano visudo.

Für eigene Regeln fassen Sie /etc/sudoers aber gar nicht erst an. Am Ende der Datei bindet eine Zeile ein ganzes Verzeichnis ein, je nach Alter des Systems als @includedir /etc/sudoers.d oder als #includedir /etc/sudoers.d. Das Doppelkreuz sieht aus wie ein Kommentarzeichen, ist aber keines. Auch diese Datei legen Sie mit visudo an:

visudo -f /etc/sudoers.d/10-kernel

Die zwei Regeln, an denen Dateien im Verzeichnis scheitern

Der Dateiname darf keinen Punkt enthalten und nicht auf eine Tilde enden. sudo überspringt solche Dateien stillschweigend, damit Sicherungskopien nicht versehentlich Rechte vergeben. 10-kernel.conf wird deshalb nie gelesen, und zwar ohne jede Meldung. Richtig ist 10-kernel.

Die Datei muss root gehören und darf für Gruppe und andere nicht schreibbar sein, erwartet wird der Modus 0440.

chown root:root /etc/sudoers.d/10-kernel
chmod 0440 /etc/sudoers.d/10-kernel
visudo -c

visudo -c prüft alle eingebundenen Dateien und gibt für jede eine Zeile aus:

/etc/sudoers: parsed OK
/etc/sudoers.d/10-kernel: parsed OK

Das ist zugleich die beste Prüfung auf die erste Regel: Taucht Ihre Datei hier nicht auf, wird sie nicht gelesen, und dann ist fast immer ein Punkt im Dateinamen die Ursache. Bei falschen Rechten meldet visudo stattdessen /etc/sudoers.d/10-kernel: bad permissions, should be mode 0440.

NOPASSWD: was es wirklich kostet

Früher oder später stößt jeder auf diese Zeile:

kernel ALL=(ALL) NOPASSWD: ALL

Sie ist gefährlicher, als sie aussieht. Die Passwortabfrage ist die letzte Hürde zwischen "jemand hat eine Shell als kernel" und "jemand ist root". Wer über eine verwundbare Webanwendung, einen kopierten privaten Schlüssel oder eine unbeaufsichtigte Sitzung an das Konto kommt, ist mit dieser Zeile ohne weiteren Schritt root. Mit NOPASSWD: ALL schrumpft der Sicherheitsgewinn gegenüber der direkten root-Anmeldung also auf einen Benutzernamen, den ein Angreifer nicht kennt.

Berechtigt ist NOPASSWD dort, wo niemand tippen kann: Ansible-Läufe, Sicherungsskripte, Deployment-Pipelines. Dann aber eng gefasst und nicht für den Menschen am Terminal:

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

Drei Fallstricke bei solchen Regeln:

• Absolute Pfade sind Pflicht. Ein Programmname ohne Pfad passt auf nichts.
• Ohne aufgeführte Argumente sind alle Argumente erlaubt. deploy ALL=(root) NOPASSWD: /usr/bin/systemctl gestattet jeden systemctl-Aufruf. Erst wenn Sie die Argumente mit aufschreiben, muss die Befehlszeile genau so lauten. Soll gar kein Argument erlaubt sein, hängen Sie ein leeres Argumentpaar an, etwa /usr/bin/id "".
• Platzhalter sind selten so eng, wie sie wirken. /usr/bin/* erlaubt jedes Programm in diesem Verzeichnis und ist praktisch voller root-Zugriff.

Die wichtigste Frage bei jeder eingeschränkten Regel: Kann der erlaubte Befehl ein anderes Programm starten oder eine Shell öffnen? Editoren, Paketmanager, Archivwerkzeuge und Interpreter können das, und eine Regel, die einen Editor per sudo erlaubt, erlaubt in der Praxis alles.

Der bessere Kompromiss ist die Merkdauer: sudo behält eine erfolgreiche Eingabe standardmäßig 15 Minuten, getrennt je Terminal. Anpassen lässt sich das unter /etc/sudoers.d/:

Defaults:kernel timestamp_timeout=5

sudo -k verwirft den Vermerk sofort, sudo -v erneuert ihn, ohne einen Befehl auszuführen.

Den öffentlichen Schlüssel auf den neuen Benutzer bringen

Solange die Passwortanmeldung per SSH aktiv ist, geht es vom Arbeitsrechner aus am bequemsten mit ssh-copy-id kernel@203.0.113.10. Ist sie bereits abgeschaltet, scheitert das mit Permission denied (publickey). Dann führt der Weg über die noch offene root-Sitzung.

Der naheliegende Griff ist dort cp -r /root/.ssh /home/kernel/.ssh, und er ist falsch: Die Dateien gehören danach root, der SSH-Server lehnt sie ab, und der Befehl nimmt einen etwaigen privaten Schlüssel von root mit, der auf einem zweiten Konto nichts verloren hat. Übertragen Sie stattdessen gezielt nur die öffentlichen Schlüssel:

install -d -m 700 -o kernel -g kernel /home/kernel/.ssh
install -m 600 -o kernel -g kernel /root/.ssh/authorized_keys /home/kernel/.ssh/authorized_keys

install setzt Rechte und Eigentümer in einem Zug, sodass kein vergessenes chown übrig bleibt. Existiert /root/.ssh/authorized_keys nicht, legen Sie die Zieldatei leer an und tragen den Schlüssel mit einem Editor ein:

install -m 600 -o kernel -g kernel /dev/null /home/kernel/.ssh/authorized_keys

Erfolgskontrolle:

ls -ld /home/kernel /home/kernel/.ssh
ls -l /home/kernel/.ssh/authorized_keys
ssh-keygen -l -f /home/kernel/.ssh/authorized_keys

Die letzte Zeile gibt zu jedem hinterlegten Schlüssel den Fingerabdruck aus. Vergleichen Sie ihn mit ssh-keygen -l -f ~/.ssh/id_ed25519.pub auf Ihrem Arbeitsrechner. So wissen Sie schon vor dem ersten Anmeldeversuch, dass der richtige Schlüssel angekommen ist.

Ein Detail, das Stunden kosten kann: Mit StrictModes yes prüft der SSH-Server nicht nur .ssh und authorized_keys, sondern auch das Heimatverzeichnis. Ist es für Gruppe oder andere schreibbar, lehnt er die Schlüsselanmeldung ab, und der Client meldet lediglich Permission denied (publickey). Welche Rechte Ihr System vergibt, steht in /etc/adduser.conf unter DIR_MODE. Alles zur Schlüsselanmeldung selbst steht in SSH absichern und Schlüsselanmeldung einrichten.

Der Test, bevor Sie root abschalten

Vier Prüfungen, und erst wenn alle sitzen, fassen Sie die SSH-Konfiguration an. Die alte root-Sitzung bleibt offen.

Erstens: eine neue SSH-Sitzung als neuer Benutzer, in einem frisch geöffneten Fenster, nicht in der bestehenden Verbindung.

ssh kernel@203.0.113.10

Erwartet wird eine Shell ohne Passwortabfrage. Werden Sie nach einem Passwort gefragt, hat der Schlüssel nicht gegriffen; ssh -v zeigt, welche Schlüssel der Client überhaupt anbietet. Hakt schon der Verbindungsaufbau, hilft Per SSH mit dem Server verbinden weiter.

Zweitens: sudo in genau dieser neuen Sitzung.

id
sudo -v
sudo id

id muss die Gruppe sudo aufführen, sudo id muss mit uid=0(root) beginnen. Ein sudo -l -U kernel aus der root-Sitzung ersetzt diesen Test nicht: Es zeigt, was sudo erlauben würde, nicht ob die Anmeldung des Benutzers funktioniert.

Drittens: die Konsole. Melden Sie sich über die VNC-Konsole im Kundenbereich als kernel mit Benutzername und Passwort an und führen Sie dort sudo -i aus. Dieser Test ist der wichtigste der vier, weil die Konsole der Rettungsweg ist und nur Passwörter kennt.

Viertens: der Zustand der Passwörter.

passwd -S root
passwd -S kernel

Bei mindestens einem der beiden Konten muss in der zweiten Spalte ein P stehen. Zwei gesperrte Konten plus eine fehlerhafte SSH-Konfiguration ergeben ein System, das nur noch über ein Rettungssystem erreichbar ist.

root abschalten, aber richtig

Drei Maßnahmen werden oft in einen Topf geworfen, obwohl ihre Folgen sehr verschieden sind.

Für die meisten Server ist prohibit-password die richtige Wahl: root bleibt als Notnagel per Schlüssel erreichbar, das Raten von Passwörtern ist trotzdem chancenlos. Die Einstellung gehört in eine eigene Datei unter /etc/ssh/sshd_config.d/, und vor jedem Neustart des Dienstes steht die Syntaxprüfung:

sshd -t && systemctl restart ssh
sshd -T | grep -i permitrootlogin

passwd -l root ist die härtere Variante und nur vertretbar, wenn der dritte Test oben gelaufen ist. Der Befehl sperrt ausschließlich die Passwortanmeldung: Ein hinterlegter SSH-Schlüssel funktioniert weiterhin, sudo -i ebenfalls.

Wovon abzuraten ist: root die Login-Shell zu nehmen, etwa mit usermod -s /usr/sbin/nologin root. Das blockiert nicht nur die Anmeldung, sondern auch sudo -i und die Notfall-Shell beim Hochfahren.

Häufige Fehler und Lösungen

kernel is not in the sudoers file.: Der Benutzer gehört zu keiner Gruppe, für die eine Regel existiert, oder die Sitzung ist älter als die Gruppenänderung. Prüfen Sie id -nG kernel als root, getent group sudo, dann eine frische Anmeldung. Ältere Fassungen hängen noch einen Satz über einen gemeldeten Vorfall an.

sudo: 3 incorrect password attempts, obwohl Sie richtig getippt haben: Das Konto hat gar kein Passwort, typischerweise weil es mit --disabled-password angelegt wurde. passwd -S kernel zeigt dann L oder NP, und passwd kernel löst es. sudo fragt zudem nach dem Passwort des aufrufenden Benutzers, nicht nach dem von root.

sudo: no tty present and no askpass program specified: Es gibt kein Terminal, an dem sudo nachfragen könnte. Typisch bei ssh server 'sudo befehl' und in Cronjobs. Bei SSH hilft ssh -t, im Cronjob gehört der Eintrag in die crontab von root.

sudo: /etc/sudoers.d/10-kernel is mode 0644, should be 0440: falsche Rechte auf der Regeldatei. chmod 0440 behebt es; bis dahin wirkt die Regel nicht.

/etc/sudoers.d/10-kernel: bad permissions, should be mode 0440: dieselbe Ursache, gemeldet von visudo -c. Nutzen Sie den Befehl nach jeder Änderung.

Die Regeldatei taucht in der Ausgabe von visudo -c überhaupt nicht auf: Der Dateiname enthält einen Punkt oder endet auf eine Tilde. Benennen Sie 10-kernel.conf in 10-kernel um.

usermod: group 'sudo' does not exist: Sie arbeiten auf einem RHEL-artigen System. Dort heißt die Administratorengruppe wheel, was getent group wheel bestätigt.

Permission denied (publickey) beim neuen Benutzer, während root sich weiterhin anmelden kann: fast immer die Rechte. /home/kernel/.ssh muss 700 sein, authorized_keys 600, beides muss dem Benutzer gehören, und das Heimatverzeichnis darf für Gruppe und andere nicht schreibbar sein. Die Ursache steht im Journal:

journalctl -t sshd -n 50 --no-pager

Gesucht ist eine Zeile, die mit Authentication refused: bad ownership or modes for directory beginnt und das betroffene Verzeichnis nennt.

sudo: unable to resolve host srv01: Name or service not known: Der Hostname fehlt in /etc/hosts. sudo läuft trotzdem, aber spürbar verzögert. Der passende Eintrag steht in der Rootserver-Checkliste.

Und wenn das Konto wieder verschwinden soll: gpasswd -d kernel sudo nimmt nur die Rechte, deluser --remove-home kernel beziehungsweise userdel -r kernel entfernt es samt Heimatverzeichnis.

Distributionsunterschiede auf einen Blick

Kurzfassung

1. Rückweg klären: zweite root-Sitzung offen halten, VNC-Konsole im Kundenbereich einmal ausprobieren, root-Passwort kennen.
2. apt-get install -y sudo, falls command -v sudo nichts liefert.
3. adduser --disabled-password --gecos "" kernel, danach passwd kernel, damit die Konsole nutzbar bleibt.
4. usermod -aG sudo kernel, auf RHEL-artigen Systemen wheel. Das -a ist Pflicht.
5. Öffentlichen Schlüssel mit install übertragen: Verzeichnis 700, Datei 600, Eigentümer der neue Benutzer.
6. Eigene Regeln nur per visudo -f in /etc/sudoers.d/, Dateiname ohne Punkt, Modus 0440, danach visudo -c.
7. Prüfen: sudo -l -U kernel, neue SSH-Sitzung, sudo id, Anmeldung an der Konsole mit Passwort.
8. Erst danach PermitRootLogin anfassen.

Ein Benutzer mit sudo-Rechten nimmt Ihnen den unbeabsichtigten Totalschaden und den bekanntesten Benutzernamen. Gegen offene Ports hilft die UFW-Firewall, gegen Angriffe, die die Anbindung sättigen, nur Filterung im Netz davor, bei KernelHost im Rechenzentrum maincubes in Frankfurt am Main. Auf dem Server selbst bleibt Ihre Aufgabe die kleinste und zugleich die wirksamste: dass genau ein Konto genau die Rechte hat, die es braucht.