Tunel SSH QGIS-PostGIS: păstrați numele serverului pentru TLS

Tunelul urcă, QGIS se conectează, iar autentificarea moare cu o eroare de certificat care numește 127.0.0.1 în loc de gazda bazei de date. Următorul pas tentant este să relaxați sslmode, ceea ce amuțește verificarea și aruncă garanția de identitate pe care o doreați de fapt. Problema reală este că portul local și numele serverului sunt stocate în același câmp. O intrare de serviciu libpq le separă, astfel încât socketul merge la portul redirecționat în timp ce TLS verifică în continuare numele imprimat pe certificat.

La ce crede clientul că se conectează

Cu sslmode=verify-full, libpq compară certificatul prezentat de server cu numele de gazdă cerut. Când acel nume este o adresă loopback, comparația eșuează chiar dacă certificatul este valid pentru gazda reală a bazei de date. Forwardingul SSH schimbă ce socket transportă octeții, nu identitatea pe care clientul ar trebui să o aștepte. Odată separate aceste două idei, eroarea nu mai pare o defecțiune TLS.

Forwardingul nu este nici autorizare. PostgreSQL aplică în continuare propriile reguli conexiunii pe care o face serverul SSH, așa că țineți separat stratul de transport și stratul bazei de date înainte de a schimba ceva.

Legați forwardingul doar de loopback

Ascultătorul ar trebui să existe pe mașina QGIS și nicăieri altundeva. Numește 127.0.0.1 explicit îl ține departe de celelalte interfețe, în timp ce o adresă de legare omisă poate expune portul în funcție de setările de gateway ale clientului SSH.

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

Destinația de după al doilea două puncte este rezolvată din partea serverului SSH, așa că acest exemplu presupune că PostgreSQL se află pe aceeași gazdă ca sshd; o bază de date pe altă mașină are nevoie de acea adresă și de permisiunile ei. Rulați sesiunea cu -N ca să nu se deschidă niciun shell, lăsați în pace verificarea cheii de gazdă și confirmați că ascultătorul apare înainte de a da vina pe QGIS. Dacă portul este deja folosit, forwardingul eșuează la pornire și nu la momentul interogării.

Puneți numele și socketul într-o singură intrare de serviciu

Un fișier de serviciu permite aceleiași conexiuni să poarte un nume de verificare și o altă destinație de socket. Salvați intrarea acolo unde libpq caută servicii sau îndreptați PGSERVICEFILE spre ea.

[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

Aici host păstrează identitatea folosită la verificările certificatului, în timp ce hostaddr trimite pachetele către portul loopback redirecționat, și ambele sunt necesare pentru ca această aranjare să funcționeze. gssencmode=disable contează la build-urile care altfel ar negocia mai întâi criptarea GSSAPI, pentru că acea cale ignoră setările TLS tocmai stabilite. Faceți referire la serviciu după nume din dialogul de conexiune PostgreSQL al QGIS și furnizați parola prin promptul obișnuit, nu într-un fișier partajat. Numele și căile de mai sus sunt substituenți; înlocuiți-le cu valorile dumneavoastră aprobate.

Ce mai verifică PostgreSQL după tunel

Serverul vede o conexiune de la gazda SSH, loopback în această aranjare, și o potrivește în ordine cu regulile de autentificare bazate pe gazdă. Rolul dumneavoastră din baza de date trebuie încă să se autentifice, iar autentificarea SSH nu acordă prin ea însăși nicio identitate de bază de date. Verificați ce crede serverul, nu ce a presupus clientul.

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

Închideți sesiunea de forwarding când lucrul este terminat; intrarea locală nu mai funcționează atunci și nimic altceva nu se schimbă. O singură cale către baza de date nu este un VPN pentru tot clientul GIS, iar tratarea ei ca atare este motivul pentru care următoarea conexiune este diagnosticată greșit.