Linux / Befehl su: Benutzerkonten und Login-Shells wechseln

su ist ein Werkzeug, das verwendet wird, um eine Shell oder Befehle mit einer alternativen Benutzer- und Gruppen-ID auszuführen. Wenn kein Benutzer angegeben ist, richtet es sich typischerweise an root, und die Verwendung von su --login user wechselt zu einer Umgebung, die der direkten Anmeldung als diesem Benutzer entspricht.

Ein einfaches su user behält das aktuelle Arbeitsverzeichnis und einen Teil der Umgebung bei, was mit den Einstellungen eines anderen Benutzers gemischt werden kann. Für einen interaktiven Benutzerwechsel wird normalerweise su --login user verwendet, und wenn der Zweck nur darin besteht, einen einzelnen administrativen Befehl auszuführen, sollte zuerst überlegt werden, ob ein richtlinienbasierter sudo geeigneter ist.

Was ist der su-Befehl?

su führt Befehle mit einer anderen Benutzer- und Gruppen-ID aus. Wenn der Benutzername weggelassen wird, versucht es, eine interaktive Shell als root zu starten.

su aus util-linux führt Authentifizierung sowie Konto- und Sitzungsverwaltung über PAM (Pluggable Authentication Modules) aus. Welches Passwort erforderlich ist, ob nur bestimmte Gruppen su verwenden können und wo die Versuche protokolliert werden, hängt von den PAM- und Sicherheitseinstellungen der Distribution ab.

Dieser Artikel basiert auf der Implementierung von util-linux, die in Linux weit verbreitet ist. Das genaue Verhalten und systemabhängige Konfigurationsdateien finden Sie auf der offiziellen util-linux su-Handbuchseite.

Grundsyntax und Nutzerwechsel

Die Grundsyntax ist wie folgt.

su [options] [-] [user [arguments...]]

Wenn kein Benutzer angegeben wird, versucht es, zum Root-Konto zu wechseln.

su

Wenn es von einem normalen Benutzer ausgeführt wird, wird normalerweise nach dem Passwort des Ziel-Root-Kontos gefragt. Wenn das Root-Konto gesperrt ist oder die PAM-Richtlinie dies nicht erlaubt, kann der Wechsel nicht vorgenommen werden, selbst wenn das richtige Benutzerpasswort bekannt ist.

Um zu einem bestimmten Benutzer zu wechseln, geben Sie den Kontonamen an.

su deploy

Um zur ursprünglichen Shell zurückzukehren, führen Sie exit in der gewechselten Shell aus oder drücken Sie Strg+D.

exit

Der Unterschied zwischen su und su --login

Kategorie su user su --login user
Arbeitsverzeichnis aktuelles Verzeichnis beibehalten ins Home-Verzeichnis des Zielbenutzers wechseln
Umgebungsvariablen nur teilweise geändert und kann sich mit der bestehenden Umgebung mischen meist gelöscht, um die Login-Umgebung des Zielbenutzers einzurichten
PATH Beeinflusst durch Systemeinstellungen und PAM Initialisieren, um der Ziel-Login-Umgebung zu entsprechen
Methode des Shell-Starts Standard interaktive Shell Als Login-Shell starten
Empfohlene Situationen Für begrenzte Fälle gedacht, in denen die Beibehaltung der Umgebung gewünscht ist Normales interaktives Benutzerwechseln

Das Handbuch von util-linux empfiehlt die Verwendung von --login, um Nebeneffekte durch gemischte Umgebungen zu vermeiden. Die Kurzform - hat die gleiche Bedeutung.

su --login deploy
su - deploy

Änderungen in der Login-Shell-Umgebung

Räumt die meisten vorhandenen Umgebungsvariablen auf

Die su --login von util-linux löscht die bestehende Umgebung mit Ausnahme von TERM, COLORTERM, NO_COLOR und explizit erlaubten Variablen. Anschließend initialisiert sie HOME, SHELL, USER, LOGNAME und PATH basierend auf dem Zielbenutzer.

Die endgültige Umgebung kann auch Werte widerspiegeln, die durch PAM-Module hinzugefügt oder geändert wurden, daher sollte nicht davon ausgegangen werden, dass sie über alle Distributionen hinweg genau gleich ist.

