SSH tunel QGIS–PostGIS: zachovejte jméno serveru pro TLS

Přesměrování SSH dá QGIS místní port, ale databáze pro TLS stále potřebuje své skutečné jméno. Použijte službu libpq s hostaddr a posluchačem na loopbacku.

Tunel se zvedne, QGIS se připojí a přihlášení skončí chybou certifikátu, která uvádí 127.0.0.1 místo hostitele databáze. Lákavým dalším krokem je povolit sslmode, což kontrolu umlčí a zahodí záruku identity, kterou jste vlastně chtěli. Skutečný problém je, že místní port a jméno serveru se ukládají do stejného pole. Záznam služby libpq je odděluje, takže socket jde na přesměrovaný port, zatímco TLS stále ověřuje jméno vytištěné na certifikátu.

K čemu si klient myslí, že se připojuje

Při sslmode=verify-full porovnává libpq certifikát, který server předloží, s názvem hostitele, na který se dotazoval. Když je tím názvem adresa loopbacku, porovnání selže, i když je certifikát platný pro skutečného hostitele databáze. Přesměrování SSH mění, který socket přenáší bajty, ne identitu, kterou má klient očekávat. Jakmile se tyto dvě představy oddělí, chyba už nevypadá jako závada TLS.

Přesměrování také není autorizace. PostgreSQL stále uplatňuje svá vlastní pravidla na připojení, které vytváří SSH server, takže než cokoli změníte, držte transportní vrstvu a vrstvu databáze oddělené.

Navazte přesměrování jen na loopback

Posluchač má existovat na stroji s QGIS a nikde jinde. Výslovné uvedení 127.0.0.1 ho drží mimo ostatní rozhraní, kdežto vynechaná adresa pro navázání může port vystavit podle nastavení brány SSH klienta.

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

Cíl za druhou dvojtečkou se řeší na straně SSH serveru, takže tento příklad předpokládá, že PostgreSQL běží na stejném hostiteli jako sshd; databáze na jiném stroji potřebuje tuto adresu a její oprávnění. Spusťte relaci s -N, aby se neotevřel žádný shell, nechte ověřování klíče hostitele být a než začnete vinit QGIS, ověřte, že se posluchač objevil. Pokud je port už obsazený, přesměrování selže při spuštění, ne při dotazu.

Dejte jméno i socket do jednoho záznamu služby

Soubor služby umožňuje, aby stejné připojení neslo ověřovací jméno a jiný cíl socketu. Uložte záznam tam, kde libpq hledá služby, nebo namiřte PGSERVICEFILE na něj.

[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

Zde host zachovává identitu používanou pro kontroly certifikátu, zatímco hostaddr posílá pakety na přesměrovaný port loopbacku a pro fungování tohoto uspořádání jsou potřeba oba. gssencmode=disable je důležité u sestavení, která by jinak nejprve vyjednala šifrování GSSAPI, protože tato cesta ignoruje právě nastavené volby TLS. Odkazujte na službu jménem z dialogu připojení PostgreSQL v QGIS a heslo zadejte přes běžnou výzvu, ne uvnitř sdíleného souboru. Názvy a cesty výše jsou zástupné; nahraďte je svými schválenými hodnotami.

Co PostgreSQL po tunelu ještě kontroluje

Server vidí připojení z hostitele SSH, v tomto uspořádání z loopbacku, a porovnává je v pořadí s pravidly ověřování podle hostitele. Vaše databázová role se stále musí ověřit a přihlášení SSH samo o sobě žádnou databázovou identitu nepřiděluje. Ověřujte, co si myslí server, ne co předpokládal klient.

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

Až je práce hotová, relaci přesměrování zavřete; místní záznam pak přestane fungovat a nic jiného se nezmění. Jedna cesta k databázi není VPN pro celého klienta GIS, a právě zacházení s ní jako s VPN vede k chybné diagnóze příštího připojení.

Související články