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 води до погрешна диагноза на следващата връзка.

Подобни статии