QGIS PostGIS SSH-tunnel: behold servernavnet for TLS

En SSH-videresending gir QGIS en lokal port, men databasen trenger fortsatt sitt virkelige navn for TLS. Bruk en libpq-tjeneste med hostaddr og en loopback-lytter.

Tunnelen kommer opp, QGIS kobler til, og innloggingen dør med en sertifikatfeil som nevner 127.0.0.1 i stedet for databaseverten. Det fristende neste trekket er å lempe på sslmode, som demper kontrollen og kaster bort identitetsgarantien du i utgangspunktet ønsket. Det egentlige problemet er at den lokale porten og serverens navn lagres i samme felt. En libpq-tjenestepost skiller dem, slik at socketen går til den videresendte porten mens TLS fortsatt verifiserer navnet som er trykt på sertifikatet.

Hva klienten tror den kobler til

Under sslmode=verify-full sammenligner libpq sertifikatet serveren legger fram med vertsnavnet det ble spurt etter. Når navnet er en loopback-adresse, feiler sammenligningen selv om sertifikatet er gyldig for den virkelige databaseverten. SSH-videresendingen endrer hvilken socket som bærer bytene, ikke identiteten klienten bør forvente. Når de to tingene skilles, ser feilen ikke lenger ut som en TLS-feil.

En videresending er heller ikke autorisasjon. PostgreSQL bruker fortsatt sine egne regler på tilkoblingen SSH-serveren lager, så hold transportlaget og databaselaget atskilt før du endrer noe.

Bind videresendingen bare til loopback

Lytteren bør finnes på QGIS-maskinen og ingen andre steder. Å nevne 127.0.0.1 eksplisitt holder den unna andre grensesnitt, mens en utelatt bind-adresse kan eksponere porten avhengig av SSH-klientens gateway-innstillinger.

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

Destinasjonen etter det andre kolonet løses fra SSH-serverens side, så dette eksempelet antar at PostgreSQL er på samme vert som sshd; en database på en annen maskin trenger den adressen og tillatelsene dens. Kjør økten med -N slik at ingen skall åpnes, la vertsnøkkelverifiseringen være og bekreft at lytteren dukker opp før du klandrer QGIS. Hvis porten allerede er i bruk, feiler videresendingen ved oppstart og ikke ved spørringen.

Sett navnet og socketen i én tjenestepost

En tjenestefil lar samme tilkobling bære et verifiseringsnavn og en annen socket-destinasjon. Lagre posten der libpq leter etter tjenester, eller pek 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

Her beholder host identiteten som brukes til sertifikatkontroller, mens hostaddr sender pakkene til den videresendte loopback-porten, og begge trengs for at denne ordningen skal virke. gssencmode=disable betyr noe på bygg som ellers ville forhandle GSSAPI-kryptering først, fordi den veien ignorerer TLS-innstillingene som nettopp ble satt. Referer til tjenesten ved navn fra QGIS’ PostgreSQL-tilkoblingsdialog og oppgi passordet via den vanlige forespørselen, ikke inne i en delt fil. Navnene og stiene over er plassholdere; erstatt dem med dine egne godkjente verdier.

Hva PostgreSQL fortsatt kontrollerer etter tunnelen

Serveren ser en tilkobling fra SSH-verten, loopback i denne ordningen, og matcher den mot vertsbaserte autentiseringsregler i rekkefølge. Databaserollen din må fortsatt autentisere seg, og SSH-innloggingen gir ingen databaseidentitet i seg selv. Verifiser hva serveren tror, ikke hva klienten antok.

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

Lukk videresendingsøkten når arbeidet er ferdig; den lokale posten slutter da å virke og ingenting annet endres. Én databasevei er ikke en VPN for hele GIS-klienten, og å behandle den som en er hvordan neste tilkobling blir feildiagnostisert.

Relaterte artikler