Linux: Benutzer, Rechte und SSH

Wer darf auf dem Server was tun?

Ein neuer Administrator soll einen Server betreuen. Ein gemeinsames Root-Passwort wäre schnell weitergegeben, würde aber Verantwortlichkeiten vermischen und sofort umfassende Rechte verleihen. Ein eigenes Benutzerkonto, ein geprüfter SSH-Zugang und gezielt erteilte Verwaltungsrechte machen den Zugriff nachvollziehbarer. Dafür müssen Dateirechte und Anmeldung zusammenpassen.

Linux ordnet einem lokalen Benutzer eine numerische User ID (UID) zu. Eine Group ID (GID) identifiziert eine Gruppe. Ein Konto besitzt eine primäre Gruppe und kann zusätzliche Gruppenmitgliedschaften haben. Auf dem Dateisystem werden Eigentümer und Gruppe als Nummern gespeichert; die angezeigten Namen entstehen durch deren Auflösung. Derselbe Name auf zwei Rechnern garantiert daher nicht dieselbe Identität. Mit id prüfst du dein Konto, mit id lernadmin ein benanntes Konto. groups zeigt Gruppenzugehörigkeiten.

Die UID 0 kennzeichnet root. Dieses Konto hat weitreichende administrative Befugnisse; zusätzliche Schutzmechanismen und Einschränkungen können trotzdem wirken. Ein normales Konto arbeitet zunächst mit seinen eigenen Rechten. sudo führt einen erlaubten Befehl unter einer anderen Identität aus, üblicherweise root. Welche Befehle erlaubt sind, bestimmt die lokale sudo-Policy. Eine Passwortabfrage ist kein Beweis dafür, dass jeder Befehl erlaubt wäre.

sudo -l listet die für die aktuelle Identität vorgesehenen Berechtigungen auf und kann eine Authentifizierung verlangen. Unter Ubuntu und Debian wird umfassender Verwaltungszugriff häufig über die Gruppe sudo vergeben. Das ist eine Konvention der Distribution und Konfiguration, kein fest eingebautes Recht jeder gleichnamigen Gruppe. Änderungen an Gruppen werden in bestehenden Sitzungen nicht zuverlässig automatisch wirksam; eine neue Anmeldung schafft einen neuen Gruppenkontext.

Neun Bits beschreiben drei Zugriffsklassen.

ls -l kann für eine ausführbare Datei -rwxr-x--- anzeigen. Das erste Zeichen - bezeichnet eine reguläre Datei; bei einem Verzeichnis steht dort d. Es folgen drei Dreiergruppen: Owner (Eigentümer), Group (Dateigruppe) und Others (übrige Benutzer). r steht für Lesen, w für Schreiben und x für Ausführen. Ein Strich bedeutet, dass dieses Bit fehlt.

Die drei Klassen werden nicht einfach addiert: Ist ein Benutzer Eigentümer, zählt die Owner-Klasse. Sonst wird eine passende Gruppenmitgliedschaft geprüft, sonst Others. Ein Besitzer kann daher nicht auf großzügigere Others-Bits ausweichen. Für jede Klasse addierst du im Oktalsystem r = 4, w = 2, x = 1. So bedeutet 640: Eigentümer lesen und schreiben, Gruppe nur lesen, andere nichts.

chmod 640 bericht.txt setzt die klassischen Zugriffsbits auf diesen Wert. chmod u+x skript.sh ergänzt dagegen gezielt das Ausführungsrecht für den Eigentümer. In der symbolischen Schreibweise stehen u, g, o und a für Eigentümer, Gruppe, andere und alle; + ergänzt, - entfernt, = setzt die benannten Rechte. chmod g-w bericht.txt entzieht der Gruppe das Schreibrecht. Ein Ausführungsbit macht eine beliebige Textdatei noch nicht zu einem sinnvollen Programm: Ein Shellskript benötigt unter anderem gültigen Inhalt und einen passenden Interpreter.