In das Home-Verzeichnis des Zielbenutzers wechseln

--login startet die Login-Shell nach dem Wechsel in das Home-Verzeichnis des Zielbenutzers. Nach dem Wechsel können Sie den Benutzer, das Home-Verzeichnis und das Arbeitsverzeichnis mit den folgenden Befehlen überprüfen.

id
printf '%s\n' "$HOME"
pwd

Änderung der Shell-Initialisierungsdateien

Die Login-Shell liest Initialisierungsdateien für die Anmeldung gemäß den Regeln der verwendeten Shell. Bei Bash kann dies durch Systemeinstellungen und Benutzereinstellungen wie /etc/profile und ~/.bash_profile beeinflusst werden. Überprüfen Sie das Handbuch der Ziel-Shell und die Kontoeinstellungen für die tatsächliche Reihenfolge.

Häufig verwendete su-Optionen

Option Funktion Verwendung und Vorsichtsmaßnahmen
-, -l, --login Wechsel zur Login-Shell-Umgebung Allgemein für interaktives Umschalten empfohlen
-c command, --command command Einen einzelnen Befehl an die Shell weitergeben Muss Quoting und Exit-Status prüfen
-s shell, --shell shell Die auszuführende Shell angeben In einem eingeschränkten Shell-Konto kann dies ignoriert werden, wenn der Aufrufer nicht root ist
-m, -p, --preserve-environment Die aktuelle Umgebung so weit wie möglich beibehalten Wird bei Verwendung mit --login ignoriert, vorsichtig für die Sicherheit verwenden
-w list, --whitelist-environment list Beim Umschalten des Logins bestimmte Umgebungsvariablen beibehalten Durch Kommas getrennt, ohne zentrale Kontovariablen
-P, --pty Erstellen Sie ein separates Pseudo-Terminal in der Sitzung Nützlich zur Trennung der Terminals interaktiver Sitzungen
-g group Standardgruppe angeben Nur Root-Benutzer kann es verwenden
-G group Sekundärgruppe angeben Nur Root-Benutzer kann es verwenden und wiederholbar

Einen einzelnen Befehl als ein anderer Benutzer ausführen

Führen Sie einen Befehl mit -c aus

Wenn Sie nicht in einer interaktiven Shell bleiben müssen, können Sie Befehle an die Shell des Zielbenutzers mit -c übergeben.

su -c 'id' deploy

Wenn der Befehl endet, beendet sich su ebenfalls und kehrt zur ursprünglichen Shell zurück. Da die Befehlszeichenfolge von der Zielshell neu interpretiert wird, achten Sie auf Anführungszeichen, Variablenexpansion und den Zeitpunkt der Umleitung.

Befehle in einer Login-Umgebung ausführen

Um Befehle in der Login-Umgebung und im Heimatverzeichnis des Zielbenutzers auszuführen, verwenden Sie --login zusammen.

su --login -c 'pwd; id' deploy

Beide Befehle, die durch ein Semikolon verbunden sind, werden innerhalb der Shell des Zielbenutzers ausgeführt. Übergeben Sie keine dynamisch erstellten Strings mit erhöhten Rechten direkt, wenn sie externe Eingaben enthalten, da dies das Risiko einer Befehlsinjektion birgt.

Überprüfung des Exit-Status von Befehlen

su gibt im Allgemeinen den Exit-Status des ausgeführten Befehls zurück. In der util-linux-Implementierung gibt es 126 zurück, wenn der Befehl nicht ausgeführt werden kann, 127, wenn der Befehl nicht gefunden wird, und 1 für allgemeine Fehler vor der Befehlsausführung.

su -c '/usr/local/bin/check-job' deploy
status=$?
printf 'exit=%s\n' "$status"

In der Automatisierung sollten Sie nicht nur die Ausgabestrings, sondern auch den Exit-Status überprüfen.

Umgang mit Shells und eingeschränkten Konten

Standard-Shell des Zielbenutzers

