QGIS PostGIS SSH-tonnel: hou die bedienernaam vir TLS

Die tonnel kom op, QGIS maak verbinding, en die aanmelding misluk met ’n sertifikaatfout wat 127.0.0.1 noem in plaas van die databasis-gasheer. Die aanloklike volgende stap is om sslmode, te verslap, wat die kontrole stilmaak en die identiteitswaarborg weggooi wat jy juis in die eerste plek wou gehad het. Die werklike probleem is dat die plaaslike poort en die bediener se naam in dieselfde veld gestoor word. ’n libpq-diensinskrywing skei hulle, sodat die sok na die deurgevoerde poort gaan terwyl TLS steeds die naam verifieer wat op die sertifikaat gedruk staan.

Waaraan die kliënt dink hy verbinding maak

Onder sslmode=verify-full, vergelyk libpq die sertifikaat wat die bediener aanbied met die gasheernaam waarna gevra is. Wanneer daardie naam ’n loopback-adres is, misluk die vergelyking selfs al is die sertifikaat geldig vir die werklike databasis-gasheer. Die SSH-deurvoer verander watter sok die grepe dra, nie die identiteit wat die kliënt moet verwag nie. Sodra daardie twee idees geskei is, lyk die fout nie meer soos ’n TLS-fout nie.

’n Deurvoer is ook nie magtiging nie. PostgreSQL pas steeds sy eie reëls toe op die verbinding wat die SSH-bediener maak, so hou die vervoerlaag en die databaselaag apart voordat jy iets verander.

Bind die deurvoer slegs aan loopback

Die luisteraar moet op die QGIS-masjien bestaan en nêrens anders nie. Om 127.0.0.1 eksplisiet te noem, hou dit van ander koppelvlakke af, terwyl ’n weggelate bind-adres die poort kan blootstel, afhangende van die SSH-kliënt se gateway-instellings.

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

Die bestemming ná die tweede dubbelpunt word van die SSH-bediener se kant af opgelos, so hierdie voorbeeld aanvaar dat PostgreSQL op dieselfde gasheer as sshd sit; ’n databasis op ’n ander masjien het daardie adres en sy regte nodig. Begin die sessie met -N sodat geen dop oopgemaak word nie, los gasheer-sleutelverifikasie alleen, en bevestig dat die luisteraar verskyn voordat jy QGIS blameer. As die poort reeds in gebruik is, misluk die deurvoer by die opstart eerder as by die navraag.

Sit die naam en die sok in een diensinskrywing

’n Dienslêer laat dieselfde verbinding ’n verifikasienaam en ’n ander sokbestemming dra. Stoor die inskrywing waar libpq na dienste soek, of wys PGSERVICEFILE daarheen.

[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

Hier behou host die identiteit wat vir sertifikaatkontroles gebruik word, terwyl hostaddr pakkette na die deurgevoerde loopback-poort stuur, en albei is nodig om hierdie reëling te laat werk. gssencmode=disable maak saak op boue wat andersins eerste GSSAPI-enkripsie sou onderhandel, want daardie pad ignoreer die TLS-instellings wat pas opgestel is. Verwys na die diens by naam vanuit QGIS se PostgreSQL-verbindingsdialoog en gee die wagwoord deur die gewone aanmaning, nie binne ’n gedeelde lêer nie. Die name en paaie hierbo is plekhouers; vervang dit met jou eie goedgekeurde waardes.

Wat PostgreSQL steeds ná die tonnel kontroleer

Die bediener sien ’n verbinding van die SSH-gasheer, loopback in hierdie reëling, en pas dit in volgorde teen die gasheer-gebaseerde verifikasierreëls. Jou databasis-rol moet steeds verifieer, en die SSH-aanmelding gee op sigself geen databasis-identiteit nie. Verifieer wat die bediener glo eerder as wat die kliënt aangeneem het.

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

Sluit die deurvoersessie wanneer die werk klaar is; die plaaslike inskrywing hou dan op werk en niks anders verander nie. Een databasispad is nie ’n VPN vir die hele GIS-kliënt nie, en om dit as een te behandel, is hoe die volgende verbinding verkeerd gediagnoseer word.