Tunnel ya SSH ya QGIS PostGIS: hifadhi jina la seva kwa TLS

Uelekezaji wa SSH humpa QGIS lango la ndani, lakini hifadhidata bado inahitaji jina lake halisi kwa TLS. Tumia huduma ya libpq yenye hostaddr na kisikilizaji cha loopback.

Tunnel inapanda, QGIS inaunganisha, na kuingia kunakufa kwa hitilafu ya cheti inayotaja 127.0.0.1 badala ya mwenyeji wa hifadhidata. Hatua inayofuata ya kuvutia ni kulegeza sslmode, jambo ambalo hunyamazisha ukaguzi na kutupa dhamana ya utambulisho uliyokuwa ukiitaka kuanzia mwanzo. Tatizo la kweli ni kwamba lango la ndani na jina la seva huhifadhiwa katika sehemu moja. Kipengele cha huduma cha libpq huzitenganisha, kwa hivyo soketi huenda kwenye lango lililoelekezwa wakati TLS bado inathibitisha jina lililochapishwa kwenye cheti.

Mteja anadhani anaunganisha na nini

Chini ya sslmode=verify-full, libpq hulinganisha cheti anachowasilisha seva na jina la mwenyeji lililoombwa. Jina hilo linapokuwa anwani ya loopback, ulinganisho unashindikana ingawa cheti ni halali kwa mwenyeji halisi wa hifadhidata. Uelekezaji wa SSH hubadilisha soketi ipi inayobeba baiti, si utambulisho ambao mteja anapaswa kutarajia. Mawazo haya mawili yakitenganishwa, hitilafu haionekani tena kama kasoro ya TLS.

Uelekezaji pia si idhini. PostgreSQL bado hutumia kanuni zake kwa muunganisho unaofanywa na seva ya SSH, kwa hivyo tenga tabaka la usafirishaji na tabaka la hifadhidata kabla ya kubadilisha chochote.

Funga uelekezaji kwenye loopback pekee

Kisikilizaji kinapaswa kuwepo kwenye mashine ya QGIS na mahali pengine popote. Kutaja 127.0.0.1 waziwazi kunakiweka mbali na violesura vingine, ilhali anwani ya kufunga ikiachwa inaweza kuweka lango wazi kwa nje kulingana na mipangilio ya lango la mteja wa SSH.

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

Lengo baada ya nukta mbili za pili hutatuliwa kutoka upande wa seva ya SSH, kwa hivyo mfano huu unadhani PostgreSQL iko kwenye mwenyeji sawa na sshd; hifadhidata kwenye mashine nyingine inahitaji anwani hiyo na ruhusa zake. Anzisha kipindi kwa -N ili ganda lolote lisifunguke, usiguse uthibitishaji wa ufunguo wa mwenyeji, na thibitisha kuwa kisikilizaji kinaonekana kabla ya kulaumu QGIS. Ikiwa lango tayari linatumika, uelekezaji unashindikana wakati wa kuanza na si wakati wa swali.

Weka jina na soketi katika kipengele kimoja cha huduma

Faili ya huduma huruhusu muunganisho huo huo kubeba jina la uthibitishaji na lengo tofauti la soketi. Hifadhi kipengele mahali ambapo libpq hutafuta huduma, au elekeza PGSERVICEFILE kuelekea hicho.

[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

Hapa host huhifadhi utambulisho unaotumika kwa ukaguzi wa cheti wakati hostaddr hutuma pakiti kwenye lango la loopback lililoelekezwa, na zote mbili zinahitajika ili mpangilio huu ufanye kazi. gssencmode=disable ni muhimu kwenye build ambazo vinginevyo zingejadili usimbaji fiche wa GSSAPI kwanza, kwa sababu njia hiyo hupuuza mipangilio ya TLS iliyowekwa hivi punde. Rejelea huduma kwa jina kutoka kidadisi cha muunganisho wa PostgreSQL cha QGIS na toa nenosiri kupitia kidokezo cha kawaida, si ndani ya faili inayoshirikiwa. Majina na njia zilizo juu ni vielelezo; badilisha na thamani zako zilizoidhinishwa.

PostgreSQL bado hukagua nini baada ya tunnel

Seva huona muunganisho kutoka kwa mwenyeji wa SSH, loopback katika mpangilio huu, na kuulinganisha kwa mpangilio na kanuni za uthibitishaji zinazotegemea mwenyeji. Jukumu lako la hifadhidata bado linapaswa kuthibitisha, na kuingia kwa SSH hakupei utambulisho wa hifadhidata peke yake. Thibitisha kile seva inaamini, si kile mteja alidhani.

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

Funga kipindi cha uelekezaji kazi ikikamilika; kipengele cha ndani kinaacha kufanya kazi na hakuna kingine kinachobadilika. Njia moja ya hifadhidata si VPN kwa mteja wote wa GIS, na kuichukulia kama VPN ndiko kunakofanya muunganisho unaofuata utambuliwe vibaya.

Makala zinazohusiana