QGIS PostGIS SSH tunelis: išsaugokite serverio vardą TLS

SSH peradresavimas suteikia QGIS vietinį prievadą, bet duomenų bazei TLS vis dar reikia tikrojo vardo. Naudokite libpq paslaugą su hostaddr ir loopback klausytuvu.

Tunelis pakyla, QGIS prisijungia, o prisijungimas miršta su sertifikato klaida, kuri nurodo 127.0.0.1, o ne duomenų bazės mazgą. Kitas viliojantis žingsnis – susilpninti sslmode, o tai nutildo patikrą ir išmeta tapatybės garantiją, kurios iš tiesų norėjote. Tikroji problema ta, kad vietinis prievadas ir serverio vardas saugomi tame pačiame lauke. libpq paslaugos įrašas juos atskiria, todėl lizdas eina į peradresuotą prievadą, o TLS vis dar tikrina sertifikate atspausdintą vardą.

Prie ko klientas mano prisijungiąs

Nustačius sslmode=verify-full, libpq lygina serverio pateiktą sertifikatą su užklaustu mazgo vardu. Kai tas vardas yra loopback adresas, palyginimas nepavyksta, nors sertifikatas galioja tikrajam duomenų bazės mazgui. SSH peradresavimas keičia, kuris lizdas neša baitus, o ne tapatybę, kurios klientas turėtų tikėtis. Atskyrus šias dvi idėjas, klaida nebeatrodys kaip TLS gedimas.

Peradresavimas taip pat nėra įgaliojimas. PostgreSQL ir toliau taiko savo taisykles ryšiui, kurį sukuria SSH serveris, todėl laikykite transporto sluoksnį ir duomenų bazės sluoksnį atskirai, prieš ką nors keisdami.

Susiekite peradresavimą tik su loopback

Klausytuvas turėtų egzistuoti QGIS mašinoje ir niekur kitur. Aiškus 127.0.0.1 nurodymas laiko jį atokiai nuo kitų sąsajų, o praleistas susiejimo adresas gali atverti prievadą priklausomai nuo SSH kliento tinklo vartų nustatymų.

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

Tikslas po antrojo dvitaškio sprendžiamas SSH serverio pusėje, todėl šis pavyzdys daro prielaidą, kad PostgreSQL yra tame pačiame mazge kaip sshd; duomenų bazei kitoje mašinoje reikia to adreso ir jo leidimų. Paleiskite sesiją su -N, kad nebūtų atidarytas joks apvalkalas, nelieskite mazgo rakto tikrinimo ir patvirtinkite, kad klausytuvas pasirodė, prieš kaltindami QGIS. Jei prievadas jau užimtas, peradresavimas nepavyksta paleidžiant, o ne užklausos metu.

Sudėkite vardą ir lizdą į vieną paslaugos įrašą

Paslaugos failas leidžia tam pačiam ryšiui nešti patikros vardą ir kitą lizdo tikslą. Išsaugokite įrašą ten, kur libpq ieško paslaugų, arba nukreipkite PGSERVICEFILE į jį.

[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

Čia host išlaiko tapatybę, naudojamą sertifikatų patikroms, o hostaddr siunčia paketus į peradresuotą loopback prievadą, ir abu reikalingi, kad ši tvarka veiktų. gssencmode=disable svarbus versijose, kurios kitaip pirmiau derėtųsi dėl GSSAPI šifravimo, nes tas kelias nepaiso ką tik nustatytų TLS parinkčių. Nurodykite paslaugą vardu iš QGIS PostgreSQL prisijungimo dialogo ir slaptažodį pateikite įprastu raginimu, o ne bendrame faile. Aukščiau esantys vardai ir keliai yra vietos žymekliai; pakeiskite juos savo patvirtintomis reikšmėmis.

Ką PostgreSQL dar tikrina po tunelio

Serveris mato ryšį iš SSH mazgo, šioje tvarkoje loopback, ir iš eilės lygina jį su autentifikavimo taisyklėmis pagal mazgą. Jūsų duomenų bazės vaidmuo vis dar turi autentifikuotis, o SSH prisijungimas pats savaime nesuteikia duomenų bazės tapatybės. Tikrinkite, ką mano serveris, o ne ką numatė klientas.

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

Uždarykite peradresavimo sesiją, kai darbas baigtas; vietinis įrašas tada nustoja veikti ir daugiau niekas nesikeičia. Vienas kelias iki duomenų bazės nėra VPN visam GIS klientui, ir būtent elgesys su juo kaip su VPN lemia neteisingą kitos jungties diagnostiką.

Susiję straipsniai