Eigenen Benutzer anlegen und sudo einrichten

Warum nicht als root arbeiten

Auf einem frisch ausgelieferten Server bist du in der Regel als root eingeloggt. Mit dieser Identität dauerhaft zu arbeiten, bringt drei Probleme mit sich:

• Kein Schutznetz. Jeder Tippfehler ist ein produktiver Eingriff. rm -rf /var/log/* an der falschen Stelle löscht ohne Nachfrage.
• Keine Zurechenbarkeit. Wenn mehrere Personen Zugang haben oder du später Audit-Logs auswerten willst, sieht jede Aktion gleich aus — alles war „root”.
• Brute-Force-Ziel. Der Benutzername root ist überall identisch. Angriffe versuchen ihn zuerst. Ein eigener Benutzer mit individuellem Namen ist deutlich schwerer zu erraten.

Lösung: Ein normaler Benutzer mit sudo-Rechten. Standardarbeit läuft als der Benutzer, kritische Operationen werden bewusst mit sudo eingeleitet.

Neuen Benutzer anlegen

Auf Debian/Ubuntu verwendest du adduser — ein interaktives Wrapper-Skript, das alles Notwendige erledigt:

sudo adduser max

Du wirst nach einem Passwort gefragt (für sudo-Aufrufe sinnvoll, auch wenn der SSH-Login per Key läuft) und nach optionalen Stammdaten — Name, Telefonnummer etc. lassen sich mit Enter überspringen.

Auf AlmaLinux/Rocky/RHEL ist adduser lediglich ein Symlink auf useradd, der weniger interaktiv ist:

sudo useradd -m -s /bin/bash max
sudo passwd max

useradd-Optionen erklärt:

• -m — Home-Verzeichnis anlegen (/home/max).
• -s /bin/bash — Login-Shell setzen. Default auf RHEL ist oft /bin/sh oder gar keine — explizit setzen vermeidet Überraschungen.
• passwd max — Passwort vergeben (für sudo-Aufrufe).

adduser vs. useradd: Auf Debian/Ubuntu ist adduser der bequeme Weg, useradd das Low-Level-Tool. Auf der RHEL-Familie sind beide Befehle praktisch identisch, weil adduser nur ein Symlink ist. Im Zweifel adduser versuchen — es funktioniert fast überall.

In die sudo-/wheel-Gruppe aufnehmen

Distributionen unterscheiden sich, welche Gruppe sudo-Rechte bekommt:

Mitgliedschaft setzen:

sudo usermod -aG sudo max

sudo usermod -aG wheel max

Wichtig: das -a (append) niemals vergessen. Ohne -a ersetzt usermod -G alle Gruppen des Users — das fliegt einem unter Umständen direkt um die Ohren, weil dem User die Default-Gruppe weggenommen wird.

Prüfen, in welchen Gruppen der User ist:

groups max

SSH-Key auf den neuen Benutzer übertragen

Der Public Key liegt aktuell im authorized_keys von root. Der neue Benutzer braucht ihn ebenfalls. Drei Wege:

Variante 1 — vom lokalen Rechner aus (sauber)

Wie schon beim ersten Server-Setup mit ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub max@203.0.113.42

Voraussetzung: Der neue Benutzer hat ein Passwort (siehe Abschnitt 2). ssh-copy-id verbindet sich einmalig per Passwort und legt authorized_keys korrekt mit den richtigen Rechten an.

Variante 2 — auf dem Server kopieren

Wenn du eingeloggt bist, kannst du die Datei einfach umkopieren:

mkdir -p /home/max/.ssh
cp /root/.ssh/authorized_keys /home/max/.ssh/authorized_keys
chown -R max:max /home/max/.ssh
chmod 700 /home/max/.ssh
chmod 600 /home/max/.ssh/authorized_keys

Die chown/chmod-Schritte sind kritisch: Wenn die Rechte zu offen sind, ignoriert sshd die authorized_keys ohne sichtbaren Hinweis und der Login schlägt fehl.

Variante 3 — Public Key direkt einfügen

Wenn dir der Public Key in der Zwischenablage vorliegt:

mkdir -p /home/max/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...  max@beispielmail.de" > /home/max/.ssh/authorized_keys
chown -R max:max /home/max/.ssh
chmod 700 /home/max/.ssh
chmod 600 /home/max/.ssh/authorized_keys

Login mit neuem Benutzer testen — vor dem root-Lock

Bevor du den root-Login deaktivierst, in einer zweiten Terminal-Session prüfen, ob der Login als der neue Benutzer funktioniert:

ssh max@203.0.113.42

Wenn das klappt, ein sudo-Test:

sudo -v
sudo whoami
# erwartet: root

sudo -v aktualisiert das sudo-Timeout, ohne ein konkretes Kommando auszuführen — guter erster Test, weil keine Nebenwirkung. sudo whoami muss root zurückgeben.

Warum die alte Session offen lassen? Solange du mit dem getrennten Terminal noch als root eingeloggt bist, kannst du Fehler im Setup ohne Aussperr-Risiko korrigieren. Erst nach erfolgreichem Login + sudo-Test in der neuen Session wird die Root-Session entbehrlich.

sudo-Verhalten konfigurieren

Standard-sudo verlangt das Passwort des Users — alle 5–15 Minuten neu (je nach Distribution). Das ist eine bewusste Sicherheitsschicht: wer sich an deinen Rechner setzt, während du Kaffee holst, bekommt nicht automatisch root.

Passwortloses sudo — wann sinnvoll?

Bei interaktiven Admin-Sessions sollte das Passwort drin bleiben. Bei Automatisierung (Ansible, Skripte, CI/CD) wirft es Probleme — dort wird passwortloses sudo gezielt für einen separaten Automation-User eingerichtet, nicht für den persönlichen Account.

Wenn du dich davon überzeugen willst, dass es für deinen interaktiven Account passt, ist die saubere Methode eine Datei in /etc/sudoers.d/:

sudo visudo -f /etc/sudoers.d/max-nopasswd

max ALL=(ALL) NOPASSWD: ALL

visudo prüft die Syntax beim Speichern. Direkt in /etc/sudoers schreiben vermeiden — ein Tippfehler dort sperrt sudo aus, dann hilft nur noch der Rescue-Mode.

sudo-Timeout anpassen (optional)

Standard sind 5 Minuten (Debian/Ubuntu) bzw. 15 Minuten (RHEL-Familie). Anpassen via:

Defaults timestamp_timeout=30

30 = 30 Minuten. 0 deaktiviert das Caching komplett (sudo fragt jedes Mal). -1 schaltet das Caching für die Session ohne Ablauf an — wird selten empfohlen.

Root-SSH-Login deaktivieren

Erst jetzt — nachdem der eigene Login plus sudo nachweislich funktioniert — wird der Root-Zugang per SSH abgeschaltet. In /etc/ssh/sshd_config.d/ eine eigene Datei anlegen, statt direkt an sshd_config zu schreiben:

sudo nano /etc/ssh/sshd_config.d/01-no-root.conf

PermitRootLogin no

Konfiguration prüfen und SSH neu laden:

sudo sshd -t
sudo systemctl reload ssh

sshd -t testet die Konfiguration auf Syntaxfehler — kommt kein Output, ist alles gültig. Reload statt Restart: bestehende Sessions laufen weiter, nur neue Verbindungen werden mit der neuen Konfig akzeptiert. Das ist absichtlich, falls die Konfiguration einen Fehler enthält.

PermitRootLogin prohibit-password ist eine Zwischenoption: erlaubt root-Login, aber nur per Key, kein Passwort. In den meisten Setups reicht no — wenn du root via SSH brauchst, läuft etwas anderes schief und sollte über sudo gehen.

Verifikation aus einer dritten Terminal-Session:

ssh root@203.0.113.42
# erwartet: Permission denied (publickey).

Sicherheits-Checkliste

• Neuer Benutzer angelegt, Home-Verzeichnis vorhanden, Login-Shell gesetzt
• Mitgliedschaft in sudo (Debian/Ubuntu) oder wheel (RHEL) per groups <user> verifiziert
• Public Key in ~/.ssh/authorized_keys des neuen Users, Rechte 700/600 korrekt
• Login als neuer User in einer separaten Session erfolgreich, sudo whoami liefert root
• PermitRootLogin no gesetzt, mit sshd -t validiert, per Reload geladen
• Letzte root-Session beendet, ab jetzt arbeitet ausschließlich der neue Benutzer
• Passwort des neuen Benutzers nicht zu schwach — auch wenn der SSH-Login per Key geht, schützt das Passwort die sudo-Eskalation. Mindestens 16 Zeichen, idealerweise aus einem Passwort-Manager

Verwandte Artikel

• Erste SSH-Verbindung und SSH-Key einrichten — der Schritt davor
• SSH-Hardening — PasswordAuthentication no, Port-Wechsel, fail2ban — der nächste Schritt
• Linux für den eigenen Server wählen — Distro-Wahl betrifft sudo vs. wheel
• Linux-Doku: SSH-Konfiguration — Tiefen-Doku zu sshd_config-Optionen

Externe Quellen

• sudoers(5) Manpage — vollständige Referenz für sudoers-Syntax
• OpenSSH sshd_config Manpage — alle SSH-Server-Optionen
• Debian Wiki: sudo — Debian-spezifische sudo-Konventionen
• Red Hat: Adding a User — RHEL-Doku zu Benutzer-Verwaltung