QGIS PostGIS SSH సొరంగం: TLS కోసం సర్వర్ పేరును ఉంచుకోండి
SSH ఫార్వార్డింగ్ QGIS కి స్థానిక పోర్టును ఇస్తుంది, కానీ డేటాబేస్ కు TLS కోసం దాని నిజమైన పేరు ఇంకా అవసరం. hostaddr మరియు loopback శ్రోతతో libpq సేవను ఉపయోగించండి.
సొరంగం పైకి వస్తుంది, 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 గా భావించడమే తదుపరి కనెక్షన్ తప్పుగా నిర్ధారణ చేయబడడానికి కారణం.