Mit chown lernadmin:projekt bericht.txt würde ein Administrator Eigentümer und Dateigruppe ändern. chown :projekt bericht.txt ändert nur die Gruppe. Ein Wechsel des Eigentümers benötigt unter Linux administrative Befugnisse; ein normaler Benutzer kann eigene Dateien nur an zulässige Gruppen umgruppieren. Ein rekursives chown -R oder chmod -R betrifft ganze Bäume und kann Konfigurationen beschädigen. Für einen einzelnen SSH-Key reicht ein gezielter Dateipfad.

Bei Verzeichnissen bedeutet x: hindurchgehen.

Eine lesbare Datei hinter einem nicht durchquerbaren Elternverzeichnis ist nicht erreichbar. Umgekehrt kann ein Benutzer mit x, aber ohne r, auf einen bekannten Dateinamen zugreifen, sofern die Datei selbst es erlaubt; die Namen des Verzeichnisses kann er nicht auflisten. Für einen vollständigen Pfad ist x auf jedem beteiligten Verzeichnis erforderlich.

Ob du eine Datei löschen darfst, hängt vor allem von den Rechten auf ihr Elternverzeichnis ab. Eine schreibgeschützte Datei ist dadurch nicht automatisch vor dem Entfernen geschützt. Der Sticky Bit begrenzt das Löschen in gemeinsam beschreibbaren Verzeichnissen wie /tmp zusätzlich auf berechtigte Eigentümer beziehungsweise privilegierte Benutzer. Diese Besonderheit ist ein weiterer Grund, nicht pauschal 777 als Reparatur zu verwenden.

Die umask ist eine Erzeugungsmaske: Sie entfernt Rechte aus dem Modus, den ein Programm für neue Objekte anfordert. Gewöhnliche Dateien werden häufig mit höchstens 666, Verzeichnisse mit 777 angelegt. Bei umask 027 entstehen daraus typischerweise Dateien mit 640 und Verzeichnisse mit 750. Das ist eine Bitmaske, keine allgemeingültige Subtraktionsregel. Die umask fügt keine Ausführungsrechte hinzu und ändert keine bestehenden Dateien; Default-ACLs und ein restriktiverer Programmmodus können das Ergebnis beeinflussen.

Eine lokale Übung erzeugt ein neues Verzeichnis. Die runden Klammern öffnen eine Subshell, sodass die umask der aufrufenden Shell erhalten bleibt. Voraussetzung ist eine Bash-Sitzung unter Linux; hier werden keine Benutzer oder Systemdateien geändert.

(
  umask 027
  rechtetest=$(mktemp -d "$HOME/bitsicht-rechte.XXXXXX") || exit 1
  cd "$rechtetest" || exit 1
  printf 'Nur für diese Übung\n' > bericht.txt
  mkdir projekt
  ls -ld bericht.txt projekt
  chmod u=rw,g=r,o= bericht.txt
  chmod 750 projekt
  ls -ld bericht.txt projekt
)

ls -ld zeigt mit -d das Verzeichnis selbst statt seines Inhalts. Ohne Default-ACL ist die simulierte Modusausgabe -rw-r----- für bericht.txt und drwxr-x--- für projekt. mktemp -d erzeugt den äußeren privaten Testordner unabhängig davon normalerweise mit 700. Die Gruppenrechte am inneren Ordner allein verschaffen deshalb noch keinen Zugriff durch das äußere Verzeichnis. Genau diese Kombination aus Datei- und Pfadrechten ist beim Prüfen entscheidend.

SSH prüft Server und Benutzer getrennt.

Secure Shell (SSH) ermöglicht verschlüsselte entfernte Anmeldungen und Befehlsausführung. Auf deinem Rechner läuft der SSH-Client, auf dem Zielsystem nimmt der SSH-Server, etwa OpenSSH sshd, Verbindungen entgegen. Der Dienst lauscht gewöhnlich auf TCP-Port 22, sofern die Konfiguration nichts anderes festlegt. Die passende IP-Adresse, ein funktionierender Netzweg und erlaubender Firewall-Zugriff sind Voraussetzungen, keine Benutzeranmeldung.

