Túnel SSH QGIS-PostGIS: mantenha o nome do servidor para TLS

O túnel sobe, o QGIS liga-se e o início de sessão morre com um erro de certificado que nomeia 127.0.0.1 em vez do anfitrião da base de dados. O próximo passo tentador é relaxar sslmode, o que silencia a verificação e deita fora a garantia de identidade que queria precisamente. O problema real é que a porta local e o nome do servidor são guardados no mesmo campo. Uma entrada de serviço libpq separa-os, pelo que o socket vai para a porta encaminhada enquanto o TLS continua a verificar o nome impresso no certificado.

A que o cliente pensa que se liga

Com sslmode=verify-full, o libpq compara o certificado apresentado pelo servidor com o nome de anfitrião pedido. Quando esse nome é um endereço de loopback, a comparação falha mesmo que o certificado seja válido para o anfitrião real da base de dados. O encaminhamento SSH muda qual socket transporta os bytes, não a identidade que o cliente deve esperar. Assim que estas duas ideias se separam, o erro deixa de parecer uma falha de TLS.

Um encaminhamento também não é autorização. O PostgreSQL continua a aplicar as suas próprias regras à ligação que o servidor SSH estabelece, por isso mantenha a camada de transporte e a camada de base de dados separadas antes de mudar seja o que for.

Ligue o encaminhamento apenas ao loopback

O ouvinte deve existir na máquina do QGIS e em nenhum outro lugar. Nomear 127.0.0.1 explicitamente mantém-no fora das outras interfaces, enquanto um endereço de ligação omitido pode expor a porta conforme as definições de gateway do cliente SSH.

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

O destino após os segundos dois pontos é resolvido do lado do servidor SSH, pelo que este exemplo assume que o PostgreSQL está no mesmo anfitrião que o sshd; uma base de dados noutra máquina precisa desse endereço e das suas permissões. Execute a sessão com -N para que não se abra qualquer shell, deixe a verificação da chave do anfitrião em paz e confirme que o ouvinte aparece antes de culpar o QGIS. Se a porta já estiver em uso, o encaminhamento falha no arranque e não no momento da consulta.

Coloque o nome e o socket numa única entrada de serviço

Um ficheiro de serviço permite que a mesma ligação transporte um nome de verificação e um destino de socket diferente. Guarde a entrada onde o libpq procura serviços, ou aponte PGSERVICEFILE para 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

Aqui host conserva a identidade usada nas verificações de certificado enquanto hostaddr envia os pacotes para a porta de loopback encaminhada, e ambos são necessários para esta disposição funcionar. gssencmode=disable é importante em compilações que, de outro modo, negociariam primeiro a cifragem GSSAPI, porque esse caminho ignora as definições de TLS acabadas de configurar. Faça referência ao serviço pelo nome a partir da caixa de diálogo de ligação PostgreSQL do QGIS e forneça a palavra-passe através do pedido habitual, não dentro de um ficheiro partilhado. Os nomes e caminhos acima são marcadores de posição; substitua-os pelos seus próprios valores aprovados.

O que o PostgreSQL ainda verifica depois do túnel

O servidor vê uma ligação a partir do anfitrião SSH, loopback nesta disposição, e compara-a por ordem com as regras de autenticação baseadas no anfitrião. A sua função na base de dados continua a ter de se autenticar, e o início de sessão SSH não concede por si só qualquer identidade de base de dados. Verifique o que o servidor acredita, não o que o cliente assumiu.

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

Feche a sessão de encaminhamento quando o trabalho estiver concluído; a entrada local deixa então de funcionar e nada mais muda. Um único caminho para a base de dados não é uma VPN para todo o cliente SIG, e tratá-lo como tal é como a ligação seguinte é mal diagnosticada.