Sofern nicht anders angegeben, wird in der Regel die im passwd-Eintrag des Zielkontos festgelegte Shell verwendet, und falls diese fehlt, ist standardmäßig /bin/sh eingestellt. Beim Überprüfen von Kontoinformationen sollte nicht willkürlich die gesamte /etc/passwd geändert werden; stattdessen sollte wie folgt abgefragt werden.

getent passwd deploy

Shell mit -s angeben

Sie können eine andere Shell mit -s angeben.

su -s /bin/sh -c 'id' deploy

Wenn die Shell des Zielkontos eine eingeschränkte Shell ist, die nicht in /etc/shells aufgeführt ist, kann die von einem normalen Benutzer angegebene Shell ignoriert werden. Nur weil root die Einschränkung umgehen kann, bedeutet das nicht, dass es sicher ist, für ein Dienstkonto eine interaktive Shell zu öffnen.

Den Zweck von Dienstkonten respektieren

Konten mit nologin oder false als Shell sind wahrscheinlich nicht für interaktive Logins vorgesehen. Wenn Sie mit einem solchen Konto arbeiten müssen, führen Sie nur den notwendigen Befehl aus und überprüfen Sie zuerst, ob Verwaltungsbefehle vom Dienst bereitgestellt werden oder ob systemd-Funktionen verfügbar sind.

Umgang mit der Beibehaltung von Umgebungsvariablen vorsichtig

Bedeutung von --preserve-environment

Die Option --preserve-environment behält die aktuelle Umgebung bei, ohne HOME, SHELL, USER oder LOGNAME zurückzusetzen. Sie wird ignoriert, wenn sie zusammen mit --login angegeben wird.

su --preserve-environment deploy

Sofern es sich nicht um einen Sonderfall handelt, bei dem die Einstellungen des aufrufenden Benutzers unverändert übernommen werden müssen, kann das Mischen des Home- und Ausführungsumfelds des Zielkontos zu unerwarteten Dateibesitz- oder Konfigurationsänderungen führen.

Nur notwendige Variablen zulassen

In util-linux können Sie nur die notwendigen Variablen beibehalten, indem Sie --login und --whitelist-environment kombinieren.

su --login --whitelist-environment=LANG,LC_ALL deploy

HOME, SHELL, USER, LOGNAME und PATH sind von der Whitelist ausgeschlossen. Gebietsschema-Variablen können ebenfalls das Programmverhalten beeinflussen, daher sollten nur Werte übergeben werden, die absolut notwendig sind.

Unterschied zwischen su und sudo

Kategorie su sudo
Hauptzweck Shell oder Befehle als ein anderer Benutzer ausführen Befehle als ein anderer Benutzer ausführen, der durch Richtlinie erlaubt ist
Allgemeine Authentifizierung Passwort des Zielbenutzers Passwort des aufrufenden Benutzers
Umfang der Berechtigungen Weiterhin die Berechtigungen des Zielkontos in der gewechselten Shell verwenden Kann mit erlaubten Befehlen und Bedingungen eingeschränkt werden
Überwachung und Nachverfolgung Fokussiert auf Sitzungswechselprotokolle, und internes Befehls-Tracking erfordert eine separate Verfolgung Ausführungsanforderungen können über Richtlinien-/Protokollierungs-Plugins aufgezeichnet werden
Geeignete Situationen Wenn das Zielkonto eine interaktive Umgebung benötigt Führen Sie einen einzelnen administrativen Befehl oder minimale Privilegien pro Rolle aus

Authentifizierungsmethode und Protokollierung können je nach PAM und Richtlinie variieren, daher ist die obige Tabelle ein allgemeiner Vergleich. Wenn nur ein Root-Befehl benötigt wird, ist sudo, das die Privilegien pro Befehl einschränken kann, oft geeigneter als su, das das Kontopasswort teilt. Für detaillierte Nutzung siehe Linux sudo-Befehl und sudoers-Konfiguration.

Gründe, nicht direkt zum Root-Konto zu wechseln

Das Root-Konto kann gesperrt sein

Einige Distributionen deaktivieren standardmäßig die Passwortanmeldung für das Root-Konto und verwenden die Administration über sudo. In diesem Fall wird die Eingabe des aktuellen Benutzerpassworts in su - nicht erfolgreich sein.

