जब आप गलत सर्वर से कनेक्ट करने का प्रयास करते हैं तो क्या आपका SSH पासवर्ड सामने आया है?


192

जब आप गलती से पासवर्ड के साथ गलत सर्वर से जुड़ने का प्रयास करते हैं तो क्या आपके द्वारा उपयोग किए गए पासवर्ड को पढ़ना और लॉग इन करना व्यवस्थापक के लिए संभव है?



41
एक ssh क्लाइंट में, आप पहले सर्वर को प्रमाणित करते हैं और ऐसा करने पर आप कहते हैं "मुझे विश्वास है कि मैं इस सर्वर पर अपना पासवर्ड बता सकता हूं"। अगली बार आपके द्वारा पहले देखे गए संदेश पर ध्यान दें: "एक्स की प्रामाणिकता स्थापित नहीं की जा सकती। आरएसए कुंजी फिंगरप्रिंट वाई है क्या आप निश्चित रूप से जेड हैं (हां / नहीं)" यह कष्टप्रद प्रश्न नहीं पूछा जाएगा यदि आप चाहते हैं स्वचालित रूप से हर एक बार हां का जवाब देने के लिए ।
kubanczyk

6
PasswordAuthentication noओपनएसएसएच में डिफ़ॉल्ट रूप से सेट करना संभव है , और केवल विश्वसनीय सर्वर के लिए इसे (यदि / जब आवश्यक हो) सक्षम करें। सख्त होस्ट कुंजी जाँच के साथ संयुक्त, यह ज्यादातर आपको अपने पासवर्ड को उजागर करने से बचाता है, निश्चित रूप से सुविधा में।
हॉब्स

6
@kubanczyk, यदि आप SSH को "internal-www.my-company.com" करना चाहते थे, लेकिन गलती से "ssh www.my-company.com" में टाइप हो गया, तो यह संकेत आपकी रक्षा नहीं करेगा - संभावना है कि दोनों सर्वर हैं आपकी विश्वसनीय सूची में, यह सिर्फ इतना है कि उनमें से एक आपके द्वारा चलाया जाता है, और दूसरा किसी तीसरे पक्ष द्वारा।
मार्क

@hobbs, ChallengeResponseAuthentication noभी, मुझे लगता है
ilkkachu

जवाबों:


215

सरल डाल: हाँ

ज्यादा जानकारी...

यदि आप मेरी मशीन से जुड़ते हैं, तो आप नहीं जानते कि मैं सामान्य sshसर्वर चला रहा हूं , या एक जिसे पासवर्ड पारित करने के लिए लिखा गया है।

इसके अलावा, मुझे आवश्यक रूप से संशोधित करने की आवश्यकता नहीं होगी sshd, लेकिन एक PAM मॉड्यूल (जैसे का उपयोग करके pam_script) लिख सकता है , जो आपके पासवर्ड को पारित कर देगा।

तो हाँ। कभी भी अपना पासवर्ड किसी अविश्वसनीय सर्वर पर न भेजें। मशीन का मालिक आसानी से सभी प्रयास किए गए पासवर्ड को लॉग करने के लिए इसे कॉन्फ़िगर कर सकता था।

(वास्तव में यह infosec दुनिया में असामान्य नहीं है, पासवर्ड का प्रयास करने के लिए लॉग इन करने के लिए एक honeypot सर्वर सेट करें)


13
सही बात। डिफ़ॉल्ट रूप से, मानक पासवर्ड लॉग नहींsshd करता है । (यदि आप अपना पासवर्ड लॉगिन नाम के रूप में दर्ज करते हैं तो इसे लॉग इन किया जाएगा, लेकिन यह एक और समस्या है)। मानक एक सुरक्षा उपकरण है, और इसलिए यह इस तरह से क्रेडेंशियल लॉग नहीं करेगा :-)sshd
स्टीफन हैरिस

116
फिर भी सार्वजनिक / निजी कुंजी जोड़े का उपयोग करने का एक और कारण ...
gerrit

3
मैं कुछ समय के लिए अपने पासवर्ड के उपयोग के बारे में सोच रहा था और यह हाल ही में मुझ पर आया कि गलत सर्वर पर लॉग ऑन करने का प्रयास मेरे पासवर्ड को दुर्भावनापूर्ण सर्वर व्यवस्थापक को प्रकट करने का एक अच्छा तरीका होगा।
vfclists

10
गलत सर्वर पर लॉग ऑन करने वाले @vfclists भी ठीक यही कारण है कि आपका sshd क्लाइंट प्रत्येक सर्वर के लिए फिंगर प्रिंट स्टोर करता है। जब आप पहली बार कनेक्ट करते हैं, तो आप उस फिंगरप्रिंट को स्वीकार करते हैं, फिर बाद में यदि यह मेल नहीं खाता है, तो आपको एक विशाल चेतावनी मिलती है जिसे आपको ध्यान रखना चाहिए।
गृहनगर

