QGIS PostGIS SSH թունել. պահեք սերվերի անունը 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-ով, որպեսզի ոչ մի shell չբացվի, ձեռք չտաք հոսթի բանալու ստուգմանը և համոզվեք, որ լսիչը հայտնվել է, նախքան 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 կարգավորումները։ Հղվեք ծառայությանը անունով QGIS-ի PostgreSQL միացման երկխոսությունից և գաղտնաբառը տրամադրեք սովորական հուշման միջոցով, ոչ թե ընդհանուր ֆայլի ներսում։ Վերևի անուններն ու ուղիները տեղապահեր են. փոխարինեք դրանք ձեր հաստատված արժեքներով։

Ինչ է PostgreSQL-ը դեռ ստուգում թունելից հետո

Սերվերը տեսնում է կապ SSH հոսթից՝ այս դասավորությունում loopback-ից, և հերթով համապատասխանեցնում է այն հոսթի վրա հիմնված նույնականացման կանոններին։ Ձեր տվյալների բազայի դերը դեռ պետք է նույնականանա, և SSH մուտքն ինքնին տվյալների բազայի ինքնություն չի տալիս։ Ստուգեք, թե ինչ է սերվերը կարծում, ոչ թե ինչ է ենթադրել կլիենտը։

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

Փակեք փոխանցման նստաշրջանը, երբ աշխատանքն ավարտված է. տեղական գրառումը դադարում է աշխատել, և այլևս ոչինչ չի փոխվում։ Տվյալների բազայի մեկ ուղին VPN չէ ամբողջ GIS կլիենտի համար, և դրան այդպես վերաբերվելն է պատճառը, որ հաջորդ կապը սխալ է ախտորոշվում։

Առնչվող հոդվածներ