Wenn der Benutzer über sudo-Rechte verfügt und die Richtlinie dies zulässt, kann eine login-ähnliche Root-Shell wie folgt geöffnet werden, aber wenn nur einzelne Befehle benötigt werden, ist es sicherer, sudo command anstelle einer Administratorshell zu verwenden.

sudo -i

PAM- oder Gruppenrichtlinien können Einschränkungen auferlegen

Die Richtlinie in /etc/pam.d/su kann die Verwendung von su auf bestimmte Gruppen beschränken oder zusätzliche Authentifizierungsanforderungen erzwingen. Schwächen Sie PAM-Einstellungen nicht willkürlich, um Privilegien zu erlangen; stellen Sie stattdessen dem Systemadministrator die erforderlichen Aufgaben und Zielkonten bereit.

Es kann Probleme mit dem Status des Zielkontos geben.

Der Wechsel kann aufgrund von Kontoablauf, Sperrung, falschem Heimatverzeichnis, eingeschränkter Shell oder Dateiberechtigungen fehlschlagen. Wenn Sie Administrator sind, überprüfen Sie die Ursache mit getent passwd user, Kontoverwaltungstools und Authentifizierungsprotokollen.

Wenn root als ein anderer Benutzer ausgeführt wird

kann runuser für die Automatisierung besser geeignet sein

Das util-linux-Handbuch empfiehlt bereits runuser, wenn es als ein anderer Benutzer von einem Prozess mit hohen Rechten oder aus den Skripten von root ausgeführt wird. runuser ist nicht set-user-ID, erfordert keine Passwortauthentifizierung und verwendet eine separate PAM-Konfiguration.

runuser -u backup -- /usr/local/bin/backup-job

runuser ist ein Verwaltungstool, das von root verwendet wird, daher ist es kein Befehl für einen normalen Benutzer, um Privilegien anstelle von sudo zu erlangen.

Wenn eine PAM-Sitzung nicht benötigt wird, überdenken Sie den Zweck

Wenn Sie lediglich Benutzer-/Gruppen-IDs und Berechtigungsattribute ändern müssen, um ein Programm auszuführen und keine PAM-Sitzung erforderlich ist, schlägt util-linux auch setpriv als Alternative vor. Dieses Tool verwaltet direkt Privilegien und Sicherheitsattribute, daher sollte es nur von Administratoren verwendet werden, die die genauen Benutzer-, Gruppen-, Zusatzgruppen- und Fähigkeits-Einstellungen verstehen.

Trennen Sie die Sitzung mit einem Pseudo-Terminal

Trennung bereitgestellt durch --pty

--pty erstellt ein separates Pseudo-Terminal zwischen der ursprünglichen Sitzung und der Ziel-Sitzung, und su leitet die Eingaben und Ausgaben weiter. Dies kann die Sicherheit verbessern, indem verhindert wird, dass die beiden Sitzungen in einer interaktiven Sitzung dasselbe Terminal direkt teilen.

su --pty --login deploy

Keine vollständige systemd-Anmeldesitzung

Selbst bei der Verwendung von su --login wird aus der Perspektive von systemd-logind keine vollständig neue tatsächliche Anmeldungssitzung erstellt. Wenn Sie Aufgaben ausführen müssen, die Benutzerdienste, Sitze oder Sitzungsgrenzen erfordern, sollten Sie Werkzeuge in Betracht ziehen, die für diesen Zweck geeignet sind, wie systemd-run oder machinectl.

Sicherheitsvorkehrungen

  • Teilen Sie das Root-Passwort oder die Passwörter anderer Benutzer nicht mit mehreren Personen.
  • Geben Sie Passwörter nicht auf der Befehlszeile, in der Shell-Historie, in Skripten oder in Pipes ein.
  • Halten Sie eine Root-Shell nicht länger offen als notwendig; exit sofort nach Abschluss der Arbeit.
  • Unmittelbar nach dem Wechsel überprüfen Sie id, pwd und HOME, um Verwechslungen zwischen Benutzern und Pfaden zu vermeiden.
  • Für Befehle, die mit erhöhten Rechten ausgeführt werden sollen, überprüfen Sie zunächst die Optionen, Zielpfade und Ergebnisse von Platzhaltererweiterungen.
  • Gehen Sie nicht davon aus, dass Protokolle aufbewahrt werden; überprüfen Sie stattdessen die tatsächlichen Einstellungen und Aufbewahrungsrichtlinien von PAM, Journal- und Authentifizierungsprotokollen.