44
बेहतर सलाह: ssh के लिए कभी भी पासवर्ड ऑउटफिट का उपयोग न करें । प्रोटोकॉल में बहुत अच्छे कारणों के लिए प्यूबिक ऑर्ट है; इसका इस्तेमाल करें!
आर ..

52

हाँ।

एन्क्रिप्टेड कनेक्शन स्थापित होने के बाद पासवर्ड भेजा जाता है, लेकिन रिमोट सर्वर को पासवर्ड को प्लेनटेक्स्ट में मिलता है।

यदि आप इस बारे में परवाह करते हैं, तो SSH कुंजियों का उपयोग करना सबसे अच्छा और आसान उपाय है।

यदि आपके पास ऐसी मशीनें हैं जो कुंजियों को स्वीकार नहीं कर सकती हैं, तो एक समाधान एक उपकरण बनाना होगा जो आपके पासवर्ड को सुरक्षित रूप से संग्रहीत करता है, और फिर sshpassआपके द्वारा कनेक्ट होने वाले सर्वर के आधार पर हमेशा सही पासवर्ड भेजने का उपयोग करता है।


अब, पासवर्ड को प्लेनटेक्स्ट में भेजने का कारण यह है कि यह हैंडलिंग और स्टोर करने के सभी निर्णयों को दूरस्थ छोर तक छोड़ देता है, और क्लाइंट पूरी तरह से गूंगा हो सकता है। पिछले दस वर्षों में (या ( क्रिप्टो (3) ) ) लिनक्स और बीएसडी सिस्टम में उपयोग किए जाने वाले विभिन्न पासवर्ड हैशिंग (स्टोरेज) स्वरूपों में से एक जोड़े हैं , जिनमें से किसी को भी क्लाइंट से समर्थन की आवश्यकता नहीं है।

हालांकि यह आंशिक रूप से इतिहास के कारण भी है (अर्थात यह हमेशा से ऐसा ही रहा है)। बेहतर चुनौती-प्रतिक्रिया प्रमाणीकरण प्रोटोकॉल हैं जो पासवर्ड के साथ भी उपयोग किए जा सकते हैं। उदाहरण के लिए , एसआरपी , जो प्रमाणीकरण के दौरान एक साझा रहस्य के साथ पार्टियों को प्रदान करता है। यह कुछ SSH सर्वरों के लिए लागू किया गया है, लेकिन OpenSSH के लिए पैच एक (बहुत) पुराने संस्करण के लिए है।


1
पासवर्ड प्रमाणीकरण के लिए चुनौती-प्रतिक्रिया प्रोटोकॉल के साथ समस्या यह है कि उनमें से कुछ को सर्वर को सादे-पाठ में पासवर्ड संग्रहीत करने की आवश्यकता होती है। यदि चुनौती-प्रतिक्रिया प्रोटोकॉल सर्वर के लिए एक हैशेड पासवर्ड स्टोर करने की अनुमति देता है, तो सबसे अधिक संभावना है कि एक बहुत विशिष्ट हैशिंग एल्गोरिथ्म की आवश्यकता होती है।
22

8
पासवर्ड आमतौर पर "प्लेनटेक्स्ट" में भेजे जाते हैं (यानी वास्तव में स्पष्ट नहीं, लेकिन केवल उस सुरक्षा के साथ जो अंतर्निहित SSH-TLS। जो भी कनेक्शन प्रदान करता है)। यदि पासवर्ड के लिए एक सिस्टम को हैशड क्लाइंट-साइड और हैश भेजने के लिए कहा जाता है, तो सर्वर के पास वास्तविक पासवर्ड प्राप्त करने का कोई तरीका नहीं होगा , और इसके बजाय पासवर्ड हैश प्रदान करने वाले किसी भी व्यक्ति को एक्सेस प्रदान कर सकता है , जिससे कहा गया हैश पासवर्ड-समतुल्य है। ।
ब्लैकलाइट शाइनिंग

1
@BlacklightShining शून्य-ज्ञान पासवर्ड प्रमाण मौजूद हैं, लेकिन SSH में उपयोग नहीं किए जाते हैं क्योंकि उनके लिए मानक पासवर्ड डेटाबेस का उपयोग करने का कोई तरीका नहीं है और कुंजी-आधारित प्रमाणीकरण के बजाय उनका उपयोग करने के लिए कोई वास्तविक बिंदु नहीं है।
रैंडम 832

मैं उन पासवर्डों को कहां देख सकता हूं जिन्हें प्रमाणित करने के लिए उपयोग किया जाता है? वे /var/log/auth.log में नहीं हैं, तब कहां हैं?
ッ ク ア

