Túnel SSH de QGIS a PostGIS: conserveu el nom del servidor per a TLS

El túnel s’aixeca, QGIS es connecta i l’inici de sessió mor amb un error de certificat que anomena 127.0.0.1 en lloc de l’amfitrió de la base de dades. El següent moviment temptador és relaxar sslmode, cosa que silencia la comprovació i llença la garantia d’identitat que volíeu precisament. El problema real és que el port local i el nom del servidor es guarden al mateix camp. Una entrada de servei libpq els separa, així el sòcol va al port reenviat mentre TLS continua verificant el nom imprès al certificat.

A què creu el client que es connecta

Amb sslmode=verify-full, libpq compara el certificat que presenta el servidor amb el nom d’amfitrió al qual s’ha demanat d’arribar. Quan aquest nom és una adreça de loopback, la comparació falla encara que el certificat sigui vàlid per a l’amfitrió real de la base de dades. El reenviament SSH canvia quin sòcol transporta els bytes, no la identitat que el client hauria d’esperar. Un cop aquestes dues idees se separen, l’error deixa de semblar una fallada de TLS.

Un reenviament tampoc no és autorització. PostgreSQL continua aplicant les seves pròpies regles a la connexió que fa el servidor SSH, així que manteniu la capa de transport i la capa de base de dades separades abans de canviar res.

Lligueu el reenviament només a loopback

L’oient ha d’existir a la màquina de QGIS i enlloc més. Anomenar 127.0.0.1 explícitament el manté fora de les altres interfícies, mentre que una adreça d’enllaç omesa pot exposar el port segons la configuració de passarel·la del client SSH.

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

La destinació després dels segons dos punts es resol des del costat del servidor SSH, així que aquest exemple assumeix que PostgreSQL és al mateix amfitrió que sshd; una base de dades en una altra màquina necessita aquella adreça i els seus permisos. Executeu la sessió amb -N perquè no s’obri cap intèrpret d’ordres, no toqueu la verificació de la clau d’amfitrió i confirmeu que l’oient apareix abans de culpar QGIS. Si el port ja és en ús, el reenviament falla en arrencar, no en el moment de la consulta.

Poseu el nom i el sòcol en una sola entrada de servei

Un fitxer de servei permet que la mateixa connexió porti un nom de verificació i una destinació de sòcol diferent. Deseu l’entrada on libpq busca els serveis, o feu que PGSERVICEFILE hi apunti.

[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

Aquí host conserva la identitat utilitzada per a les comprovacions de certificat mentre que hostaddr envia els paquets al port de loopback reenviat, i totes dues coses calen perquè aquesta disposició funcioni. gssencmode=disable importa en compilacions que, altrament, negociarien primer el xifratge GSSAPI, perquè aquest camí ignora la configuració de TLS que s’acaba de fer. Feu referència al servei pel nom des del diàleg de connexió PostgreSQL de QGIS i proporcioneu la contrasenya mitjançant el missatge habitual, no dins d’un fitxer compartit. Els noms i camins anteriors són marcadors de posició; substituïu-los pels vostres valors aprovats.

Què continua comprovant PostgreSQL després del túnel

El servidor veu una connexió de l’amfitrió SSH, loopback en aquesta disposició, i la compara amb les regles d’autenticació per amfitrió en ordre. El vostre rol de base de dades encara s’ha d’autenticar, i l’inici de sessió SSH no atorga cap identitat de base de dades per si sol. Verifiqueu què creu el servidor, no què va suposar el client.

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

Tanqueu la sessió de reenviament quan la feina estigui feta; l’entrada local llavors deixa de funcionar i res més no canvia. Un sol camí a la base de dades no és una VPN per a tot el client GIS, i tractar-lo com si ho fos és com es diagnostica malament la connexió següent.