QGIS-PostGIS-SSH-Tunnel: den Servernamen für TLS behalten

Eine SSH-Weiterleitung gibt QGIS einen lokalen Port, doch die Datenbank braucht für TLS weiterhin ihren echten Namen. Nutzen Sie einen libpq-Dienst mit hostaddr und einem Loopback-Listener.

Der Tunnel steht, QGIS verbindet, und die Anmeldung stirbt mit einem Zertifikatsfehler, der 127.0.0.1 statt des Datenbankhosts nennt. Der verlockende nächste Schritt ist, sslmode zu lockern, was die Prüfung stumm schaltet und die Identitätsgarantie wegwirft, die Sie überhaupt wollten. Das eigentliche Problem ist, dass der lokale Port und der Name des Servers im selben Feld gespeichert werden. Ein libpq-Diensteintrag trennt beides, sodass der Socket auf den weitergeleiteten Port geht, während TLS weiterhin den auf dem Zertifikat gedruckten Namen prüft.

Womit der Client sich zu verbinden glaubt

Unter sslmode=verify-full vergleicht libpq das vom Server vorgelegte Zertifikat mit dem Hostnamen, der angefragt wurde. Ist dieser Name eine Loopback-Adresse, schlägt der Vergleich fehl, obwohl das Zertifikat für den echten Datenbankhost gültig ist. Die SSH-Weiterleitung ändert, welcher Socket die Bytes trägt, nicht die Identität, die der Client erwarten sollte. Sobald diese beiden Vorstellungen getrennt sind, sieht der Fehler nicht mehr wie ein TLS-Defekt aus.

Eine Weiterleitung ist auch keine Autorisierung. PostgreSQL wendet weiterhin seine eigenen Regeln auf die Verbindung an, die der SSH-Server aufbaut, also halten Sie Transportschicht und Datenbankschicht getrennt, bevor Sie etwas ändern.

Binden Sie die Weiterleitung nur an Loopback

Der Listener sollte auf der QGIS-Maschine existieren und nirgendwo sonst. 127.0.0.1 ausdrücklich zu nennen hält ihn von anderen Schnittstellen fern, während eine weggelassene Bind-Adresse den Port je nach Gateway-Einstellungen des SSH-Clients offenlegen kann.

ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 [email protected]

Das Ziel nach dem zweiten Doppelpunkt wird von der Seite des SSH-Servers aufgelöst, daher nimmt dieses Beispiel an, dass PostgreSQL auf demselben Host wie sshd läuft; eine Datenbank auf einer anderen Maschine braucht jene Adresse und ihre Berechtigungen. Starten Sie die Sitzung mit -N, damit keine Shell geöffnet wird, lassen Sie die Host-Key-Prüfung in Ruhe und bestätigen Sie, dass der Listener erscheint, bevor Sie QGIS beschuldigen. Ist der Port bereits belegt, scheitert die Weiterleitung beim Start und nicht erst bei der Abfrage.

Stecken Sie Namen und Socket in einen Diensteintrag

Eine Dienstdatei lässt dieselbe Verbindung einen Prüfnamen und ein anderes Socket-Ziel tragen. Speichern Sie den Eintrag dort, wo libpq nach Diensten sucht, oder richten Sie PGSERVICEFILE darauf.

[gis-via-ssh]
host=db.geo.example
hostaddr=127.0.0.1
port=15432
dbname=gisdb
user=gis_reader
sslmode=verify-full
gssencmode=disable
sslrootcert=/path/to/approved-root.crt

Hier behält host die für Zertifikatsprüfungen verwendete Identität, während hostaddr Pakete an den weitergeleiteten Loopback-Port schickt, und beides ist nötig, damit diese Anordnung funktioniert. gssencmode=disable ist bei Builds wichtig, die sonst zuerst GSSAPI-Verschlüsselung aushandeln würden, weil dieser Pfad die gerade gesetzten TLS-Einstellungen ignoriert. Verweisen Sie im PostgreSQL-Verbindungsdialog von QGIS per Namen auf den Dienst und geben Sie das Passwort über die normale Abfrage ein, nicht in einer gemeinsam genutzten Datei. Die Namen und Pfade oben sind Platzhalter; ersetzen Sie sie durch Ihre eigenen freigegebenen Werte.

Was PostgreSQL nach dem Tunnel noch prüft

Der Server sieht eine Verbindung vom SSH-Host, in dieser Anordnung Loopback, und gleicht sie der Reihe nach mit den hostbasierten Authentifizierungsregeln ab. Ihre Datenbankrolle muss sich weiterhin authentifizieren, und die SSH-Anmeldung verleiht für sich genommen keine Datenbankidentität. Prüfen Sie, was der Server annimmt, statt was der Client vermutet hat.

psql "service=gis-via-ssh" -c "select inet_server_addr(), current_user"

Schließen Sie die Weiterleitungssitzung, wenn die Arbeit erledigt ist; der lokale Eintrag funktioniert dann nicht mehr, und sonst ändert sich nichts. Ein Datenbankpfad ist kein VPN für den ganzen GIS-Client, und ihn als eines zu behandeln, ist der Grund, warum die nächste Verbindung falsch diagnostiziert wird.

Ähnliche Artikel