QGIS PostGIS SSH-tunnel: behold servernavnet til TLS

En SSH-viderekobling giver QGIS en lokal port, men databasen har stadig brug for sit rigtige navn til TLS. Brug en libpq-tjeneste med hostaddr og en loopback-lytter.

Tunnelen kommer op, QGIS forbinder, og login dør med en certifikatfejl, der nævner 127.0.0.1 i stedet for databaseserveren. Det fristende næste skridt er at lempe sslmode, hvilket dæmper kontrollen og smider identitetsgarantien væk, som du netop ønskede. Det egentlige problem er, at den lokale port og serverens navn gemmes i samme felt. En libpq-tjenestepost skiller dem, så socketen går til den videresendte port, mens TLS stadig verificerer navnet trykt på certifikatet.

Hvad klienten tror, den forbinder til

Under sslmode=verify-full sammenligner libpq certifikatet, serveren fremlægger, med det værtsnavn, der blev spurgt efter. Når navnet er en loopback-adresse, fejler sammenligningen, selv om certifikatet er gyldigt for den rigtige databasevært. SSH-viderekoblingen ændrer, hvilken socket der bærer bytes, ikke den identitet klienten bør forvente. Når de to ting skilles ad, holder fejlen op med at ligne en TLS-fejl.

En viderekobling er heller ikke autorisation. PostgreSQL anvender stadig sine egne regler på den forbindelse, SSH-serveren opretter, så hold transportlaget og databaselaget adskilt, før du ændrer noget.

Bind viderekoblingen kun til loopback

Lytteren bør findes på QGIS-maskinen og ingen andre steder. At nævne 127.0.0.1 eksplicit holder den væk fra andre grænseflader, mens en udeladt bind-adresse kan blotte porten afhængigt af SSH-klientens gateway-indstillinger.

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

Destinationen efter det andet kolon opløses fra SSH-serverens side, så dette eksempel antager, at PostgreSQL kører på samme vært som sshd; en database på en anden maskine har brug for den adresse og dens tilladelser. Kør sessionen med -N, så der ikke åbnes en skal, lad værtsnøgleverifikationen være og bekræft, at lytteren dukker op, før du bebrejder QGIS. Hvis porten allerede er i brug, fejler viderekoblingen ved start i stedet for ved forespørgslen.

Sæt navnet og socketen i én tjenestepost

En tjenestefil lader den samme forbindelse bære et verifikationsnavn og en anden socketdestination. Gem posten, hvor libpq leder efter tjenester, eller peg PGSERVICEFILE mod 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 bevarer host den identitet, der bruges til certifikatkontroller, mens hostaddr sender pakker til den videresendte loopback-port, og begge er nødvendige for, at denne ordning virker. gssencmode=disable betyder noget på builds, der ellers ville forhandle GSSAPI-kryptering først, fordi den vej ignorerer de netop satte TLS-indstillinger. Referer til tjenesten ved navn fra QGIS' PostgreSQL-forbindelsesdialog, og lever passwordet gennem den normale prompt i stedet for inde i en delt fil. Navnene og stierne ovenfor er pladsholdere; erstat dem med dine egne godkendte værdier.

Hvad PostgreSQL stadig kontrollerer efter tunnelen

Serveren ser en forbindelse fra SSH-værten, loopback i denne ordning, og matcher den mod værtsbaserede godkendelsesregler i rækkefølge. Din databaserolle skal stadig godkendes, og SSH-login giver ikke nogen databaseidentitet i sig selv. Verificer, hvad serveren tror, i stedet for hvad klienten antog.

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

Luk viderekoblingssessionen, når arbejdet er færdigt; den lokale post holder så op med at virke, og intet andet ændres. Én databasevej er ikke en VPN for hele GIS-klienten, og at behandle den som en er, hvordan den næste forbindelse bliver fejldiagnosticeret.

Relaterede artikler