Тунэль 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 прыводзіць да няправільнай дыягностыкі наступнага злучэння.

Падобныя артыкулы