Túnel SSH de QGIS a PostGIS: conserve o nome do servidor para TLS

Un reenvío SSH dá a QGIS un porto local, pero a base de datos segue necesitando o seu nome real para TLS. Use un servizo libpq con hostaddr e un oínte de loopback.

O túnel levanta, QGIS conecta e o inicio de sesión morre cun erro de certificado que nomea 127.0.0.1 en lugar do host da base de datos. O seguinte movemento tentador é relaxar sslmode, o que silencia a comprobación e bota a garantía de identidade que precisamente quería. O problema real é que o porto local e o nome do servidor gárdanse no mesmo campo. Unha entrada de servizo libpq sepáraos, así o socket vai ao porto reenviado mentres TLS segue verificando o nome impreso no certificado.

A que cre o cliente que se conecta

Con sslmode=verify-full, libpq compara o certificado que presenta o servidor co nome de host ao que se pediu chegar. Cando ese nome é un enderezo de loopback, a comparación falla aínda que o certificado sexa válido para o host real da base de datos. O reenvío SSH cambia que socket transporta os bytes, non a identidade que o cliente debería esperar. Unha vez separadas esas dúas ideas, o erro deixa de parecer unha falla de TLS.

Un reenvío tampouco é autorización. PostgreSQL segue aplicando as súas propias regras á conexión que fai o servidor SSH, así que manteña a capa de transporte e a capa de base de datos separadas antes de cambiar nada.

Ate o reenvío só a loopback

O oínte debe existir na máquina de QGIS e en ningún outro sitio. Nomear 127.0.0.1 explicitamente mantéño fóra das demais interfaces, mentres que un enderezo de enlace omitido pode expoñer o porto segundo a configuración de pasarela do cliente SSH.

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

O destino tras os segundos dous puntos resólvese do lado do servidor SSH, así que este exemplo supón que PostgreSQL está no mesmo host que sshd; unha base de datos noutra máquina necesita ese enderezo e os seus permisos. Execute a sesión con -N para que non se abra ningún intérprete, deixe en paz a verificación da clave de host e confirme que aparece o oínte antes de culpar QGIS. Se o porto xa está en uso, o reenvío falla ao arrincar e non no momento da consulta.

Pon o nome e o socket nunha soa entrada de servizo

Un ficheiro de servizo permite que a mesma conexión leve un nome de verificación e un destino de socket distinto. Garde a entrada onde libpq busca os servizos, ou apunte PGSERVICEFILE cara a ela.

[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 a identidade usada para as comprobacións de certificado mentres que hostaddr envía os paquetes ao porto de loopback reenviado, e ambas as cousas fan falta para que esta disposición funcione. gssencmode=disable importa en compilacións que, doutro xeito, negociarían primeiro o cifrado GSSAPI, porque esa ruta ignora a configuración de TLS recén establecida. Faga referencia ao servizo por nome desde o diálogo de conexión PostgreSQL de QGIS e entregue o contrasinal mediante o aviso habitual, non dentro dun ficheiro compartido. Os nomes e rutas anteriores son marcadores de posición; substitúaos polos seus propios valores aprobados.

Que segue comprobando PostgreSQL tras o túnel

O servidor ve unha conexión desde o host SSH, loopback nesta disposición, e compáraa en orde coas regras de autenticación por host. O seu rol de base de datos aínda ten que autenticarse, e o inicio de sesión SSH non outorga por si mesmo ningunha identidade de base de datos. Verifique o que cre o servidor e non o que supuxo o cliente.

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

Pecha a sesión de reenvío cando o traballo estea feito; a entrada local deixa entón de funcionar e nada máis cambia. Unha soa ruta á base de datos non é unha VPN para todo o cliente GIS, e tratala coma se o fose é como se diagnostica mal a seguinte conexión.

Artigos relacionados