QGIS PostGIS SSH-tunnel: hâld de servernam foar TLS

In SSH-oerdracht jout QGIS in lokale poarte, mar de databank hat foar TLS noch hieltyd syn echte namme nedich. Brûk in libpq-tsjinst mei hostaddr en in loopback-harker.

De tunnel komt op, QGIS ferbynt, en de oanmelding stjert mei in sertifikaatflater dy’t 127.0.0.1 neamt ynstee fan de databankhost. De ferloklike folgjende stap is om sslmode losser te meitsjen, wat de kontrôle stil makket en de identiteitsgarânsje fuortsmyt dy’t jo krekt woe. It echte probleem is dat de lokale poarte en de namme fan de server yn itselde fjild bewarre wurde. In libpq-tsjinstynskriuwing skiedt se, sadat de socket nei de trochstjoerde poarte giet wylst TLS noch hieltyd de namme ferifiearret dy’t op it sertifikaat printe is.

Wêr’t de klient tinkt dat er mei ferbynt

Under sslmode=verify-full ferliket libpq it sertifikaat dat de server oanbiedt mei de hostnamme dêr’t om frege is. As dy namme in loopback-adres is, mislearret de ferliking sels as it sertifikaat jildich is foar de echte databankhost. De SSH-oerdracht feroaret hokker socket de bytes draacht, net de identiteit dy’t de klient ferwachtsje moat. Sadree’t dy twa ideeën skieden binne, liket de flater net mear op in TLS-defekt.

In oerdracht is ek gjin autorisaasje. PostgreSQL past noch hieltyd syn eigen regels ta op de ferbining dy’t de SSH-server makket, dus hâld de transportlaach en de databanklaach skieden foardat jo eat feroarje.

Bin de oerdracht allinnich oan loopback

De harker moat op de QGIS-masine bestean en nearne oars. 127.0.0.1 eksplisyt neame hâldt him fuort fan oare ynterfaces, wylst in weilitten bindadres de poarte bûtendoar lizze kin ôfhinklik fan ’e gateway-ynstellingen fan de SSH-klient.

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

De bestimming nei de twadde dûbele punt wurdt fan ’e SSH-serverkant ôf oplost, dus dit foarbyld giet derfan út dat PostgreSQL op deselde host sit as sshd; in databank op in oare masine hat dat adres en syn rjochten nedich. Start de sesje mei -N sadat gjin shell iepene wurdt, lit de hostkaai-ferifikaasje gewurde en befêstigje dat de harker ferskynt foardat jo QGIS de skuld jouwe. As de poarte al yn gebrûk is, mislearret de oerdracht by it starten en net by it opfreegjen.

Set de namme en de socket yn ien tsjinstynskriuwing

In tsjinstbestân lit deselde ferbining in ferifikaasjenamme en in oare socketbestimming drage. Bewarje de ynskriuwing dêr’t libpq tsjinsten siket, of rjochtsje PGSERVICEFILE dêrop.

[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

Hjir hâldt host de identiteit dy’t brûkt wurdt foar sertifikaatkontrôles, wylst hostaddr pakketten nei de trochstjoerde loopback-poarte stjoert, en beide binne nedich om dizze regeling wurkje te litten. gssencmode=disable is wichtich by builds dy’t oars earst GSSAPI-fersifering ûnderhannelje soene, om’t dat paad de krekt ynstelde TLS-ynstellingen negearret. Ferwize nei de tsjinst by namme út ’e PostgreSQL-ferbiningsdialooch fan QGIS en jou it wachtwurd fia de gewoane fraach, net binnen in dield bestân. De nammen en paden hjirboppe binne plakhâlders; ferfange se troch jo eigen goedkarde wearden.

Wat PostgreSQL nei de tunnel noch kontrolearret

De server sjocht in ferbining fan ’e SSH-host, loopback yn dizze regeling, en ferliket dy op folchoarder mei de host-basearre autentikaasjeregels. Jo databankrol moat noch hieltyd autentisearje, en de SSH-oanmelding jout op himsels gjin databankidentiteit. Ferifiearje wat de server tinkt, net wat de klient oannaam.

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

Slút de oerdrachtsesje as it wurk dien is; de lokale ynskriuwing wurket dan net mear en fierder feroaret neat. Ien databankpaad is gjin VPN foar de hiele GIS-klient, en it as ien behannelje is hoe’t de folgjende ferbining ferkeard diagnostisearre wurdt.

Relatearre artikelen