Tuneli SSH QGIS PostGIS: mbani emrin e serverit për TLS

Tuneli ngrihet, QGIS lidhet dhe hyrja vdes me një gabim certifikate që përmend 127.0.0.1 në vend të hostit të bazës së të dhënave. Hapi tjetër joshës është të lehtësohet sslmode, gjë që e hesht kontrollin dhe hedh poshtë garancinë e identitetit që doje që në fillim. Problemi i vërtetë është se porta lokale dhe emri i serverit ruhen në të njëjtin fushë. Një zë shërbimi libpq i ndan ato, kështu që socket-i shkon te porta e përcjellë ndërsa TLS vazhdon të verifikojë emrin e shtypur në certifikatë.

Me çfarë mendon klienti se lidhet

Me sslmode=verify-full, libpq krahason certifikatën që paraqet serveri me emrin e hostit që u kërkua. Kur ai emër është adresë loopback, krahasimi dështon edhe pse certifikata është e vlefshme për hostin e vërtetë të bazës së të dhënave. Përcjellja SSH ndryshon cila socket mbart bajtët, jo identitetin që klienti duhet të presë. Pasi këto dy ide ndahen, gabimi nuk duket më si defekt TLS.

Përcjellja nuk është as autorizim. PostgreSQL vazhdon të zbatojë rregullat e veta për lidhjen që krijon serveri SSH, prandaj mbajini shtresën e transportit dhe shtresën e bazës së të dhënave të ndara përpara se të ndryshoni çdo gjë.

Lidhni përcjelljen vetëm me loopback

Dëgjuesi duhet të ekzistojë në makinën QGIS dhe askund tjetër. Përmendja e qartë e 127.0.0.1 e mban larg ndërfaqeve të tjera, ndërsa një adresë lidhjeje e lënë jashtë mund ta ekspozojë portën varësisht nga cilësimet e portës hyrëse të klientit SSH.

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

Destinacioni pas dy pikave të dyta zgjidhet nga ana e serverit SSH, prandaj ky shembull supozon se PostgreSQL është në të njëjtin host si sshd; një bazë të dhënash në një makinë tjetër i duhet ajo adresë dhe lejet e saj. Nisni sesionin me -N, që të mos hapet asnjë shell, mos e prekni verifikimin e çelësit të hostit dhe konfirmoni që dëgjuesi shfaqet përpara se të fajësoni QGIS. Nëse porta është tashmë e zënë, përcjellja dështon në nisje dhe jo në momentin e pyetjes.

Vendosni emrin dhe socket-in në një zë të vetëm shërbimi

Një skedar shërbimi lejon të njëjtën lidhje të mbajë një emër verifikimi dhe një destinacion tjetër socket-i. Ruani zërin aty ku libpq kërkon shërbime, ose drejtojeni PGSERVICEFILE nga ai.

[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

Këtu host ruan identitetin e përdorur për kontrollet e certifikatës, ndërsa hostaddr i dërgon paketat te porta loopback e përcjellë, dhe të dyja nevojiten që kjo rregullim të funksionojë. gssencmode=disable ka rëndësi në ndërtimet që përndryshe do të negocionin fillimisht kriptimin GSSAPI, sepse ajo rrugë i shpërfill cilësimet TLS të sapo vendosura. Referojuni shërbimit me emër nga dialogu i lidhjes PostgreSQL të QGIS dhe jepni fjalëkalimin përmes kërkesës së zakonshme, jo brenda një skedari të përbashkët. Emrat dhe shtigjet më sipër janë vendmbajtëse; zëvendësojini me vlerat tuaja të miratuara.

Çfarë kontrollon ende PostgreSQL pas tunelit

Serveri sheh një lidhje nga hosti SSH, loopback në këtë rregullim, dhe e përputh me radhë me rregullat e autentikimit të bazuara në host. Roli juaj në bazën e të dhënave duhet ende të autentikohet, dhe hyrja SSH nuk jep në vetvete asnjë identitet në bazën e të dhënave. Verifikoni atë që beson serveri, jo atë që supozoi klienti.

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

Mbyllni sesionin e përcjelljes kur puna të ketë mbaruar; zëri lokal atëherë nuk funksionon më dhe asgjë tjetër nuk ndryshon. Një rrugë e vetme drejt bazës së të dhënave nuk është VPN për të gjithë klientin GIS, dhe trajtimi i saj si e tillë është arsyeja pse lidhja tjetër diagnostikohet gabimisht.