Zuerst muss der Client den Server erkennen. Dessen Host-Key identifiziert den Server und wird nach Prüfung üblicherweise in ~/.ssh/known_hosts gemerkt. Bei der ersten Verbindung vergleichst du den Fingerabdruck über einen unabhängigen, vertrauenswürdigen Weg, zum Beispiel mit der Verwaltungskonsole. Die Anzeige einfach mit „yes“ zu bestätigen, prüft die Identität nicht. Eine spätere Warnung über einen geänderten Host-Key kann einen legitimen Neuaufbau oder einen Angriff bedeuten. Ursache und neuen Fingerabdruck prüfen, statt den gespeicherten Eintrag blind zu entfernen.

Bei Passwortauthentifizierung prüft der Server ein Benutzergeheimnis über die verschlüsselte Verbindung. Bei Public-Key-Authentifizierung besitzt der Benutzer ein Schlüsselpaar. Nur der öffentliche Teil kommt auf den Server, gewöhnlich als eigene Zeile in ~/.ssh/authorized_keys des Zielkontos. Der private Teil bleibt auf dem Client oder in einem geeigneten Hardwaregerät. Eine Passphrase schützt eine lokal gespeicherte private Schlüsseldatei zusätzlich; sie wird nicht als Serverpasswort übertragen. Wer einen privaten Schlüssel samt nötiger Entsperrmöglichkeit erhält, kann sich damit als dessen Besitzer ausgeben.

Ein neuer Administrator erhält Zugang in fünf Schritten.

Das folgende Szenario gilt für eine eigene Debian-13-/Ubuntu-24.04-Test-VM mit eingerichtetem OpenSSH-Server und einer bereits funktionierenden Verwaltungssitzung. lernadmin ist ein frei gewählter Beispielname, 192.0.2.10 eine Dokumentationsadresse, die durch die Adresse der eigenen VM zu ersetzen ist. Diese Schritte verändern Benutzerkonten und gehören nicht auf einen fremden oder produktiven Host. Während der Einrichtung bleibt die bisherige Sitzung offen; außerdem muss ein getesteter Konsolen- oder Wiederherstellungszugang vorhanden sein.

1. Ein eigenes Konto bereitstellen.

sudo adduser lernadmin
id lernadmin

Der bestehende Administrator erstellt mit adduser interaktiv ein Konto mit Home-Verzeichnis. Passwort und Personendaten werden lokal eingegeben, nicht aus diesem Artikel übernommen. id prüft die zugeordneten Nummern und Gruppen. Eine simulierte Ausgabe könnte uid=1002(lernadmin) gid=1002(lernadmin) groups=1002(lernadmin) lauten; die Zahlen sind nicht vorgegeben. Ein normales Konto soll zunächst keine unnötigen Gruppen besitzen.

2. Identität und Rechte kontrollieren.

sudo -l -U lernadmin
sudo ls -ld /home/lernadmin

-l listet sudo-Regeln; -U lässt den berechtigten Administrator die Regeln des angegebenen Benutzers prüfen. Zu diesem Zeitpunkt ist fehlende sudo-Berechtigung ein erwartbares Ergebnis. Besitzer und Gruppe des Home-Verzeichnisses müssen zum Konto passen; es darf nicht durch beliebige andere Benutzer beschreibbar sein. Umfangreiche sudo-Rechte werden erst nach dem Zugangstest bewusst erteilt.

3. Nur den öffentlichen Schlüssel hinterlegen.

Der neue Administrator erzeugt auf seinem Client einen eigenen Schlüssel oder verwendet einen dafür vorgesehenen vorhandenen. Beispielsweise startet ssh-keygen -t ed25519 die interaktive Erzeugung; -t wählt den Schlüsseltyp. Wähle einen noch unbenutzten Dateipfad und eine Passphrase. Bei einer Überschreibfrage abbrechen und den Pfad prüfen. Manche Richtlinien, etwa bestimmte FIPS-Umgebungen, erfordern einen anderen erlaubten Algorithmus. Die Datei ohne .pub ist privat und darf nicht weitergegeben werden.

Für eine gestufte Einrichtung kann sich der bestehende Administrator den geprüften .pub-Inhalt über den vereinbarten Kanal geben lassen und im Testkonto hinterlegen. Ein distributionsunabhängiger Automatismus mit erfundenem Schlüssel wäre hier unbrauchbar. In der vorhandenen Administrationssitzung:

sudo -iu lernadmin
umask 077
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

sudo -iu öffnet eine Login-Shell des Zielbenutzers. Damit landen die folgenden Dateien im richtigen Home und gehören dem neuen Benutzer. umask 077 begrenzt neu erzeugte Dateien auf diesen Benutzer. mkdir -p legt das Verzeichnis an, falls es fehlt, chmod 700 setzt dessen Rechte ausdrücklich. nano ist hier der beispielhafte Editor; falls er fehlt, verwende einen vertrauten installierten Editor. Füge den öffentlichen Schlüssel als eine vollständige neue Zeile hinzu, ohne vorhandene berechtigte Schlüssel zu ersetzen. Er beginnt zum Beispiel mit ssh-ed25519; der Artikel enthält absichtlich keinen verwendbaren Schlüssel.

chmod 600 ~/.ssh/authorized_keys
ls -ld ~/.ssh ~/.ssh/authorized_keys
exit

600 erlaubt dem Eigentümer Lesen und Schreiben. exit beendet die Zielbenutzer-Shell und kehrt zur vorherigen Sitzung zurück. OpenSSH kann unsichere Besitz- und Schreibrechte beim Prüfen des Zugangs zurückweisen. Das Hinterlegen einer Public-Key-Zeile erfordert normalerweise keinen Dienstneustart. Das hier gezeigte Standardziel kann durch AuthorizedKeysFile oder andere Mechanismen geändert sein; die tatsächliche Serverkonfiguration zählt.

4. In einem zweiten Terminal anmelden.

ssh -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no -i ~/.ssh/bitsicht_admin lernadmin@192.0.2.10
id

Der Clientbefehl verwendet mit -i den zuvor gewählten privaten Schlüsselpfad; passe ihn an. IdentitiesOnly=yes begrenzt die angebotenen Identitäten, PreferredAuthentications=publickey fordert die gewünschte Methode. Die beiden weiteren Optionen schließen Passwort und interaktive Passwortverfahren für diesen Test aus. Diese Optionen ändern keine Serverdatei. Eine lokale Passphrase-Abfrage zum Entsperren des Schlüssels bleibt möglich. Prüfe den Host-Key über den unabhängigen Kanal. Erst eine erfolgreiche neue Sitzung mit der erwarteten Identität bestätigt den Zugang.

5. Administrative Befugnisse gezielt vergeben und neu testen.

Benötigt der neue Administrator tatsächlich vollständige Systemverwaltung, kann der bestehende Administrator auf dieser Test-VM sudo adduser lernadmin sudo ausführen. Das ist eine weitreichende Berechtigung, keine harmlose Formalität. Für begrenzte Aufgaben ist eine engere, mit visudo geprüfte sudo-Policy sinnvoll; scheinbar harmlose Editoren oder Shells können eine Beschränkung aushebeln.

Nach der Gruppenänderung meldet sich lernadmin erneut in einem separaten Terminal an und prüft id, sudo -l und gegebenenfalls sudo id -u. Letzteres führt nur die UID-Abfrage mit erhöhten Rechten aus; die erwartete Ausgabe ist 0. Es belegt diese Ausführung, nicht jede denkbare Administratoraufgabe. Die alte Verwaltungssitzung bleibt bis zum vollständigen erfolgreichen Test geöffnet.

Härtung folgt dem bewiesenen Zugang.

Das Prinzip minimaler Berechtigungen lautet: Jede Identität und jeder Dienst erhält nur die notwendigen Zugriffe. Eigene Konten statt geteilter Root-Anmeldung verbessern Zuordnung und Entzug von Zugriffen. PermitRootLogin no kann direkten Root-Zugang sperren, während eine separat erlaubte sudo-Nutzung bestehen bleibt. Auf vielen Systemen ist Root ohnehin kein regulär per Passwort nutzbares Konto. Der tatsächliche Stand muss geprüft werden.

