विश्वासार्ह नसलेल्या 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 बोलणी करू शकणाऱ्या सगळ्याच्या खाली असतात, आणि कोणताही बोगदा ते बदलत नाही। वर्कस्टेशन संशयास्पद असेल, तर दुसऱ्या एग्झिटने पुन्हा कनेक्ट करून गोपनीयता तपासण्याऐवजी घटना प्रक्रिया अनुसरा। पुन्हा कनेक्ट होणे नेटवर्क मार्ग बदलला हे सिद्ध करते, एंडपॉइंटबद्दल काहीही नाही।

नेहमीच्या प्रकरणाने संपवा: सत्यापित होस्ट, संरक्षित वहन, जाणीवपूर्वक निवडलेली प्रमाणीकरण पद्धत, आणि गरज नसलेले कोणतेही फॉरवर्डिंग नाही। हेच संयोजन शीर्षकातील प्रश्नाचे उत्तर आहे, आणि ते एक नाही, चार निर्णय आहेत।