QGIS PostGIS SSH बोगदा: TLS साठी सर्व्हरचे नाव ठेवा

बोगदा वर येतो, 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"

काम संपल्यावर फॉरवर्डिंग सत्र बंद करा; स्थानिक नोंद नंतर काम करणे थांबवते आणि दुसरे काहीही बदलत नाही. डेटाबेसचा एक मार्ग संपूर्ण GIS क्लायंटसाठी VPN नाही, आणि त्याला VPN मानणे हेच पुढच्या कनेक्शनचे चुकीचे निदान होण्याचे कारण आहे.