Kategorie: Linux / Server / Plesk

Wer seinen eigenen Linux-Server mit Plesk (insbesondere der Web Admin Edition) verwaltet, kennt das Szenario: Man möchte einer neu angelegten Domain oder einem Systembenutzer vollen SSH-Zugriff über /bin/bash gewähren. Man wählt die Shell im Dropdown-Menü aus, klickt auf Speichern – und rennt prompt in diese Fehlermeldung:

„Error: no secure shell available“

Das Kuriose daran: Die Bash-Shell existiert natürlich auf dem Server, und als Root-User kann man sich völlig problemlos via SSH einloggen. Warum blockiert Plesk also im Web-Interface und wie biegt man das wieder gerade?

Warum passiert das überhaupt?

Der Fehler liegt weder an Apache noch an nginx. Schuld ist ein Sicherheits-Feature namens Site Isolation (Website-Isolierung), das Plesk in neueren Versionen standardmäßig sehr restriktiv einstellt.

Bei der Web Admin Edition geht Plesk davon aus, dass der Admin ohnehin direkt auf der Konsole arbeitet und normale Webspace-Benutzer aus Sicherheitsgründen keine mächtige Shell auf dem restlichen Server erhalten sollten. Daher sperrt das System die Zuweisung im Hintergrund komplett.

Das Problem dabei: Das Web-Interface ist hier extrem unlogisch designt. Es bietet dir die Auswahl von /bin/bash zwar an, läuft dann aber beim Speichern gegen eine interne Wand und wirft diesen kryptischen Fehler, statt direkt zu sagen, wo es hakt. Da die Web Admin Edition zudem die globalen Rechtemenüs im Interface ausblendet, lässt sich die Sperre nicht einfach per Klick aufheben.

Exkurs: /bin/bash vs. chrootsh – Wo ist der Unterschied?

In den Standardeinstellungen von Plesk stolpert man oft über den Begriff chrootsh. Warum wehrt sich das System so sehr gegen die normale /bin/bash? Es ist eine Frage der Sicherheit:

• /bin/bash (Die vollwertige Shell): Bekommt ein Webspace-User diesen Zugriff, kann er sich nach dem SSH-Login frei auf dem gesamten Server umsehen. Er kann zwar (dank Linux-Rechteverwaltung) die Dateien anderer User meist nicht bearbeiten oder löschen, aber er sieht die Verzeichnisstruktur, installierte Pakete und globale Konfigurationen. Für den Admin selbst ist das oft notwendig, für fremde Kundenkonnten jedoch ein potenzielles Sicherheitsrisiko.
• /opt/psa/bin/chrootsh (Die eingesperrte Shell): Chroot steht für „change root“ (Wurzelverzeichnis ändern). Dieser Mechanismus sperrt den Benutzer in ein virtuelles Gefängnis – exakt in sein eigenes Webspace-Verzeichnis (z. B. /var/www/vhosts/deine-domain.de/). Für diesen User existiert der restliche Server schlichtweg nicht. Er sieht nur seine eigenen Dateien und kann auch nur die Befehle ausführen, die Plesk explizit in dieses „Gefängnis“ kopiert hat (z. B. eine abgespeckte PHP- oder Git-Umgebung).

Da bei einer frischen Plesk-Installation standardmäßig selbst die restriktive chrootsh nicht explizit freigegeben ist, blockiert das System jegliche Zuweisung komplett.

Die Lösung: Die Sperre auf dem Server aufheben

Um das Problem zu lösen, müssen wir die Konfiguration dort anpassen, wo der Admin zu Hause ist: auf der Linux-Konsole.

Schritt 1: Per SSH einloggen

Verbinde dich als root via SSH mit deinem Server.

Schritt 2: Die Konfigurationsdatei anpassen

Die Sicherheitsrichtlinie wird in einer Konfigurationsdatei von Plesk geregelt. Wir öffnen diese Datei mit dem Texteditor nano:

Bash

nano /usr/local/psa/admin/conf/site_isolation_settings.ini

Wenn du in die Datei schaust, siehst du im Abschnitt [hosting] verschiedene Optionen, die alle mit einem Semikolon ; beginnen. Das bedeutet, sie sind auskommentiert (inaktiv), weshalb der harte Plesk-Standard greift.

Suche nach der Zeile:

Ini, TOML

;;shell = /opt/psa/bin/chrootsh

Ändere diese Zeile so ab, dass die Einschränkung komplett aufgehoben wird, und entferne die Semikolons am Anfang, um die Option aktiv zu schalten:

Ini, TOML

shell = any

Hinweis: Mit shell = any erlaubst du Plesk, jede im System verfügbare Shell (also auch deine gewünschte /bin/bash) im Web-Interface ohne Meckern zu akzeptieren.

Speichere die Datei in Nano mit STRG+O (mit Enter bestätigen) und verlasse den Editor mit STRG+X.

Schritt 3: Plesk-Dienst neu starten

Damit Plesk die geänderten Rechte übernimmt, musst du den Plesk-Verwaltungsdienst (sw-engine) einmal kurz neu starten. Keine Sorge, deine Webseiten bleiben dabei komplett online:

Bash

systemctl restart sw-engine

Fazit

Wenn du jetzt zurück in dein Plesk-Interface gehst und die Domain mit /bin/bash anlegst oder bearbeitest, speichert das System die Einstellung sofort klaglos ab.

Manchmal sind es die kleinsten, auskommentierten Zeilen in den Tiefen des Systems, die einen stundenlang beschäftigen können. Mit diesem Handgriff hast du die Kontrolle über deine Shell-Zuweisungen dauerhaft zurück und kannst deinen Systembenutzern genau den Zugriff geben, den sie für ihre Arbeit benötigen!

Haftungsausschluss (Disclaimer)

Hinweis zur Haftung:

Die Bearbeitung von Systemkonfigurationen auf Linux-Servern erfolgt immer auf eigene Gefahr. Dieser Artikel wurde nach bestem Wissen und Gewissen verfasst und beschreibt eine praxiserprobte Lösung. Dennoch übernehme ich keine Haftung für eventuelle Schäden, Datenverluste oder Serverausfälle, die durch die Umsetzung dieser Anleitung entstehen können. Stellt vor jeder Änderung an Systemdateien sicher, dass ihr ein aktuelles Backup eures Servers bzw. der entsprechenden Konfigurationsdateien parat habt

Aufrufe: 16 Views