Tunnel tõuseb, QGIS ühendub ja sisselogimine sureb sertifikaadiveaga, mis nimetab andmebaasi hosti asemel 127.0.0.1. Järgmine ahvatlev samm on lõdvendada sslmode, mis vaigistab kontrolli ja viskab ära identiteedi garantii, mida te tegelikult tahtsite. Tegelik probleem on see, et kohalik port ja serveri nimi hoitakse samas väljas. libpq teenusekirje eraldab need, nii et socket läheb edastatud pordile, samal ajal kui TLS kontrollib endiselt sertifikaadile trükitud nime.

Millega klient arvab end ühenduvat

Režiimis sslmode=verify-full võrdleb libpq serveri esitatud sertifikaati hostinimega, millele pöörduti. Kui see nimi on loopback-aadress, ebaõnnestub võrdlus ka siis, kui sertifikaat kehtib tõelise andmebaasi hosti jaoks. SSH edastus muudab seda, milline socket baite kannab, mitte identiteeti, mida klient peaks ootama. Kui need kaks ideed on eraldatud, ei näe viga enam TLS-i rikkena.

Edastus ei ole ka autoriseerimine. PostgreSQL rakendab endiselt oma reegleid ühendusele, mille SSH-server loob, seega hoidke transpordikiht ja andmebaasikiht lahus enne, kui midagi muudate.

Siduge edastus ainult loopbackiga

Kuulaja peaks olema QGIS-i masinas ja mitte kusagil mujal. 127.0.0.1 selgesõnaline nimetamine hoiab selle teistest liidestest eemal, samas kui ära jäetud sidumisaadress võib pordi paljastada sõltuvalt SSH-kliendi lüüsi seadetest.

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

Sihtkoht pärast teist koolonit lahendatakse SSH-serveri poolel, seega eeldab see näide, et PostgreSQL asub samas hostis kui sshd; teises masinas olev andmebaas vajab hoopis seda aadressi ja selle õigusi. Käivitage sessioon -N-ga, et ühtki kesta ei avataks, jätke hostivõtme kontroll puutumata ja kinnitage, et kuulaja ilmub, enne kui QGIS-i süüdistate. Kui port on juba kasutusel, ebaõnnestub edastus käivitamisel, mitte päringu ajal.

Pange nimi ja socket ühte teenusekirjesse

Teenusefail lubab samal ühendusel kanda kontrollnime ja teistsugust socketi sihtkohta. Salvestage kirje sinna, kust libpq teenuseid otsib, või suunake PGSERVICEFILE sellele.

[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

Siin hoiab host alles sertifikaadikontrollide jaoks kasutatava identiteedi, samal ajal kui hostaddr saadab paketid edastatud loopback-pordile, ja mõlemat on selle korralduse toimimiseks vaja. gssencmode=disable on oluline buildides, mis muidu läbiräägiksid kõigepealt GSSAPI krüpteerimise, sest see tee eirab äsja seatud TLS-i sätteid. Viidake teenusele nime järgi QGIS-i PostgreSQL-ühenduse dialoogist ja andke parool tavalise küsimuse kaudu, mitte jagatud faili sees. Ülaltoodud nimed ja teed on kohahoidjad; asendage need oma kinnitatud väärtustega.

Mida PostgreSQL pärast tunnelit veel kontrollib

Server näeb ühendust SSH-hostist, selles korralduses loopbackist, ja sobitab selle järjekorras hostipõhiste autentimisreeglitega. Teie andmebaasi roll peab endiselt autentima ja SSH-sisselogimine ei anna iseenesest mingit andmebaasi identiteeti. Kontrollige, mida server arvab, mitte mida klient eeldas.

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

Sulgege edastussessioon, kui töö on tehtud; kohalik kirje lakkab siis töötamast ja miski muu ei muutu. Üks tee andmebaasi ei ole VPN kogu GIS-kliendi jaoks, ja selle VPN-ina kohtlemine ongi põhjus, miks järgmine ühendus valesti diagnoositakse.

Seotud artiklid