अविश्वासनीय VPN मा तपाईंको SSH पासवर्ड वास्तवमा कसले देख्छ?

तपाईं आफैं सञ्चालन नगर्ने VPN मार्फत SSH सत्र पठाउनुहोस्, र पासवर्ड अझै SSH सर्भरकै रहन्छ, बीचको नेटवर्कको होइन। यदि प्रमाणित होस्टसम्मको यातायात राम्ररी सुरक्षित छ भने, त्यो बाटोको निष्क्रिय पर्यवेक्षक पासवर्ड पढ्न योग्य रूपमा पाउँदैन। तर एउटा सर्त बदल्नुहोस्, उत्तर पनि बदलिन्छ: अप्रमाणित होस्ट, कमजोर बनाइएको साइफर सूची, वा भंग भएको कार्यस्थान सबैले फरक नतिजा दिन्छन्। तलका जाँचहरू क्रममा गर्नुहोस्, र प्रत्येकलाई रोकिने सर्त मान्नुहोस्।

केही टाइप गर्नु अघि प्राप्तकर्ताको नाम लिनुहोस्

पासवर्ड फिल्ड प्रमाणीकरण सन्देशभित्र यात्रा गर्छ, र त्यो सन्देश इन्क्रिप्टेड यातायातभित्र यात्रा गर्छ। गोपनीयता यातायातको गुण हो, अर्थात् यो सुरक्षामा वार्ता भएको छ कि छैन र त्यो तपाईंले लक्ष्य गरेको होस्टसँगै भएको छ कि छैन भन्नेमा निर्भर गर्छ। मानिसहरूले ठ्याक्कै त्यो दोस्रो आधा छोड्छन्। ठगसँग इन्क्रिप्ट गरिएको जडान एकै समयमा गोप्य र व्यर्थ हुन्छ। VPN लगइनले SSH होस्टबारे केही प्रमाणित गर्दैन, र प्रदायकको प्रतिष्ठा कुञ्जी-जाँचको विकल्प होइन।

दुई दिशा मनमा अलग राख्नुहोस्। होस्ट कुञ्जीले तपाईं कुन सर्भरसम्म पुग्नुभयो भन्ने जवाफ दिन्छ। पासवर्ड वा कुञ्जी प्रमाणीकरणले सर्भरले कुन प्रयोगकर्ता स्वीकार्छ भन्ने जवाफ दिन्छ। दोस्रो सुधार्दा पहिलो कहिल्यै सुधारिँदैन।

होस्टको पहिचान, अभिलेख र वार्ता जाँच्नुहोस्

क्लाइन्टमा तपाईंसँग पहिले नै भएको अभिलेखबाट सुरु गर्नुहोस्। विश्वसनीय स्रोतसँग तुलना गरिएको प्रकाशित फिंगरप्रिन्ट, र अझै मिल्ने known_hosts प्रविष्टिले प्रमाणीकरण सुरु हुनु अघि महत्त्वपूर्ण एक मात्र प्रमाण दिन्छ।

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

सर्भरको तर्फ, प्रकाशित गर्न खोजिएका फिंगरप्रिन्टहरू सम्झनाबाट प्रतिलिपि गर्नुको सट्टा छाप्नुहोस्। तिनीहरूलाई च्यानलबाहिर वितरण गर्नु नै मुख्य कुरा हो; होस्टनामसँगै उही च्याट च्यानलबाट टाँसिएको फिंगरप्रिन्टले दुवै एउटै ठाउँबाट आए भन्ने मात्र प्रमाणित गर्छ।

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

वार्ता गरिएका एल्गोरिदम दुवै पक्षको प्रतिच्छेदनबाट आउँछन्। यदि क्लाइन्ट कन्फिगरेसनले पुरानो यन्त्रसम्म पुग्नका लागि अप्रचलित कुञ्जी विनिमय पिन गर्छ भने, त्यो छनोटले यो जससँग बोल्छ त्यसलाई लागू हुन्छ, त्यसैले यसलाई विश्वव्यापी नभई त्यही होस्टमा सीमित गर्नुहोस्।

सर्भरले वास्तवमा कुन विधि स्वीकार्छ त्यो पढ्नुहोस्

