SSH फर्वार्डिङले स्थानीय पोर्ट 13306 मा सुन्छ, तर mysql अझै स्थानीय डाटाबेसमा जोडिन्छ—वा यसको स्थानीय सकेट छैन भनी रिपोर्ट गर्छ। Unix मा localhost दिइएको MySQL क्लाइन्टले TCP को सट्टा Unix सकेट छनोट गर्न सक्छ। पोर्ट दिनुले त्यो छनोट अनिवार्य रूपमा परिवर्तन गर्दैन।

विद्यमान स्वीकृत TCP फर्वार्डका लागि प्रोटोकल स्पष्ट पार्नुहोस्:

mysql --protocol=TCP --host=127.0.0.1 --port=13306 \
  --user=dbuser --password

प्रयोगकर्ता नाम केवल उदाहरण हो; पासवर्ड विकल्पले अन्तरक्रियात्मक इनपुट माग्छ। कमाण्डले Unix सकेटको सट्टा स्थानीय TCP श्रोतासँग जोडिन्छ।

दुई लगइन अलग राख्नुहोस्

स्थिर SSH मार्गको यो आकार हुन सक्छ:

ssh -N -L 127.0.0.1:13306:db.internal:3306 [email protected]

गेटवेको SSH सर्भरले db.internal:3306 सम्म पुग्छ। त्यसपछि MySQL ले त्यो बाइट स्ट्रिममार्फत डाटाबेस खाता प्रमाणित गर्छ। स्वीकार गरिएको SSH कुञ्जीले डाटाबेस लगइन दिँदैन, र डाटाबेसको स्रोत प्रतिबन्धहरूले जडान मार्गको त्यो छेउबाट आएको देख्छन्।

यो स्थिर TCP एडाप्टर हो, mysql ले उपभोग गर्ने SOCKS सेटिङ होइन। फर्वार्डिङ इन्डपोइन्टमा एक पूर्वनिर्धारित लक्ष्य भएकाले अनुप्रयोगलाई SOCKS वार्ताको आवश्यकता पर्दैन।

जहाँ प्रयोग हुन्छ त्यहाँ इच्छित डाटाबेस TLS पहिचान र प्रमाणपत्र नीति कायम राख्नुहोस्। सकेटलाई loopback मा जोड्दा डाटाबेस प्रमाणपत्र अर्को सेवा नामका लागि मान्य हुँदैन। सफल स्थानीय TCP जडानले यातायातको छनोट टुङ्ग्याउँछ, पछिको डाटाबेस प्रमाणीकरण वा TLS जाँचहरू होइनन्।

सम्बन्धित लेखहरू