Tunel SSH QGIS-PostGIS: zachowaj nazwę serwera dla TLS

Przekierowanie SSH daje QGIS port lokalny, ale baza danych nadal potrzebuje swojej prawdziwej nazwy dla TLS. Użyj usługi libpq z hostaddr i nasłuchiwacza loopback.

Tunel się podnosi, QGIS się łączy, a logowanie umiera z błędem certyfikatu, który wskazuje 127.0.0.1 zamiast hosta bazy danych. Kolejnym kuszącym ruchem jest poluzowanie sslmode, co wycisza sprawdzanie i wyrzuca gwarancję tożsamości, której właśnie chciałeś. Prawdziwym problemem jest to, że port lokalny i nazwa serwera są przechowywane w tym samym polu. Wpis usługi libpq rozdziela je, więc gniazdo trafia na przekierowany port, a TLS nadal weryfikuje nazwę wydrukowaną na certyfikacie.

Do czego klient myśli, że się łączy

Przy sslmode=verify-full libpq porównuje certyfikat przedstawiony przez serwer z nazwą hosta, o którą poproszono. Gdy tą nazwą jest adres loopback, porównanie zawodzi, mimo że certyfikat jest ważny dla prawdziwego hosta bazy danych. Przekierowanie SSH zmienia to, które gniazdo niesie bajty, a nie tożsamość, której klient powinien oczekiwać. Gdy te dwie idee zostaną rozdzielone, błąd przestaje wyglądać jak awaria TLS.

Przekierowanie nie jest też autoryzacją. PostgreSQL nadal stosuje własne reguły do połączenia, które nawiązuje serwer SSH, więc trzymaj warstwę transportową i warstwę bazy danych oddzielnie, zanim cokolwiek zmienisz.

Przypnij przekierowanie tylko do loopback

Nasłuchiwacz powinien istnieć na maszynie QGIS i nigdzie indziej. Wymienienie 127.0.0.1 wprost trzyma go z dala od innych interfejsów, natomiast pominięty adres przypisania może wystawić port na zewnątrz w zależności od ustawień bramy klienta SSH.

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

Cel po drugim dwukropku jest rozwiązywany po stronie serwera SSH, więc ten przykład zakłada, że PostgreSQL stoi na tym samym hoście co sshd; baza na innej maszynie potrzebuje tego adresu i jego uprawnień. Uruchom sesję z -N, aby nie otwierała się żadna powłoka, nie ruszaj weryfikacji klucza hosta i potwierdź, że nasłuchiwacz się pojawił, zanim obwinisz QGIS. Jeśli port jest już zajęty, przekierowanie zawodzi przy starcie, a nie w momencie zapytania.

Umieść nazwę i gniazdo w jednym wpisie usługi

Plik usługi pozwala temu samemu połączeniu nieść nazwę weryfikacyjną i inny cel gniazda. Zapisz wpis tam, gdzie libpq szuka usług, albo skieruj PGSERVICEFILE na niego.

[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

Tutaj host zachowuje tożsamość używaną do sprawdzania certyfikatu, a hostaddr wysyła pakiety na przekierowany port loopback, i oba są potrzebne, aby ten układ działał. gssencmode=disable ma znaczenie w kompilacjach, które inaczej najpierw negocjowałyby szyfrowanie GSSAPI, ponieważ ta ścieżka ignoruje właśnie ustawione opcje TLS. Odwołaj się do usługi po nazwie z okna połączenia PostgreSQL w QGIS i podaj hasło przez zwykłe pytanie, a nie w udostępnionym pliku. Powyższe nazwy i ścieżki to placeholdery; zastąp je własnymi zatwierdzonymi wartościami.

Co PostgreSQL jeszcze sprawdza po tunelu

Serwer widzi połączenie z hosta SSH, w tym układzie loopback, i po kolei dopasowuje je do reguł uwierzytelniania opartych na hoście. Twoja rola w bazie nadal musi się uwierzytelnić, a logowanie SSH samo w sobie nie daje tożsamości w bazie. Sprawdzaj, co sądzi serwer, a nie co założył klient.

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

Zamknij sesję przekierowania, gdy praca się skończy; lokalny wpis przestaje wtedy działać i nic więcej się nie zmienia. Jedna ścieżka do bazy nie jest VPN dla całego klienta GIS, a traktowanie jej jako VPN jest właśnie tym, co powoduje błędną diagnozę następnego połączenia.

Powiązane artykuły