QGIS PostGIS SSH-tunnel: behåll servernamnet för TLS

En SSH-vidarebefordran ger QGIS en lokal port, men databasen behöver fortfarande sitt riktiga namn för TLS. Använd en libpq-tjänst med hostaddr och en loopback-lyssnare.

Tunneln kommer upp, QGIS ansluter och inloggningen dör med ett certifikatfel som anger 127.0.0.1 i stället för databasvärden. Nästa frestande steg är att lätta på sslmode, vilket tystar kontrollen och kastar bort identitetsgarantin du faktiskt ville ha. Det verkliga problemet är att den lokala porten och serverns namn lagras i samma fält. En libpq-tjänstepost skiljer dem, så socketen går till den vidarebefordrade porten medan TLS fortfarande verifierar namnet som tryckts på certifikatet.

Vad klienten tror att den ansluter till

Under sslmode=verify-full jämför libpq certifikatet servern presenterar med det värdnamn som efterfrågades. När namnet är en loopback-adress misslyckas jämförelsen även om certifikatet är giltigt för den riktiga databasvärden. SSH-vidarebefordran ändrar vilken socket som bär byten, inte den identitet klienten bör förvänta sig. När de två idéerna skiljs åt ser felet inte längre ut som ett TLS-fel.

En vidarebefordran är inte heller någon auktorisering. PostgreSQL tillämpar fortfarande sina egna regler på anslutningen som SSH-servern skapar, så håll transportlagret och databaslagret åtskilda innan du ändrar något.

Bind vidarebefordran endast till loopback

Lyssnaren bör finnas på QGIS-maskinen och ingen annanstans. Att uttryckligen nämna 127.0.0.1 håller den borta från andra gränssnitt, medan en utelämnad bindadress kan exponera porten beroende på SSH-klientens gateway-inställningar.

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

Målet efter det andra kolontecknet löses upp från SSH-serverns sida, så detta exempel antar att PostgreSQL finns på samma värd som sshd; en databas på en annan maskin behöver den adressen och dess behörigheter. Kör sessionen med -N så att inget skal öppnas, låt värdnyckelverifieringen vara och bekräfta att lyssnaren dyker upp innan du skyller på QGIS. Om porten redan används misslyckas vidarebefordran vid start och inte vid frågan.

Sätt namnet och socketen i en enda tjänstepost

En tjänstefil låter samma anslutning bära ett verifieringsnamn och ett annat socketmål. Spara posten där libpq letar efter tjänster, eller peka PGSERVICEFILE mot den.

[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

Här behåller host identiteten som används för certifikatkontroller, medan hostaddr skickar paketen till den vidarebefordrade loopback-porten, och båda behövs för att den här ordningen ska fungera. gssencmode=disable spelar roll i byggen som annars först skulle förhandla GSSAPI-kryptering, eftersom den vägen ignorerar de TLS-inställningar som just satts. Hänvisa till tjänsten vid namn från QGIS PostgreSQL-anslutningsdialog och ange lösenordet via den vanliga uppmaningen, inte i en delad fil. Namnen och sökvägarna ovan är platshållare; ersätt dem med dina egna godkända värden.

Vad PostgreSQL fortfarande kontrollerar efter tunneln

Servern ser en anslutning från SSH-värden, loopback i den här ordningen, och matchar den i tur och ordning mot värdbaserade autentiseringsregler. Din databasroll måste fortfarande autentisera sig, och SSH-inloggningen ger ingen databasidentitet i sig. Verifiera vad servern tror, inte vad klienten antog.

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

Stäng vidarebefordringssessionen när arbetet är klart; den lokala posten slutar då fungera och inget annat ändras. En databasväg är inte en VPN för hela GIS-klienten, och att behandla den som en är hur nästa anslutning feldiagnostiseras.

Relaterade artiklar