SSH тунел за QGIS и PostGIS: сочувајте го името на серверот за TLS

SSH препраќањето му дава на QGIS локален порт, но базата на податоци за TLS уште го бара своето вистинско име. Користете libpq услуга со hostaddr и loopback слушач.

Тунелот се крева, QGIS се поврзува и најавата умира со грешка за сертификатот што наведува 127.0.0.1 наместо домаќинот на базата на податоци. Следниот примамлив чекор е да се олабави sslmode, што ја замолчува проверката и ја фрла гаранцијата за идентитет што всушност ја сакавте. Вистинскиот проблем е што локалниот порт и името на серверот се чуваат во исто поле. Записот за libpq услуга ги разделува, па сокетот оди на препратениот порт, додека TLS уште го проверува името испечатено на сертификатот.

На што клиентот мисли дека се поврзува

Со sslmode=verify-full, libpq го споредува сертификатот што го презентира серверот со името на домаќинот што било побарано. Кога тоа име е loopback адреса, споредбата не успева иако сертификатот е валиден за вистинскиот домаќин на базата. SSH препраќањето менува кој сокет ги носи бајтите, не идентитетот што клиентот треба да го очекува. Откако овие две идеи ќе се разделат, грешката повеќе не изгледа како дефект на TLS.

Препраќањето исто така не е авторизација. PostgreSQL уште ги применува своите правила на врската што ја воспоставува SSH серверот, затоа држете ги транспортниот слој и слојот на базата одвоени пред да промените нешто.

Врзете го препраќањето само на loopback

Слушачот треба да постои на машината со QGIS и никаде на друго место. Изречното наведување на 127.0.0.1 го држи подалеку од другите интерфејси, додека испуштената адреса за врзување може да го изложи портот надвор во зависност од поставките за порта на SSH клиентот.

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

Одредиштето по втората две точки се решава од страната на SSH серверот, па овој пример претпоставува дека PostgreSQL е на истиот домаќин како sshd; база на друга машина бара таа адреса и нејзините дозволи. Стартувајте ја сесијата со -N за да не се отвори лушпа, не допирајте ја проверката на клучот на домаќинот и потврдете дека слушачот се појавува пред да го обвините QGIS. Ако портот е веќе зафатен, препраќањето паѓа при стартувањето, а не при барањето.

Ставете ги името и сокетот во еден запис за услуга

Датотеката за услуга му овозможува на истото поврзување да носи име за проверка и друго одредиште на сокетот. Зачувајте го записот таму каде што libpq бара услуги или насочете PGSERVICEFILE кон него.

[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

Тука host го задржува идентитетот што се користи за проверки на сертификатот, додека hostaddr ги испраќа пакетите на препратениот loopback порт, и двете се потребни за овој распоред да работи. gssencmode=disable е важен кај градбите што инаку прво би преговарале за GSSAPI шифрирање, бидејќи тој пат ги игнорира штотуку поставените TLS поставки. Повикајте се на услугата по име од дијалогот за PostgreSQL врска во QGIS и доставете ја лозинката преку вообичаеното прашање, а не внатре во споделена датотека. Имињата и патеките погоре се заменици; заменете ги со вашите одобрени вредности.

Што уште проверува PostgreSQL по тунелот

Серверот гледа врска од SSH домаќинот, во овој распоред loopback, и по ред ја споредува со правилата за автентикација засновани на домаќин. Вашата улога во базата уште мора да се автентицира, а најавата преку SSH сама по себе не дава идентитет во базата. Проверете што мисли серверот, а не што претпоставил клиентот.

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

Затворете ја сесијата за препраќање кога работата е завршена; локалниот запис тогаш престанува да работи и ништо друго не се менува. Една патека до база не е VPN за целиот GIS клиент, и токму третирањето како VPN е причината зошто следната врска се дијагностицира погрешно.

Поврзани статии