Tunnel SSH ng QGIS PostGIS: panatilihin ang pangalan ng server para sa TLS

Bumangon ang tunnel, kumokonekta ang QGIS, at namamatay ang login sa error ng sertipiko na tumutukoy sa 127.0.0.1 sa halip na ang host ng database. Ang susunod na tuksong hakbang ay ang luwagan ang sslmode, na nagpapatahimik sa pagsusuri at itinatapon ang garantiya ng pagkakakilanlan na talagang gusto mo. Ang tunay na problema ay nakaimbak ang lokal na port at pangalan ng server sa iisang field. Pinaghihiwalay ng entry ng serbisyong libpq ang mga ito, kaya ang socket ay pumupunta sa naipasang port habang ang TLS ay nagbe-verify pa rin ng pangalang nakalimbag sa sertipiko.

Ano ang inaakalang kinokonektahan ng kliyente

Sa ilalim ng sslmode=verify-full, inihahambing ng libpq ang sertipikong inihaharap ng server sa hiniling na pangalan ng host. Kapag ang pangalang iyon ay loopback address, nabibigo ang paghahambing kahit valid ang sertipiko para sa tunay na host ng database. Binabago ng SSH forward kung aling socket ang nagdadala ng mga byte, hindi ang pagkakakilanlang dapat asahan ng kliyente. Kapag nahiwalay ang dalawang ideyang ito, hindi na mukhang sira ng TLS ang error.

Ang forward ay hindi rin awtorisasyon. Inilalapat pa rin ng PostgreSQL ang sarili nitong mga tuntunin sa koneksyong ginagawa ng SSH server, kaya panatilihing hiwalay ang transport layer at ang database layer bago magbago ng kahit ano.

Itali ang forward sa loopback lamang

Dapat umiral ang listener sa makina ng QGIS at wala nang iba. Ang tahasang pagbanggit ng 127.0.0.1 ay naglalayo nito sa ibang interface, samantalang ang inalis na bind address ay maaaring maglantad ng port depende sa gateway settings ng SSH client.

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

Ang destinasyon pagkatapos ng ikalawang tutuldok ay nireresolba mula sa panig ng SSH server, kaya ipinapalagay ng halimbawang ito na ang PostgreSQL ay nasa parehong host ng sshd; ang database sa ibang makina ay nangangailangan ng address na iyon at ng mga pahintulot nito. Patakbuhin ang session gamit ang -N upang walang shell na mabuksan, huwag galawin ang host-key verification, at tiyakin na lumilitaw ang listener bago sisihin ang QGIS. Kung ginagamit na ang port, nabibigo ang forward sa pagsisimula at hindi sa oras ng query.

Ilagay ang pangalan at socket sa isang entry ng serbisyo

Pinapayagan ng service file ang parehong koneksyon na magdala ng pangalan para sa verification at ibang destinasyon ng socket. I-save ang entry kung saan hinahanap ng libpq ang mga serbisyo, o ituro ang PGSERVICEFILE doon.

[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

Dito pinapanatili ng host ang pagkakakilanlang ginagamit sa mga pagsusuri ng sertipiko habang ang hostaddr ay nagpapadala ng mga packet sa naipasang loopback port, at kailangan ang pareho para gumana ang kaayusang ito. gssencmode=disable ay mahalaga sa mga build na kung hindi ay makikipag-usap muna sa GSSAPI encryption, dahil binabalewala ng landas na iyon ang mga TLS setting na kalilagay lamang. Sumangguni sa serbisyo sa pamamagitan ng pangalan mula sa dialog ng koneksyon ng PostgreSQL sa QGIS at ibigay ang password sa karaniwang prompt, hindi sa loob ng pinagsasaluhang file. Ang mga pangalan at landas sa itaas ay mga placeholder; palitan ang mga ito ng sarili mong aprubadong halaga.

Ano pa ang sinusuri ng PostgreSQL pagkatapos ng tunnel

Nakikita ng server ang koneksyon mula sa SSH host, loopback sa kaayusang ito, at itinutugma ito nang sunud-sunod sa mga tuntunin ng authentication na nakabatay sa host. Kailangan pa ring mag-authenticate ng iyong role sa database, at ang SSH login mismo ay hindi nagbibigay ng pagkakakilanlan sa database. I-verify kung ano ang pinaniniwalaan ng server, hindi kung ano ang inakala ng kliyente.

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

Isara ang forwarding session kapag tapos na ang trabaho; titigil na gumana ang lokal na entry at wala nang ibang magbabago. Ang isang landas patungo sa database ay hindi VPN para sa buong GIS client, at ang ituring itong VPN ang dahilan kung bakit mali ang diagnosis sa susunod na koneksyon.