QGIS PostGIS SSH-alagút: tartsa meg a kiszolgáló nevét a TLS-hez

Az alagút feljön, a QGIS csatlakozik, és a bejelentkezés meghal egy tanúsítványhibával, amely az adatbázis-gazdagép helyett 127.0.0.1-et nevez meg. A következő csábító lépés a sslmode lazítása, ami elnémítja az ellenőrzést, és eldobja azt az identitásgaranciát, amelyet eredetileg akart. A valódi probléma az, hogy a helyi port és a kiszolgáló neve ugyanabban a mezőben tárolódik. Egy libpq-szolgáltatásbejegyzés szétválasztja őket, így a socket a továbbított portra megy, miközben a TLS továbbra is ellenőrzi a tanúsítványra nyomtatott nevet.

Mihez hiszi a kliens, hogy csatlakozik

A sslmode=verify-full beállítás mellett a libpq összehasonlítja a kiszolgáló által bemutatott tanúsítványt a kért gazdagépnévvel. Ha ez a név loopback-cím, az összehasonlítás meghiúsul, pedig a tanúsítvány érvényes a valódi adatbázis-gazdagépre. Az SSH-továbbítás azt változtatja meg, melyik socket szállítja a bájtokat, nem azt az identitást, amelyet a kliensnek várnia kellene. Amint ez a két elképzelés szétválik, a hiba már nem tűnik TLS-hibának.

A továbbítás nem felhatalmazás sem. A PostgreSQL továbbra is a saját szabályait alkalmazza az SSH-kiszolgáló által létrehozott kapcsolatra, ezért a szállítási réteget és az adatbázis-réteget tartsa külön, mielőtt bármit módosítana.

Csak loopbackre kösse a továbbítást

A figyelőnek a QGIS gépén kell léteznie, és sehol másutt. A 127.0.0.1 kifejezett megnevezése távol tartja a többi interfésztől, míg az elhagyott kötési cím a SSH-kliens átjáróbeállításaitól függően a portot is kiteheti.

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

A második kettőspont utáni cél az SSH-kiszolgáló oldalán oldódik fel, ezért ez a példa azt feltételezi, hogy a PostgreSQL ugyanazon a gazdagépen van, mint az sshd; egy másik gépen lévő adatbázisnak arra a címre és annak engedélyeire van szüksége. Indítsa a munkamenetet -N kapcsolóval, hogy ne nyíljon héj, hagyja békén a gazdagépkulcs ellenőrzését, és erősítse meg, hogy a figyelő megjelenik, mielőtt a QGIS-t hibáztatná. Ha a port már használatban van, a továbbítás indításkor hiúsul meg, nem a lekérdezés idején.

Tegye a nevet és a socketet egyetlen szolgáltatásbejegyzésbe

Egy szolgáltatásfájl lehetővé teszi, hogy ugyanaz a kapcsolat ellenőrzési nevet és más socketcélt hordozzon. Mentse a bejegyzést oda, ahol a libpq szolgáltatásokat keres, vagy irányítsa PGSERVICEFILE rá.

[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

Itt a host megtartja a tanúsítványellenőrzésekhez használt identitást, míg a hostaddr a csomagokat a továbbított loopback portra küldi, és mindkettő kell ahhoz, hogy ez az elrendezés működjön. gssencmode=disable azokon a buildeken számít, amelyek egyébként először GSSAPI-titkosítást tárgyalnának, mert az az útvonal figyelmen kívül hagyja az éppen beállított TLS-opciókat. Hivatkozzon a szolgáltatásra név szerint a QGIS PostgreSQL-kapcsolat párbeszédpaneljéből, és a jelszót a szokásos kérésen keresztül adja meg, ne egy megosztott fájlon belül. A fenti nevek és útvonalak helyőrzők; cserélje ki őket a saját jóváhagyott értékeire.

Mit ellenőriz még a PostgreSQL az alagút után

A kiszolgáló az SSH-gazdagéptől, ebben az elrendezésben loopbackről érkező kapcsolatot lát, és sorrendben összeveti a gazdagépalapú hitelesítési szabályokkal. Az adatbázis-szerepkörének továbbra is hitelesítenie kell magát, és az SSH-bejelentkezés önmagában nem ad adatbázis-identitást. Azt ellenőrizze, amit a kiszolgáló hisz, ne azt, amit a kliens feltételezett.

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

Zárja be a továbbítási munkamenetet, amikor a munka elkészült; a helyi bejegyzés akkor működni szűnik meg, és semmi más nem változik. Egy adatbázis-útvonal nem VPN az egész GIS-kliens számára, és ha annak tekintjük, az vezet a következő kapcsolat félrediagnosztizálásához.