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-ით, რომ არც ერთი ჭურვი არ გაიხსნას, ხელი არ ახლოთ ჰოსტის გასაღების შემოწმებას და დარწმუნდით, რომ მსმენელი გამოჩნდა, სანამ 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 კლიენტისთვის, და სწორედ ასე მოპყრობა იწვევს შემდეგი კავშირის არასწორ დიაგნოზს.

დაკავშირებული სტატიები