QGIS PostGIS SSH-tunelo: konservu la servilan nomon por TLS

SSH-plusendado donas al QGIS lokan pordon, sed la datumbazo ankoraŭ bezonas sian veran nomon por TLS. Uzu libpq-servon kun hostaddr kaj loopback-aŭskultanto.

La tunelo ekfunkcias, QGIS konektiĝas, kaj la ensaluto mortas per atestila eraro, kiu nomas 127.0.0.1 anstataŭ la datumbazan gastiganton. La tentiga sekva paŝo estas malstreĉi sslmode, kio silentigas la kontrolon kaj forĵetas la identec-garantion, kiun vi ĵus volis. La vera problemo estas, ke la loka pordo kaj la nomo de la servilo estas konservataj en la sama kampo. Libpq-serva rikordo apartigas ilin, do la ingo iras al la plusendita pordo dum TLS ankoraŭ kontrolas la nomon presitan sur la atestilo.

Al kio la kliento pensas, ke ĝi konektiĝas

Sub sslmode=verify-full, libpq komparas la atestilon, kiun la servilo prezentas, kun la gastigantnomo, kiun oni petis atingi. Kiam tiu nomo estas loopback-adreso, la komparo malsukcesas eĉ se la atestilo validas por la vera datumbaza gastiganto. La SSH-plusendado ŝanĝas, kiu ingo portas la bitokojn, ne la identecon, kiun la kliento devus atendi. Post kiam tiuj du ideoj apartiĝas, la eraro ĉesas aspekti kiel TLS-difekto.

Plusendado ankaŭ ne estas rajtigo. PostgreSQL ankoraŭ aplikas siajn proprajn regulojn al la konekto, kiun faras la SSH-servilo, do tenu la transportan tavolon kaj la datumbazan tavolon apartaj antaŭ ol ŝanĝi ion ajn.

Ligu la plusendadon nur al loopback

La aŭskultanto devus ekzisti sur la QGIS-maŝino kaj nenie alie. Eksplicita nomo de 127.0.0.1 tenas ĝin for de aliaj interfacoj, dum forlasita liga adreso povas elmeti la pordon depende de la enireja agordo de la SSH-kliento.

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

La celo post la dua dupunkto estas solvata de la flanko de la SSH-servilo, do ĉi tiu ekzemplo supozas, ke PostgreSQL staras sur la sama gastiganto kiel sshd; datumbazo sur alia maŝino bezonas tiun adreson kaj ĝiajn permesojn. Lanĉu la seancon per -N por ke nenia ŝelo malfermiĝu, lasu la gastigantŝlosilan kontrolon trankvila kaj konfirmu, ke la aŭskultanto aperas antaŭ ol kulpigi QGIS. Se la pordo jam estas uzata, la plusendado malsukcesas ĉe starto, ne ĉe la momento de la peto.

Metu la nomon kaj la ingon en unu servan rikordon

Serva dosiero ebligas al la sama konekto porti kontrolnomon kaj alian ingan celon. Konservu la rikordon tie, kie libpq serĉas servojn, aŭ direktu PGSERVICEFILE al ĝi.

[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

Ĉi tie host konservas la identecon uzatan por atestilaj kontroloj, dum hostaddr sendas pakaĵojn al la plusendita loopback-pordo, kaj ambaŭ necesas por ke ĉi tiu aranĝo funkciu. gssencmode=disable gravas ĉe konstruaĵoj, kiuj alie unue intertraktus GSSAPI-ĉifradon, ĉar tiu vojo ignoras la ĵus agorditajn TLS-agordojn. Referencu la servon laŭnome el la PostgreSQL-konekta dialogo de QGIS kaj donu la pasvorton per la kutima prompto, ne ene de komuna dosiero. La nomoj kaj vojoj supre estas anstataŭigiloj; anstataŭigu ilin per viaj propraj aprobitaj valoroj.

Kion PostgreSQL ankoraŭ kontrolas post la tunelo

La servilo vidas konekton de la SSH-gastiganto, loopback en ĉi tiu aranĝo, kaj laŭorde kongruigas ĝin kun la gastigant-bazitaj aŭtentikigaj reguloj. Via datumbaza rolo ankoraŭ devas aŭtentikigi, kaj la SSH-ensaluto per si mem donas neniun datumbazan identecon. Kontrolu, kion la servilo kredas, anstataŭ kion la kliento supozis.

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

Fermu la plusendadan seancon kiam la laboro finiĝas; la loka rikordo tiam ĉesas funkcii kaj nenio alia ŝanĝiĝas. Unu datumbaza vojo ne estas VPN por la tuta GIS-kliento, kaj trakti ĝin kiel tia estas kiel la sekva konekto misdiagnoziĝas.

Rilataj artikoloj