Passwortanmeldung wird erst eingeschränkt, wenn ein zweiter Schlüsselzugang und seine benötigten sudo-Rechte funktionieren sowie ein Wiederherstellungsweg getestet ist. Die relevanten OpenSSH-Optionen sind PubkeyAuthentication, PasswordAuthentication und KbdInteractiveAuthentication; nur eine Passwortoption abzuschalten deckt nicht jedes interaktive Verfahren ab. MFA- oder PAM-Vorgaben können ausdrücklich ein interaktives Verfahren verlangen. Deshalb liefert dieser Artikel keinen kopierbaren Block zum Abschalten von Anmeldewegen.

Vor einer geplanten Änderung werden bestehende Konfiguration und ein Rückweg gesichert. Anschließend prüft ein Administrator mit sudo /usr/sbin/sshd -t die Syntax und mit sudo /usr/sbin/sshd -T die effektive Grundkonfiguration; für Match-Regeln braucht die Auswertung zusätzlich den passenden Verbindungskontext über -C. Include-Dateien und häufig der zuerst gelesene Wert sind relevant. Eine fehlerfreie Syntax beweist noch keinen funktionierenden Login. Erst danach wird der Dienst über den für die Distribution vorgesehenen Weg neu geladen und ein neuer Zugang getestet. Die alte Sitzung bleibt offen; ein Syntaxfehler führt zum Abbruch und zur Korrektur.

Eine Firewall beschränkt, welche Quellen welchen Dienst erreichen. Für einen eigenen Server sollte SSH nur aus den benötigten Netzen oder über einen abgesicherten Verwaltungsweg erreichbar sein. Bestehende Regeln erst lesen, dann eine nötige Freigabe gezielt planen; kein pauschales Aktivieren einer Firewall in der laufenden einzigen SSH-Sitzung. Ein anderer Port ersetzt keine Authentifizierung. „Connection refused“, Timeout und „Permission denied“ gehören zu unterschiedlichen Prüfschritten: Listener beziehungsweise Ablehnung, Erreichbarkeit beziehungsweise Filter, dann Anmeldung. Die systematische Serverdiagnose führt diese Ebenen zusammen; bei Namen hilft der DNS-Artikel.

Für einen lokalen KI-Server gilt dieselbe Trennung: Ein Konto zum Bedienen der Anwendung benötigt nicht automatisch umfassende Root-Rechte. Entzogene SSH-Schlüssel werden aus den zulässigen Schlüsselquellen entfernt; bereits laufende Sitzungen verschwinden dadurch nicht zwingend. Auch diese gehören bei einem tatsächlichen Entzug geprüft.

Zwei Entscheidungen begründen.

Aufgabe 1: Eine Datei gehört dir, ist mit 400 nur lesbar, liegt aber in einem Verzeichnis, auf dem ein anderer Benutzer wirksame wx-Rechte besitzt. Schützt der Dateimodus sie zuverlässig vor dem Löschen? Welcher Modus wäre für ein persönliches Verzeichnis üblich?

Aufgabe 2: Das neue Konto kann sich in einer zweiten Sitzung per Schlüssel anmelden. sudo -l verweigert dort aber die benötigte Administration. Darfst du jetzt Passwortzugang und direkten Root-Login abschalten?

Quellen und fachlicher Stand.

Fachlich geprüft am 22.10.2026. Zielumgebung: Debian 13 / Ubuntu Server 24.04 LTS mit OpenSSH; die geprüften Debian-Manpages beziehen sich auf OpenSSH 10.0p1 und GNU Coreutils 9.7. Paketversionen und lokale Sicherheitsrichtlinien können abweichen. Kein SSH-Dienst und kein echtes Benutzerkonto wurden für diese Seite verändert.

• Ubuntu Server: Benutzerverwaltung und sudo sowie sudo(8): Optionen und Policy.
• Debian Reference: Rechte, Verzeichnisse und umask und path_resolution(7): Pfadzugriff, umask(2): Erzeugungsmaske, inode(7): Dateimetadaten und Rechte und unlink(2): Löschberechtigung.
• chmod(1) und chown(1): Modi und Eigentümer.
• Ubuntu Server: OpenSSH einrichten und Konfiguration prüfen.
• ssh(1): Client, Identitäten und Host-Prüfung, ssh-keygen(1): Schlüssel erzeugen, sshd(8): authorized_keys und Prüfbefehle und sshd_config(5): effektive Konfiguration und Authentifizierung.