QGIS PostGIS SSH-tunnel: houd de servernaam voor TLS

Een SSH-doorstuur geeft QGIS een lokale poort, maar de database heeft voor TLS nog steeds zijn echte naam nodig. Gebruik een libpq-service met hostaddr en een loopback-listener.

De tunnel komt op, QGIS verbindt, en de login sterft met een certificaatfout die 127.0.0.1 noemt in plaats van de databasehost. De verleidelijke volgende stap is sslmode te versoepelen, wat de controle stillegt en de identiteitsgarantie weggooit die je juist wilde. Het echte probleem is dat de lokale poort en de naam van de server in hetzelfde veld worden opgeslagen. Een libpq-service-item scheidt ze, zodat de socket naar de doorgestuurde poort gaat terwijl TLS nog steeds de naam op het certificaat verifieert.

Waarmee de client denkt te verbinden

Onder sslmode=verify-full vergelijkt libpq het certificaat dat de server presenteert met de gevraagde hostnaam. Als die naam een loopback-adres is, mislukt de vergelijking ook al is het certificaat geldig voor de echte databasehost. De SSH-doorstuur verandert welke socket de bytes draagt, niet de identiteit die de client mag verwachten. Zodra die twee ideeën gescheiden zijn, ziet de fout er niet meer uit als een TLS-storing.

Een doorstuur is ook geen autorisatie. PostgreSQL past nog steeds zijn eigen regels toe op de verbinding die de SSH-server maakt, dus houd de transportlaag en de databaselaag gescheiden voordat je iets verandert.

Bind de doorstuur alleen aan loopback

De listener hoort op de QGIS-machine te bestaan en nergens anders. 127.0.0.1 expliciet noemen houdt hem van andere interfaces af, terwijl een weggelaten bindadres de poort kan blootleggen, afhankelijk van de gateway-instellingen van de SSH-client.

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

De bestemming na de tweede dubbele punt wordt aan de kant van de SSH-server opgelost, dus dit voorbeeld gaat ervan uit dat PostgreSQL op dezelfde host als sshd staat; een database op een andere machine heeft dat adres en zijn rechten nodig. Start de sessie met -N zodat er geen shell wordt geopend, laat de hostkey-verificatie met rust en bevestig dat de listener verschijnt voordat je QGIS de schuld geeft. Als de poort al in gebruik is, mislukt de doorstuur bij het starten en niet bij de query.

Zet de naam en de socket in één service-item

Een servicebestand laat dezelfde verbinding een verificatienaam en een andere socketbestemming dragen. Bewaar het item waar libpq naar services zoekt, of richt PGSERVICEFILE daarop.

[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 behoudt host de identiteit die voor certificaatcontroles wordt gebruikt, terwijl hostaddr pakketten naar de doorgestuurde loopback-poort stuurt, en beide zijn nodig om deze opzet te laten werken. gssencmode=disable is belangrijk op builds die anders eerst GSSAPI-versleuteling zouden onderhandelen, omdat dat pad de zojuist ingestelde TLS-instellingen negeert. Verwijs in de PostgreSQL-verbindingsdialoog van QGIS naar de service bij naam en geef het wachtwoord via de gebruikelijke prompt, niet in een gedeeld bestand. De namen en paden hierboven zijn plaatsaanduidingen; vervang ze door je eigen goedgekeurde waarden.

Wat PostgreSQL na de tunnel nog controleert

De server ziet een verbinding van de SSH-host, in deze opzet loopback, en vergelijkt die op volgorde met de hostgebaseerde authenticatieregels. Je databaserol moet zich nog steeds authenticeren, en de SSH-login geeft op zichzelf geen database-identiteit. Controleer wat de server gelooft, niet wat de client aannam.

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

Sluit de doorstuursessie wanneer het werk klaar is; het lokale item werkt dan niet meer en verder verandert er niets. Eén databasepad is geen VPN voor de hele GIS-client, en het als zodanig behandelen is hoe de volgende verbinding verkeerd wordt gediagnosticeerd.

Gerelateerde artikelen