सर्भरले कुन प्रमाणीकरण विधिलाई अनुमति दिन्छ भन्ने थाहा पाउँदा पासवर्ड कुन कामको हो भन्ने बुझिन्छ। केवल सार्वजनिक कुञ्जी स्वीकार्ने होस्टसँग जोगाउनुपर्ने पासवर्ड विनिमय हुँदैन, र अझै पासवर्ड स्वीकार्ने होस्ट वंशाणुगत पूर्वनिर्धारितभन्दा सचेत निर्णयको योग्य हुन्छ।

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

प्रयोगकर्तालाई कुञ्जी प्रमाणीकरणमा सार्दा त्यो प्रयोगकर्ताको पासवर्ड त्यो विनिमयबाट हट्छ। यसले भंग भएको कार्यस्थान सुरक्षित बनाउँदैन, र अविश्वासनीय दूरस्थ सत्र हानिरहित बनाउँदैन। यी फरक नियन्त्रण भएका फरक जोखिम हुन्। एजेन्ट फर्वार्डिङबारे पनि निर्णय गर्नुहोस्। अविश्वासनीय होस्टमा एजेन्ट फर्वार्ड गर्दा सत्र चलिरहेसम्म त्यो होस्टले तपाईंका कुञ्जी प्रयोग गर्न सक्ने क्षमता पाउँछ, र यो सुरुको पासवर्ड प्रश्नभन्दा ठूलो जोखिम हो।

होस्ट-कुञ्जी चेतावनीलाई घटनाको चरणको रूपमा व्यवहार गर्नुहोस्

क्लाइन्टले होस्टको पहिचान बदलिएको चेतावनी दिँदा, रोक्नुहोस् र उही नेटवर्क मार्गबाट नजाने च्यानलमार्फत प्रमाणित गर्नुहोस्। फिंगरप्रिन्टलाई सर्भर कन्सोल वा यसलाई पुनर्निर्माण गर्ने अपरेटरसँग तुलना गर्नुहोस्। चेतावनी शान्त पार्न पुरानो प्रविष्टि मेटाउनु त्याग गर्नुपर्ने एक मात्र कार्य हो। यसले प्रमाण फ्याँक्छ र सम्भावित अवरोधलाई सामान्य लगइनमा बदल्छ।

यदि होस्ट वैध रूपमा पुनर्निर्माण गरिएको थियो भने, नयाँ फिंगरप्रिन्ट पुष्टि भएपछि मात्र पुरानो प्रविष्टि हटाउनुहोस्, त्यसपछि फेरि जडान गरी वार्ता फेरि जाँच्नुहोस्। परिवर्तन मिति र कारणसहित अभिलेख गर्नुहोस्, किनकि अर्को व्यक्तिले उही चेतावनी देख्नेछ र यो समाधान भइसकेको जान्न आवश्यक छ।

यो निर्देशिकाले के समेट्दैन

ट्राफिक हेरिरहेको VPN अपरेटर तपाईंको मेसिनमा स्थानीय विशेषाधिकार भएको सफ्टवेयरजस्तो होइन। अन्त्य बिन्दुको भंग, शत्रुतापूर्ण ब्राउजर एक्स्टेन्सन वा किबोर्ड लगर SSH ले वार्ता गर्न सक्ने सबैभन्दा तल बस्छन्, र कुनै सुरुङले त्यो बदल्दैन। यदि कार्यस्थान शंकास्पद छ भने, अर्को निकासबाट फेरि जडान गरेर गोपनीयता परीक्षण गर्नुको सट्टा घटना प्रक्रिया पालना गर्नुहोस्। फेरि जडान हुनुले नेटवर्क मार्ग बदलिएको प्रमाणित गर्छ, अन्त्य बिन्दुबारे केही होइन।

सामान्य अवस्थासँग अन्त्य गर्नुहोस्: प्रमाणित होस्ट, सुरक्षित यातायात, सचेत रूपमा छानिएको प्रमाणीकरण विधि, र आवश्यक नभएको कुनै फर्वार्डिङ नहुनु। यही संयोजन शीर्षकको प्रश्नको उत्तर हो, र यो एक होइन, चार निर्णय हुन्।