Befehle, die nach dem Öffnen einer Root-Shell mit su ausgeführt werden, sind getrennt von den Authentifizierungsaufzeichnungen von su selbst. Wenn eine individuelle Befehlsüberwachung erforderlich ist, sollten Sie diese zusammen mit Shell-Auditing, zentralisiertem Logging oder Methoden wie sudo planen, die pro-Befehl-Richtlinien bereitstellen.

Häufige Probleme und Lösungen

Symptome Mögliche Ursache Wie zu prüfen
Authentication failure Ziel-Passwortfehler, Kontosperrung oder PAM-Einschränkungen Überprüfen Sie das Zielkonto und die Authentifizierungsrichtlinie/Protokolle
Befehl kann nach dem Wechsel nicht gefunden werden Der PATH des Zielbenutzers ist unterschiedlich Überprüfen Sie command -v und printf '%s\n' "$PATH"
Das Heimatverzeichnis ändert sich nicht Verwenden Sie su user ohne Login-Option Verwenden Sie su --login user
Benutzereinstellungen scheinen gemischt zu sein Verwenden Sie reguläres su, das teilweise die bestehende Umgebung beibehält Überprüfen Sie env, HOME, USER
Die angegebene Shell wird nicht ausgeführt Eingeschränkte Shell oder Aufrufberechtigungseinschränkung Überprüfen Sie getent passwd und /etc/shells

Häufig gestellte Fragen

Wessen Passwort geben Sie für su ein?

Im Allgemeinen geben Sie das Passwort des Zielbenutzers ein, zu dem Sie wechseln möchten. Wenn root es jedoch ausführt oder PAM-Richtlinien unterschiedliche Authentifizierungsmethoden verwenden, kann das Verhalten variieren. Es ist normal, dass während der Passworteingabe keine Zeichen auf dem Bildschirm angezeigt werden.

Was ist der Unterschied zwischen su und su -?

su startet eine Root-Shell, während das aktuelle Verzeichnis und ein Teil der Umgebung beibehalten werden. su - wechselt in das Home-Verzeichnis des Root-Benutzers und richtet die Anmeldeumgebung ein. In util-linux wird die Login-Variante empfohlen, um das Vermischen von Umgebungen zu reduzieren.

Wie überprüft man den aktuellen Benutzer, nachdem man mit su gewechselt hat?

id ist nützlich, um sowohl reale als auch effektive Benutzer und Gruppen zusammen zu prüfen. Wenn Sie nur einen einfachen Benutzernamen benötigen, können Sie whoami verwenden, aber um zusätzliche Gruppen zu prüfen, liefert id mehr Informationen.

Ist es in Ordnung, das Passwort von su im Skript zu speichern?

Nein. Das Passwort kann in Dateien, Prozessinformationen oder Protokollen offengelegt werden. Wenn die Automatisierung als Root erfolgt, entwerfen Sie eine Methode unter Verwendung eines eingeschränkten runuser. Wenn es für die Rechteerweiterung als normaler Benutzer ist, entwerfen Sie eine Möglichkeit, die das Passwort nicht einbettet, wie z. B. minimale Privilegienregelungen in sudoers oder einen dedizierten Dienst für die Aufgabe.

Zusammenfassung

Für allgemeines interaktives Benutzerwechseln können Sie su --login user verwenden, und für einen einzelnen Befehl su -c 'command' user. Ein einfaches su user kann Umgebungen vermischen, daher ist es gut, id, HOME und pwd nach dem Wechsel zu überprüfen.

Wenn das Ziel darin besteht, nur einen Root-Befehl auszuführen, kann sudo, das eine Berechtigungskontrolle und Protokollierung pro Befehl bietet, geeigneter sein. Wenn Sie als ein anderer Benutzer in der Root-Automatisierung arbeiten, beachten Sie runuser. Sie können auch verwandte Basiswerkzeuge zusammen in der Liste der häufig verwendeten Befehle in Linux überprüfen.