Tunnel SSH QGIS-PostGIS : gardez le nom du serveur pour TLS

Un transfert SSH donne à QGIS un port local, mais la base de données a toujours besoin de son vrai nom pour TLS. Utilisez un service libpq avec hostaddr et un écouteur loopback.

Le tunnel monte, QGIS se connecte, et la connexion meurt sur une erreur de certificat qui nomme 127.0.0.1 au lieu de l’hôte de la base de données. Le geste tentant ensuite est d’assouplir sslmode, ce qui fait taire le contrôle et jette la garantie d’identité que vous vouliez précisément. Le vrai problème est que le port local et le nom du serveur sont stockés dans le même champ. Une entrée de service libpq les sépare, si bien que la socket part vers le port transféré pendant que TLS vérifie toujours le nom imprimé sur le certificat.

À quoi le client croit se connecter

Sous sslmode=verify-full, libpq compare le certificat présenté par le serveur au nom d’hôte demandé. Quand ce nom est une adresse de loopback, la comparaison échoue même si le certificat est valide pour le véritable hôte de la base de données. Le transfert SSH change quelle socket transporte les octets, pas l’identité que le client devrait attendre. Une fois ces deux idées séparées, l’erreur cesse de ressembler à une panne TLS.

Un transfert n’est pas une autorisation non plus. PostgreSQL applique toujours ses propres règles à la connexion établie par le serveur SSH, alors gardez la couche de transport et la couche base de données distinctes avant de changer quoi que ce soit.

Liez le transfert à loopback uniquement

L’écouteur doit exister sur la machine QGIS et nulle part ailleurs. Nommer 127.0.0.1 explicitement le garde hors des autres interfaces, tandis qu’une adresse de liaison omise peut exposer le port selon les réglages de passerelle du client SSH.

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

La destination après le deuxième deux-points est résolue du côté du serveur SSH, donc cet exemple suppose que PostgreSQL se trouve sur le même hôte que sshd ; une base sur une autre machine a besoin de cette adresse et de ses autorisations. Lancez la session avec -N pour qu’aucun shell ne s’ouvre, laissez la vérification de clé d’hôte tranquille et confirmez que l’écouteur apparaît avant d’accuser QGIS. Si le port est déjà pris, le transfert échoue au démarrage et non au moment de la requête.

Mettez le nom et la socket dans une seule entrée de service

Un fichier de service permet à la même connexion de porter un nom de vérification et une destination de socket différente. Enregistrez l’entrée là où libpq cherche les services, ou pointez PGSERVICEFILE dessus.

[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

Ici host conserve l’identité utilisée pour les contrôles de certificat tandis que hostaddr envoie les paquets vers le port loopback transféré, et les deux sont nécessaires pour que cette disposition fonctionne. gssencmode=disable compte sur les versions qui négocieraient sinon d’abord le chiffrement GSSAPI, car ce chemin ignore les réglages TLS qui viennent d’être définis. Référencez le service par son nom depuis la boîte de dialogue de connexion PostgreSQL de QGIS et fournissez le mot de passe via l’invite habituelle, pas dans un fichier partagé. Les noms et chemins ci-dessus sont des espaces réservés ; remplacez-les par vos propres valeurs approuvées.

Ce que PostgreSQL vérifie encore après le tunnel

Le serveur voit une connexion venant de l’hôte SSH, loopback dans cette disposition, et la compare dans l’ordre aux règles d’authentification par hôte. Votre rôle de base de données doit toujours s’authentifier, et la connexion SSH n’accorde en soi aucune identité de base de données. Vérifiez ce que le serveur croit, pas ce que le client a supposé.

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

Fermez la session de transfert quand le travail est terminé ; l’entrée locale cesse alors de fonctionner et rien d’autre ne change. Un seul chemin vers la base de données n’est pas un VPN pour tout le client SIG, et le traiter comme tel est précisément ce qui fait mal diagnostiquer la connexion suivante.

Articles similaires