SSH für Linux-Ziele

Bei Nginx, Apache, HAProxy und Tomcat schreibt der SSH-Benutzer die Zertifikate nur über Least-Privilege-Wrapper. Das Helper-Skript des Tabs Helper installiert sie für jedes Deployment. Bei PostgreSQL, MySQL und Linux File Path schreibt das Helper-Skript stattdessen die Datei /etc/sudoers.d/tlspilot-<service>. Sie erlaubt mkdir, install, rm, stat, chown, systemctl und die Reload-Tools des Dienstes als root, ohne ihre Argumente einzuschränken. Das ist kein uneingeschränktes sudo, kommt root aber nahe; verwenden Sie diese Ziele nur auf Hosts, auf denen das akzeptabel ist. Für diese Ziele erstellt das Skript zudem den SSH-Benutzer, falls er nicht existiert, fügt ihn der Gruppe ssl-cert und der Gruppe der Dateien hinzu und führt die abschliessende Prüfung mit sudo -l nicht aus.

1. Erstellen Sie einen eigenen Dienstbenutzer ohne interaktives Passwort, zum Beispiel sudo useradd -m -s /bin/bash tlspilot. Best Practice: ein Benutzer pro Zweck, nie root. Das Helper-Skript für Nginx, Apache, HAProxy und Tomcat erstellt diesen Benutzer nicht und bricht ab, wenn er nicht existiert.
2. Verwenden Sie die Anmeldung per Schlüssel. Erstellen Sie das Schlüsselpaar, speichern Sie den privaten Schlüssel im PEM-Format im Credential vom Typ Linux SSH und fügen Sie den öffentlichen Schlüssel zu ~tlspilot/.ssh/authorized_keys hinzu (Berechtigungen 700 für .ssh, 600 für die Datei).
3. Öffnen Sie im Deployment den Tab Helper. Show flow visualization zeigt, was bei der Einrichtung, beim ersten Deployment und bei jeder Erneuerung geschieht. Klicken Sie auf Show script…, kopieren Sie das Skript auf den Linux-Host und führen Sie es einmal als root aus. TLSPilot führt dieses Skript nicht über SSH aus. Jedes Deployment hat sein eigenes Skript; führen Sie also das Skript jedes Deployments einmal aus. Das Skript lässt sich gefahrlos erneut ausführen. Meldet der Dry Run Paths changed, führen Sie das Skript erneut aus.
4. Bei Nginx, Apache, HAProxy und Tomcat schreibt das Skript Folgendes, wobei <service> für nginx, apache, haproxy oder tomcat steht und <id> das Deployment bezeichnet:
   • /usr/local/sbin/tlspilot-<service>-<id>: der Wrapper, der die Zertifikatsdateien schreibt und den Dienst aktiviert.
   • /usr/local/sbin/tlspilot-<service>-discover: der Discover-Wrapper, der für den Tab Discovery die Konfiguration des Dienstes und die darin genannten Zertifikate liest.
   • /etc/sudoers.d/tlspilot-lp-<service>-<id> erlaubt nur diesen Wrapper, und /etc/sudoers.d/tlspilot-lp-<service>-discover erlaubt nur den Discover-Wrapper. Jede Datei wird mit visudo geprüft und zurückgesetzt, wenn die Prüfung fehlschlägt.
   • Am Ende prüft das Skript mit sudo -l, ob der SSH-Benutzer nur Wrapper-Aktionen ausführen darf. Hat der Benutzer weitere sudo-Regeln, zum Beispiel in /etc/sudoers oder über eine Gruppenregel, oder ist er Mitglied der Gruppe sudo, wheel oder admin, bricht das Skript mit einem Fehler ab. Entfernen Sie diese Rechte und führen Sie es erneut aus.
5. Schalten Sie auf dem Tab Configuration den Schalter Least-privilege wrapper is installed ein, sobald das Skript gelaufen ist. Ist der Schalter aus, verteilt TLSPilot direkt ohne Wrapper. Das funktioniert mit root oder vollen sudo-Rechten, auf einem gehärteten Host, auf dem der SSH-Benutzer nur über den Wrapper schreiben darf, schlägt das Deployment aber fehl. Ist der Schalter ein und der Wrapper auf dem Host nicht installiert, bricht das Deployment mit dem Fehler The wrapper … is not installed or not allowed for <user>. Run the helper script as root on the host. ab.
6. Zwei optionale Schalter auf dem Tab Configuration erweitern das Skript. Beide sind standardmässig aus:
   • Remove existing sudoers rights and group memberships: Das Skript verschiebt ältere TLSPilot-Dateien in /etc/sudoers.d/ in einen Backup-Ordner unter /var/lib/tlspilot/ und entfernt den SSH-Benutzer aus Gruppen wie ssl-cert, nginx, www-data, haproxy oder tomcat. Die sudoers-Dateien tlspilot-lp-* der Wrapper bleiben erhalten. Existieren auf dem Host sudoers-Dateien von PostgreSQL-, MySQL- oder Linux-File-Path-Zielen, bricht das Skript ab, da diese Ziele statt eines Wrappers ihre eigene sudoers-Datei verwenden.
   • Make the SSH account key-only: Das Skript beschränkt den SSH-Benutzer in der Konfiguration des SSH-Servers auf die Anmeldung per Schlüssel: kein Passwort, kein Forwarding und kein Terminal. Es prüft die Konfiguration mit sshd -t, setzt sie bei einem Fehler zurück und lädt den SSH-Dienst neu. Das funktioniert nur mit einem Schlüssel-Credential. Mit einem Passwort-Credential lässt der Helper die Passwort-Anmeldung aktiviert: This credential is not a key. The helper leaves password login enabled.
7. Erlauben Sie TCP 22 bzw. Ihren SSH-Port nur vom Management-Host.
8. Führen Sie Test (dry run)… aus.

Der Tab Helper eines Linux-Deployments zeigt die benötigten Berechtigungen und was das Helper-Skript schreibt, siehe Abbildung Tab Helper eines Nginx-Deployments mit dem Least-Privilege-Wrapper.