SSH-tunnel for QGIS og PostGIS: ta vare på servernavnet for TLS

SSH-viderekobling gir QGIS en lokal port, men databasen trenger likevel sitt ekte navn for TLS. Ta i bruk en libpq-tjeneste med hostaddr og en lytter på loopback.

Tunnelen er oppe, QGIS kobler seg til, og påloggingen ryker med en sertifikatfeil som oppgir 127.0.0.1 i stedet for databasens vert. Det er fristende å myke opp sslmode, noe som gjør kontrollen taus og kaster bort identitetsgarantien du ønsket. Den virkelige årsaken er at den lokale porten og navnet til serveren ligger i samme felt. En tjenestepost i libpq holder dem fra hverandre, slik at forbindelsen går til den videresendte porten mens TLS fortsatt sjekker navnet som står på sertifikatet.

Hva klienten innbiller seg at den kobler til

Med sslmode=verify-full sammenligner libpq sertifikatet fra serveren med vertsnavnet som ble spurt etter. Er navnet en loopback-adresse, slår sammenligningen feil selv om sertifikatet gjelder den ekte databaseverten. SSH-viderekoblingen endrer hvilken socket som frakter bytene, ikke identiteten klienten skal forvente. Når disse to tingene skilles, ser feilen ikke ut som en TLS-svikt lenger.

Viderekobling er heller ingen autorisasjon. PostgreSQL bruker fortsatt sine egne regler på forbindelsen SSH-serveren oppretter, så hold transportlaget og databaselaget atskilt før du endrer noe.

Knytt viderekoblingen til loopback alene

Lytteren skal bare finnes på QGIS-maskinen. Å skrive 127.0.0.1 uttrykkelig holder den borte fra andre grensesnitt, mens en utelatt bind-adresse kan legge porten åpen ut fra gateway-oppsettet til SSH-klienten.

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

Målet etter det andre kolonet løses opp på SSH-serversiden, så dette eksempelet forutsetter at PostgreSQL ligger på samme vert som sshd; en database på en annen maskin trenger den adressen og rettighetene dens. Start økten med -N slik at det ikke åpnes noe skall, la vertsnøkkelkontrollen være og bekreft at lytteren dukker opp før du gir QGIS skylden. Er porten allerede opptatt, feiler viderekoblingen ved oppstart og ikke ved spørringen.

Legg navnet og socketen i én tjenestepost

En tjenestefil lar samme tilkobling bære et kontrollnavn og et annet socketmål. Lagre posten der libpq leter etter tjenester, eller pek PGSERVICEFILE dit.

[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 ved sertifikatkontroller, mens hostaddr sender pakkene til den videresendte loopback-porten, og begge trengs for at oppsettet skal virke. gssencmode=disable har betydning på bygg som ellers ville forhandle GSSAPI-kryptering først, siden den veien ser bort fra TLS-innstillingene som nettopp ble satt. Vis til tjenesten med navn fra PostgreSQL-tilkoblingsvinduet i QGIS og oppgi passordet gjennom den vanlige forespørselen, ikke inne i en delt fil. Navnene og stiene ovenfor er plassholdere; bytt dem ut med dine egne godkjente verdier.

Hva PostgreSQL fortsatt sjekker etter tunnelen

Serveren ser en tilkobling fra SSH-verten, loopback i dette oppsettet, og sammenholder den i rekkefølge med vertsbaserte autentiseringsregler. Databaserollen din må fortsatt autentisere seg, og SSH-påloggingen gir ingen databaseidentitet i seg selv. Kontroller hva serveren tror, ikke hva klienten antok.

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

Lukk viderekoblingsøkten når arbeidet er ferdig; den lokale posten slutter da å virke og ingenting annet endres. Én vei til databasen er ikke en VPN for hele GIS-klienten, og å se på den som det er nettopp hvordan neste tilkobling blir feildiagnostisert.

Relaterte artikler