OpenSSH पासवर्ड लॉग नहीं करेगा, विफल या अन्यथा। (मैं अन्य SSH सर्वरों से बहुत परिचित नहीं हूं।) लगभग सभी वैध प्रतिष्ठानों में, कोई भी ऐसा मूल्य जो प्रदान कर सकता है, जान बूझकर पासवर्ड रिकॉर्ड करने में निहित जोखिम से आगे निकल जाएगा - जिनमें से कुछ वैध उपयोगकर्ताओं द्वारा प्रदान किए गए हो सकते हैं जिन्होंने टाइपो बनाया है या क्लीयरटेक्स्ट में गलत-लेकिन-राइट-फॉर-समथिंग-पासवर्ड की कोशिश की। यदि आपके पास ऐसा करने का एक अच्छा कारण है, हालांकि, ओपनएसएसएच को पैच करना आसान होगा।
म्यूज़िकमाइब्रेन

10

स्टीफन हैरिस के उत्तर के शीर्ष पर निर्माण करने के लिए, यहां एक वास्तविक समय दृश्य है जिसे मैंने बनाया है जो दिखाता है कि संशोधित PAM ऑर्टिकल स्क्रिप्ट बॉक्स पर कनेक्ट करते समय कैप्चर करने में सक्षम होगी (s honeypot of सॉर्ट)। मैं PAM पुस्तकालय के एक संशोधित संस्करण का उपयोग करता हूँ lib-storepw।

https://livesshattack.net

https://livesshattack.net/about


4
उत्तर जो मुख्य रूप से लिंक होते हैं, उन लिंक के अनुपलब्ध होने की स्थिति में डूब जाते हैं (ऐसा लगता है कि आप इस साइट को व्यक्तिगत रूप से बनाए रखते हैं, लेकिन फिर भी)। आपको थोड़ा वर्णन करना चाहिए कि आपने इसे पाठकों के लिए अपनी स्क्रिप्ट के साथ कैसे प्रबंधित किया।
सेंटिमेन

इसके काम नहीं करने पर, मैंने पासवर्ड के रूप में एक बहुत बड़ा तार भेजा, मुझे लगता है कि इसे तोड़ दिया गया हो सकता है, क्षमा करें: - /
scottydelta

@scottydelta हालांकि मैंने इस पर गौर नहीं किया है, लेकिन PAM मॉड्यूल के पासवर्ड के आकार या SSH डेमॉन पर एक बफर सीमा हो सकती है जो कि प्रमाणीकरण के प्रयास में स्वीकार की जा सकती है। साइट अभी भी काम कर रही है जैसा कि मैंने इरादा किया है, यद्यपि sshd या PAM मॉड्यूल द्वारा स्वीकार की गई बफर सीमा तक संभाल लेंगे यदि यह वास्तव में मामला है।
विली एस।

आउट ऑफ इंटरेस्ट आपके संशोधित lib-storepw का स्रोत है जो दूसरों के उपयोग के लिए उपलब्ध है?
टिम फ्लेचर

2

SSH एक प्रोटोकॉल है जिसमें पारस्परिक विश्वास की आवश्यकता होती है। यही कारण है कि ओपनएसएसएच क्लाइंट पहले उपयोग योजना पर अपने विश्वास को लागू करने के लिए एक ज्ञात_होस्ट फ़ाइल रखता है।

जब आप SSH सर्वर पर लॉगऑन करने का प्रयास करते हैं, तो इस बात की परवाह किए बिना कि सॉफ्टवेयर की आपूर्ति किसने की है या इसे लॉग करने के लिए कौन सा डेटा कॉन्फ़िगर किया गया है, आप कुछ प्रमाणीकरण प्रक्रिया में भाग ले रहे हैं। पासवर्ड प्रमाणीकरण का उपयोग करते समय, आप अपना पासवर्ड उस सर्वर पर संचारित कर रहे हैं। यह एक कारण है कि असममित क्रिप्टोग्राफी (सार्वजनिक कुंजी, प्रमाण पत्र) की सिफारिश की जाती है - सार्वजनिक कुंजी क्रिप्टोग्राफी आपके क्रेडेंशियल्स को प्रकट करने के जोखिम को बहुत कम करती है। (हालांकि यह ssh- एजेंट अग्रेषण या कुछ इसी तरह की योजना का उपयोग करते हुए आपको एक MitM हमले से नहीं बचा सकता है।)


SSH को पारस्परिक विश्वास की आवश्यकता नहीं है, या कम से कम सममित विश्वास नहीं है। सटीक होना महत्वपूर्ण है: ज्ञात_होस्ट प्रामाणिकता के बारे में है, विश्वास नहीं। जैसा कि आप बताते हैं, कम-विश्वसनीय होस्ट पर सार्वजनिक कुंजी रखना सुरक्षित है। वास्तव में, वहाँ लॉगिन करने के लिए एक पासवर्ड का उपयोग करना "सुरक्षित" है, यह मानते हुए कि आप उस पासवर्ड का पुन: उपयोग नहीं करते हैं। (यह केवल उस हद तक सुरक्षित है जितना आप सर्वर पर भरोसा करते हैं, निश्चित रूप से।) यहां तक ​​कि होस्ट किए गए ssh लॉगिन भी असममित ट्रस्ट पर निर्भर करते हैं।
मार्कहैन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.