QGIS PostGIS SSH-tunnel: hald på servernamnet for TLS

Ei SSH-vidaresending gjev QGIS ein lokal port, men databasen treng framleis det verkelege namnet sitt for TLS. Bruk ein libpq-teneste med hostaddr og ein loopback-lyttar.

Tunnelen kjem opp, QGIS koplar til, og innlogginga døyr med ein sertifikatfeil som nemner 127.0.0.1 i staden for databaseverten. Det freistande neste trekket er å lempe på sslmode, som dempar kontrollen og kastar bort identitetsgarantien du i utgangspunktet ville ha. Det eigentlege problemet er at den lokale porten og namnet på serveren blir lagra i same felt. Ein libpq-tenestepost skil dei, slik at socketen går til den vidaresende porten medan TLS framleis stadfester namnet som er trykt på sertifikatet.

Kva klienten trur han koplar til

Under sslmode=verify-full samanliknar libpq sertifikatet serveren legg fram med vertsnamnet det vart spurt etter. Når namnet er ei loopback-adresse, feilar samanlikninga sjølv om sertifikatet er gyldig for den verkelege databaseverten. SSH-vidaresendinga endrar kva socket som ber byta, ikkje identiteten klienten bør vente. Når dei to tinga blir skilde, ser feilen ikkje lenger ut som ein TLS-feil.

Ei vidaresending er heller ikkje autorisasjon. PostgreSQL nyttar framleis sine eigne reglar på tilkoplinga SSH-serveren lagar, så hald transportlaget og databaselaget fråskilde før du endrar noko.

Bind vidaresendinga berre til loopback

Lyttaren bør finnast på QGIS-maskinen og ingen andre stader. Å nemne 127.0.0.1 eksplisitt held han unna andre grensesnitt, medan ei utelaten bind-adresse kan eksponere porten avhengig av gateway-innstillingane til SSH-klienten.

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

Destinasjonen etter det andre kolonet blir løyst frå sida til SSH-serveren, så dette dømet går ut frå at PostgreSQL er på same vert som sshd; ein database på ein annan maskin treng den adressa og løyva hennar. Køyr økta med -N slik at ingen skal opnast, lat vertsnøkkelstadfestinga vere og stadfest at lyttaren dukkar opp før du klandrar QGIS. Viss porten alt er i bruk, feilar vidaresendinga ved oppstart og ikkje ved spørjinga.

Set namnet og socketen i éin tenestepost

Ei tenestefil lèt same tilkopling bere eit stadfestingsnamn og ein annan socket-destinasjon. Lagre posten der libpq leitar etter tenester, eller peik PGSERVICEFILE mot han.

[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 held host på identiteten som blir brukt til sertifikatkontrollar, medan hostaddr sender pakkane til den vidaresende loopback-porten, og begge trengst for at denne ordninga skal verke. gssencmode=disable tyder noko på bygg som elles ville forhandle GSSAPI-kryptering først, fordi den vegen ignorerer TLS-innstillingane som nettopp vart sette. Vis til tenesta ved namn frå PostgreSQL-tilkoplingsdialogen i QGIS og oppgje passordet via den vanlege førespurnaden, ikkje inne i ei delt fil. Namna og stigane over er plasshaldarar; byt dei ut med dine eigne godkjende verdiar.

Kva PostgreSQL framleis kontrollerer etter tunnelen

Serveren ser ei tilkopling frå SSH-verten, loopback i denne ordninga, og matchar ho mot vertsbaserte autentiseringsreglar i rekkjefølgje. Databaserolla di må framleis autentisere seg, og SSH-innlogginga gjev inga databaseidentitet i seg sjølv. Stadfest kva serveren trur, ikkje kva klienten antok.

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

Lat vidaresendingsøkta att når arbeidet er ferdig; den lokale posten sluttar då å verke og ingenting anna endrar seg. Éin databaseveg er ikkje ein VPN for heile GIS-klienten, og å handsame han som ein er korleis neste tilkopling blir feildiagnostisert.

Relaterte artiklar