- Einleitung
- Benutzerverwaltung
- Virtual Host mit eigenem Benutzer einrichten
- Superuser erstellen mit Vollzugriff auf alle Webroots
Einleitung
Auf nine.ch Managed (V)Servern kommt standardmässig nine-manage-vhosts
zur Verwaltung von Websites zum Einsatz. Damit können Websites auf dem Server konfiguriert werden. nine.ch unterstützt auch die Verwendung von FPM und entsprechend verschiedener Benutzer.
In diesem Dokument wird die Verwendung der Benutzerverwaltung von nine-manage-vhosts
beschrieben.
Benutzerverwaltung
Um die Sicherheit für Webapplikationen zu erhöhen, können diese mit separaten Systembenutzern voneinander getrennt werden. Bei der Bestellung des Servers richtet nine.ch standardmässig nur den Benutzer www-data
ein, die Benutzerverwaltung wird auf Wunsch hinzugefügt. Bitte beachten Sie das ein Umbau auf FPM je nachdem zu grösseren Anpassungen oder sogar Downtimes führen können.
Mit der Benutzerverwaltung von nine-manage-vhosts werden Benutzer nach folgendem Schema verwaltet:
www-data@server:~ $ sudo nine-manage-vhosts user <action>...
Als Aktion stehen create
, update
, remove
und list
zur Verfügung. Letzteres gibt eine Liste der aktuell bestehenden Benutzer aus:
www-data@server:~ $ sudo nine-manage-vhosts user list
NAME | HOMEDIR
------------|------------------
www-data | /home/www-data
www-example | /home/www-example
Beim Erstellen (create
) oder Aktualisieren (update
) eines Benutzers stehen drei passwortbezogene Optionen zur Verfügung:
www-data@server:~ $ sudo nine-manage-vhosts user create www-example --no-password
www-data@server:~ $ sudo nine-manage-vhosts user create www-example --ask-password
www-data@server:~ $ sudo nine-manage-vhosts user create www-example --password=<password>
Mit der Option --no-password
wird kein Passwort gesetzt und der Benutzer kann sich nicht per SSH oder SFTP einloggen. Dies ist nützlich, wenn man das Anmelden über SSH/SFTP zugunsten einem FTP-Zugang deaktivieren möchte. Aus Sicherheitsgründen empfehlen wir nur bei absolut zwingenden Zugriffen ein Passwort zu setzen und damit entsprechenden Shell-Zugang zu gewähren.
Mit --ask-password
fragt das Skript nach der Eingabe eines Passwortes und mittels --password
kann ein Passwort direkt auf der Kommandozeile angegeben werden. Letzteres erleichtert das Erstellen mehrerer Benutzer mit einem eigenen Skript.
Virtual Host mit eigenem Benutzer einrichten
Um einem VirtualHost beim Erstellen einen bestimmten Benutzer zuzuweisen, gibt man den Benutzer über die Option --user
wie folgt an:
www-data@server:~ $ sudo nine-manage-vhosts virtual-host create example.org
--user=www-example
In diesem Beispiel wird der VirtualHost mit der Domain example.org
und dem Benutzer www-example
im Ordner /home/www-example/example.org
erstellt.
Superuser erstellen mit Vollzugriff auf alle Webroots
SSH-Key generieren
Der Benutzer www-data dient in unserem Beispiel als der Superuser.
Generiere als Benutzer www-data einen neuen Private- und Publickey ohne ein Passwort.
www-data@server:~ $ ssh-keygen -o -a 100 -t ed25519 -N "" -C "www-data@server"
Verteile den Public key in den gewünschten Webroots
Der Public Key der vorher generiert wurde durch uns, wird nun unter alle gewünschten Webroots im Verzeichnis ~/.ssh/authorized_keys kopiert.
Der Inhalt der Datei sollte wie folgt aussehen:
www-*@server:~ $ cat ~/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NBBBBAAAILeD/udlOxZZuNNNNNNNNNu5L1+wM/spA5JzYNKH www-data@server
Verbindung austesten
Mit folgendem Befehl kann die Verbindung zu allen gewünschten Multi-Usern getestet werden:
www-data@server:~ $ ssh www-*@localhost
ACHTUNG! Der Private SSH-Schlüssel soll geschützt werden und nicht verteilt! Er ist nicht verschlüsselt und hat keinen Passwortschutz. Es kann zu einem schwerwiegenden Sicherheitsvorfall führen, wenn der Private SSH Schlüssel gestohlen wird.
Speziell zu Beachten:
- Wenn PuTTY oder WinSCP als Clientprogramme verwendet werden, muss der SSH Schlüssel vorher ins PPK Format verwandelt werden mittels PuTTYgen.
- Der Private SSH Schlüssel unter ~www-data/.ssh/id_ed25519 muss die Zugriffseinstellung “600” besitzen. Ansonsten werden die SSH Verbindungen auf die anderen Webroots fehlschlagen.