SSH-göng QGIS og PostGIS: haltu nafni netþjónsins fyrir TLS

Göngin rísa, QGIS tengist og innskráningin deyr með vottorðsvillu sem nefnir 127.0.0.1 í stað gagnagrunnshýsisins. Næsta freistandi skref er að slaka á sslmode, sem þaggar niður athugunina og hendir þeirri auðkennisábyrgð sem þú vildir einmitt fá. Raunverulega vandamálið er að staðbundna gáttin og nafn netþjónsins eru geymd í sama reit. libpq-þjónustufærsla aðgreinir þau, svo sambandið fer á framsendu gáttina á meðan TLS staðfestir enn nafnið sem prentað er á vottorðið.

Við hvað biðlarinn heldur að hann tengist

Undir sslmode=verify-full ber libpq saman vottorðið sem netþjónninn leggur fram og hýsisnafnið sem beðið var um. Þegar það nafn er loopback-vistfang mistekst samanburðurinn þótt vottorðið sé gilt fyrir raunverulegan gagnagrunnshýsi. SSH-framsendingin breytir því hvaða samband ber bætin, ekki auðkenninu sem biðlarinn á að búast við. Þegar þessar tvær hugmyndir eru aðskildar lítur villan ekki lengur út eins og TLS-bilun.

Framsending er heldur ekki heimild. PostgreSQL beitir enn sínum eigin reglum á tenginguna sem SSH-netþjónninn býr til, svo haltu flutningslaginu og gagnagrunnslaginu aðskildum áður en þú breytir einhverju.

Bindtu framsendinguna eingöngu við loopback

Hlustarinn á að vera á QGIS-vélinni og hvergi annars staðar. Að nefna 127.0.0.1 sérstaklega heldur honum frá öðrum viðmótum, en sleppt bindivístfang getur opnað gáttina út á við eftir gáttarstillingum SSH-biðlarans.

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

Áfangastaðurinn eftir seðla tvípunktinn er leystur af hálfu SSH-netþjónsins, svo þetta dæmi gerir ráð fyrir að PostgreSQL sé á sama hýsi og sshd; gagnagrunnur á annarri vél þarf það vistfang og heimildir þess. Keyrðu lotuna með -N svo engin skel opnist, láttu hýsillykilinn í friði og staðfestu að hlustarinn birtist áður en þú kennir QGIS um. Ef gáttin er þegar í notkun mistekst framsendingin við ræsingu en ekki við fyrirspurnina.

Settu nafnið og sambandið í eina þjónustufærslu

Þjónustuskrá leyfir sama tengingunni að bera staðfestingarnafn og annan sambandsáfangastað. Vistaðu færsluna þar sem libpq leitar að þjónustum, eða beindu PGSERVICEFILE að henni.

[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

Hér heldur host því auðkenni sem notað er við vottorðsathuganir á meðan hostaddr sendir pakkana á framsendu loopback-gáttina, og bæði þarf svo að þetta fyrirkomulag virki. gssencmode=disable skiptir máli í byggingum sem myndu annars semja fyrst um GSSAPI-dulkóðun, því sú leið hunsar TLS-stillingarnar sem voru rétt settar. Vísadu í þjónustuna eftir nafni úr PostgreSQL-tengingarglugga QGIS og gefðu lykilorðið í gegnum venjulega kvaðningu, ekki inni í sameiginlegri skrá. Nöfnin og slóðirnar hér að ofan eru staðgenglar; skiptu þeim út fyrir þín eigin samþykktu gildi.

Hvað PostgreSQL athugar enn eftir göngin

Netþjónninn sér tengingu frá SSH-hýsinu, loopback í þessu fyrirkomulagi, og passar hana í röð við auðkenningarreglur sem byggja á hýsi. Hlutverk þitt í gagnagrunninum þarf samt að auðkenna sig, og SSH-innskráning veitir enga gagnagrunnsauðkenni eitt sér. Staðfestu það sem netþjónninn telur, ekki það sem biðlarinn gerði ráð fyrir.

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

Lokaðu framsendingarlotunni þegar verkinu er lokið; staðbundna færslan hættir þá að virka og ekkert annað breytist. Ein gagnagrunnsleið er ekki VPN fyrir allan GIS-biðlarann, og að líta á hana sem slíka er ástæðan fyrir því að næsta tenging er greind rangt.