Tunnel SSH QGIS-PostGIS: conservate il nome del server per TLS

Il tunnel si alza, QGIS si connette e l’accesso muore con un errore di certificato che nomina 127.0.0.1 invece dell’host del database. La mossa tentante successiva è allentare sslmode, che zittisce il controllo e butta via la garanzia di identità che volevate proprio. Il problema reale è che la porta locale e il nome del server vengono salvati nello stesso campo. Una voce di servizio libpq li separa, così il socket va alla porta inoltrata mentre TLS verifica ancora il nome stampato sul certificato.

A cosa il client crede di connettersi

Con sslmode=verify-full, libpq confronta il certificato presentato dal server con il nome host richiesto. Quando quel nome è un indirizzo di loopback, il confronto fallisce anche se il certificato è valido per il vero host del database. L’inoltro SSH cambia quale socket trasporta i byte, non l’identità che il client dovrebbe aspettarsi. Una volta separate queste due idee, l’errore smette di sembrare un guasto TLS.

Un inoltro non è nemmeno un’autorizzazione. PostgreSQL applica ancora le proprie regole alla connessione stabilita dal server SSH, quindi tenete separati il livello di trasporto e il livello database prima di cambiare qualcosa.

Legate l’inoltro solo al loopback

Il listener deve esistere sulla macchina QGIS e da nessun’altra parte. Nominare 127.0.0.1 esplicitamente lo tiene fuori dalle altre interfacce, mentre un indirizzo di bind omesso può esporre la porta a seconda delle impostazioni del gateway del client SSH.

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

La destinazione dopo i secondi due punti viene risolta dal lato del server SSH, quindi questo esempio presume che PostgreSQL sia sullo stesso host di sshd; un database su un’altra macchina ha bisogno di quell’indirizzo e dei suoi permessi. Avviate la sessione con -N così non si apre alcuna shell, lasciate stare la verifica della chiave host e confermate che il listener compaia prima di dare la colpa a QGIS. Se la porta è già in uso, l’inoltro fallisce all’avvio e non al momento della query.

Mettete il nome e il socket in un’unica voce di servizio

Un file di servizio permette alla stessa connessione di portare un nome di verifica e una destinazione socket diversa. Salvate la voce dove libpq cerca i servizi, oppure puntate PGSERVICEFILE su di essa.

[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

Qui host conserva l’identità usata per i controlli del certificato mentre hostaddr invia i pacchetti alla porta di loopback inoltrata, e servono entrambi perché questa disposizione funzioni. gssencmode=disable conta nelle build che altrimenti negozierebbero prima la cifratura GSSAPI, perché quel percorso ignora le impostazioni TLS appena definite. Fate riferimento al servizio per nome dalla finestra di connessione PostgreSQL di QGIS e fornite la password tramite il prompt abituale, non dentro un file condiviso. I nomi e i percorsi sopra sono segnaposto; sostituiteli con i vostri valori approvati.

Cosa controlla ancora PostgreSQL dopo il tunnel

Il server vede una connessione dall’host SSH, loopback in questa disposizione, e la confronta in ordine con le regole di autenticazione basate sull’host. Il vostro ruolo del database deve comunque autenticarsi, e l’accesso SSH non concede di per sé alcuna identità di database. Verificate ciò che crede il server, non ciò che ha supposto il client.

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

Chiudete la sessione di inoltro quando il lavoro è finito; la voce locale smette allora di funzionare e nient’altro cambia. Un solo percorso verso il database non è una VPN per tutto il client GIS, e trattarlo come tale è il modo in cui la connessione successiva viene diagnosticata male.