QGIS PostGIS SSH -tunneli: säilytä palvelimen nimi TLS:ää varten
SSH-edelleenohjaus antaa QGISille paikallisen portin, mutta tietokanta tarvitsee TLS:ää varten yhä oikean nimensä. Käytä libpq-palvelua, jossa on hostaddr ja loopback-kuuntelija.
Tunneli nousee, QGIS yhdistää ja kirjautuminen kuolee varmennevirheeseen, joka nimeää 127.0.0.1 tietokantapalvelimen sijaan. Houkutteleva seuraava askel on löysätä sslmode, mikä vaientaa tarkistuksen ja heittää pois sen identiteettitakuun, jota alun perin halusit. Todellinen ongelma on, että paikallinen portti ja palvelimen nimi tallennetaan samaan kenttään. libpq-palvelumerkintä erottaa ne, joten socket menee edelleenohjattuun porttiin, kun taas TLS yhä varmistaa varmenteeseen painetun nimen.
Mihin asiakas luulee yhdistyvänsä
Asetuksella sslmode=verify-full libpq vertaa palvelimen esittämää varmennetta pyydettyyn isäntänimeen. Kun nimi on loopback-osoite, vertailu epäonnistuu, vaikka varmenne olisi kelvollinen oikealle tietokantaisännälle. SSH-edelleenohjaus muuttaa sitä, mikä socket kuljettaa tavut, ei sitä identiteettiä, jota asiakkaan pitäisi odottaa. Kun nämä kaksi ajatusta erotetaan, virhe ei enää näytä TLS-vialta.
Edelleenohjaus ei ole valtuutuskaan. PostgreSQL soveltaa yhä omia sääntöjään yhteyteen, jonka SSH-palvelin muodostaa, joten pidä kuljetuskerros ja tietokantakerros erillään ennen kuin muutat mitään.
Sido edelleenohjaus vain loopbackiin
Kuuntelijan pitäisi olla QGIS-koneella eikä missään muualla. 127.0.0.1:n nimeäminen eksplisiittisesti pitää sen poissa muilta liitännöiltä, kun taas pois jätetty sidontaosoite voi paljastaa portin SSH-asiakkaan yhdyskäytäväasetuksista riippuen.
ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 [email protected]Toisen kaksoispisteen jälkeinen kohde selvitetään SSH-palvelimen puolelta, joten tämä esimerkki olettaa PostgreSQL:n olevan samalla isännällä kuin sshd; toisella koneella oleva tietokanta tarvitsee sen osoitteen ja sen käyttöoikeudet. Käynnistä istunto -N-valitsimella, jotta kuorta ei avata, jätä isäntäavaimen tarkistus rauhaan ja varmista, että kuuntelija ilmestyy, ennen kuin syytät QGISiä. Jos portti on jo käytössä, edelleenohjaus epäonnistuu käynnistyksessä eikä kyselyn aikana.
Laita nimi ja socket yhteen palvelumerkintään
Palvelutiedosto antaa saman yhteyden kantaa tarkistusnimen ja toisen socket-kohteen. Tallenna merkintä sinne, mistä libpq etsii palveluja, tai osoita PGSERVICEFILE siihen.
[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.crtTässä host säilyttää varmenteen tarkistuksissa käytetyn identiteetin, kun taas hostaddr lähettää paketit edelleenohjattuun loopback-porttiin, ja molempia tarvitaan, jotta tämä järjestely toimii. gssencmode=disable on tärkeä koosteissa, jotka muuten neuvottelisivat ensin GSSAPI-salauksesta, koska se polku jättää juuri asetetut TLS-asetukset huomiotta. Viittaa palveluun nimellä QGISin PostgreSQL-yhteysvalintaikkunasta ja anna salasana tavallisen kehotteen kautta, ei jaettuun tiedostoon. Yllä olevat nimet ja polut ovat paikkamerkkejä; korvaa ne omilla hyväksytyillä arvoillasi.
Mitä PostgreSQL vielä tarkistaa tunnelin jälkeen
Palvelin näkee yhteyden SSH-isännästä, tässä järjestelyssä loopbackista, ja sovittaa sen järjestyksessä isäntäperusteisiin todennussääntöihin. Tietokantaroolisi on yhä todennettava, eikä SSH-kirjautuminen itsessään anna tietokantaidentiteettiä. Tarkista, mitä palvelin uskoo, älä sitä, mitä asiakas oletti.
psql "service=gis-via-ssh" -c "select inet_server_addr(), current_user"Sulje edelleenohjausistunto, kun työ on valmis; paikallinen merkintä lakkaa silloin toimimasta eikä mikään muu muutu. Yksi tietokantapolku ei ole VPN koko GIS-asiakkaalle, ja sen kohteleminen sellaisena on syy siihen, miksi seuraava yhteys diagnosoidaan väärin.