SSH पासवर्ड प्रमाणीकरण एक सुरक्षा जोखिम क्यों है?

68

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

— Septagram
स्रोत

2

पासवर्ड एक-कारक प्रमाणीकरण है जिसे सूँघा, अनुमान लगाया और दोहराया जा सकता है। कुंजी (संभवतः) दो-कारक हैं। सिर्फ एक कारक के साथ कहीं से भी लॉग इन करने में सक्षम होना कुछ प्रणालियों पर अस्वीकार्य है।

— एलेक्स हॉल्स्ट

25

प्रॉप और की-बेस्ड ऑथेंटिकेशन के लिए प्रो और कोन हैं।

कुछ मामलों में, उदाहरण के लिए, कुंजी-आधारित प्रमाणीकरण पासवर्ड प्रमाणीकरण की तुलना में कम सुरक्षित है। अन्य मामलों में, इसका pw- आधारित यह कम सुरक्षित है। कुछ मामलों में, एक अधिक सुविधाजनक है, दूसरों में, कम है।

यह सब इसके लिए उबलता है: जब आप कुंजी-आधारित प्रमाणीकरण करते हैं, तो आपको पासफ़्रेज़ के साथ अपनी कुंजी सुरक्षित करनी होगी । जब तक आपके पास ssh-agent चल रहा हो (ssh-agent आपको हर बार अपने पासफ़्रेज़ में प्रवेश करने से मुक्त कर देता है), तो आपने सुविधा के मामले में कुछ भी प्राप्त नहीं किया है। सुरक्षा विवादित है: हमला वेक्टर अब सर्वर से आपको, या आपके खाते, या आपकी व्यक्तिगत मशीन, (...) में स्थानांतरित कर दिया गया है - वे टूटना आसान नहीं हो सकता है या नहीं।

इसे तय करते समय बॉक्स के बाहर सोचें। चाहे आप सुरक्षा के मामले में लाभान्वित हों या ढीले हों, यह आपके पर्यावरण और बाकी उपायों पर निर्भर करता है।

संपादित करें: ओह, बस देखा कि आप होम सर्वर के बारे में बात कर रहे हैं। मैं एक ही स्थिति में था, "पासवर्ड" या "उस पर चाबी के साथ यूएसबी स्टिक" हमेशा मेरे साथ? मैं पूर्व के लिए गया था, लेकिन 22 से कुछ अलग करने के लिए SSH श्रवण बंदरगाह को बदल दिया। यह पूरे नेटवर्क रेंज के लिए मजबूर उन सभी लंगड़ा लिपि kiddies जानवर को रोकता है।

— रोमन
स्रोत

22 से SSH पोर्ट बदलना कई मामलों में एक अच्छा विचार नहीं हो सकता है। adayinthelifeof.nl/2012/03/12/…

— Tymek

75

Ssh कीज़ का उपयोग करना पासवर्ड लॉगिन की तुलना में एक अनूठी विशेषता है: आप अनुमत कमांड को निर्दिष्ट कर सकते हैं। यह ~/.ssh/authorized_keysसर्वर पर फ़ाइल को संशोधित करके किया जा सकता है ।

उदाहरण के लिए,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

उस विशेष कुंजी के साथ केवल कमांड `/usr/local/bin/your_backup_script.sh 'की अनुमति देगा।

आप कुंजी के लिए अनुमत मेजबानों को भी निर्दिष्ट कर सकते हैं:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

या दोनों को मिलाएं:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

कुंजियों के साथ आप उस विशेष खाते के पासवर्ड का खुलासा किए बिना किसी सर्वर के लिए कुछ उपयोगकर्ता (जैसे, एक सलाहकार) को अस्थायी पहुंच प्रदान कर सकते हैं। सलाहकार ने अपनी नौकरी समाप्त करने के बाद, अस्थायी कुंजी को हटाया जा सकता है।

— जने पिक्कारेंन
स्रोत

बहुत उपयोगी टिप।

— सचिन दिवेकर

3

इसके अतिरिक्त कीज़ का उपयोग करना एक लंबे 2000 वर्ण पासवर्ड (तकनीकी रूप से इसकी और भी अधिक मजबूती) के समान है, जिसकी तुलना में आप टर्मिनल में मैन्युअल रूप से कुंजी कर सकते हैं: D

— अभिषेक दुजारी

3

SSH प्रमाणीकरण के बारे में दो बहुत उपयोगी टिप्स, लेकिन वास्तव में मेरे लिए इस सवाल का जवाब नहीं देता है ...

— मीकमर्को

यदि आप पासवर्ड-प्रमाणित उपयोगकर्ता को किसी विशिष्ट कमांड से जाने के लिए बाध्य करना चाहते हैं, तो उसका लॉगिन शेल बदलें। इसके अलावा, "पासवर्ड का खुलासा किए बिना अस्थायी पहुंच प्रदान करना" एक बहुत बुरा विचार है। बाद में पहुंच को बनाए रखने के लिए सैकड़ों अलग-अलग तरीके हैं।

— b0fh

अंतिम पैराग्राफ अकेले सवाल का जवाब देता है आईएमओ - चाबियाँ बारीक निरसन के लिए अनुमति देती हैं, जबकि पासवर्ड के साथ आपको हर किसी को सूचित करने की आवश्यकता होती है कि आप इसे बदल रहे हैं।

— सवारी

48

आप केवल अपने नेटवर्क से पासवर्ड प्रमाणीकरण की अनुमति देकर दोनों दुनिया के सर्वश्रेष्ठ प्राप्त कर सकते हैं। निम्नलिखित को अपने अंत में जोड़ें sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

— MikeyB
स्रोत

7

आपने अपने प्रश्न का आंशिक रूप से जवाब दिया है - हमलावर जितनी अधिक जगहों से जुड़ सकते हैं, उतनी अधिक संभावनाओं को उन्हें अपने सर्वर में तोड़-मरोड़ कर (डीडीओएस पर विचार) करना होगा।

अपने पासवर्ड की लंबाई की कुंजी आकार (आमतौर पर हजारों बिट्स) से तुलना करें।

— मार्टिन वेजमेलका
स्रोत

4

96-बिट्स ऑफ एन्ट्रॉपी का मतलब है 80-अक्षर वाला पासवर्ड, अगर यह अंग्रेजी में लिखा गया है; 15 अक्षर अगर यह मुद्रण योग्य वर्ण सेट से यादृच्छिक अस्पष्ट है। क्या आप सुनिश्चित हैं कि आपके ssh पासवर्ड लंबे / मजबूत हैं?

— मध्याह्न

3

यदि आपके पास 96-बिट्स एन्ट्रापी के साथ कई पासवर्ड हैं जो डिक्शनरी हमलों के लिए असुरक्षित नहीं हैं, तो संभवतः आपको किसी प्रकार के पासवर्ड प्रबंधन सॉफ़्टवेयर का उपयोग करने की आवश्यकता है, इसलिए आप पासवर्ड का उपयोग करने के लिए हर जगह प्रभावी रूप से सुलभ खो देते हैं। ।

— निक डाउटन

5

@SachinDivekar कि एन्ट्रापी के 96 बिट्स केवल अगर सेट से रैंडम पासवर्ड का उपयोग करते हैं [a-zA-Z], नहीं तो यह अंग्रेजी के शब्द हैं।

— जाप एल्डरिंग 15

16

@ नाइकडाउनटन - केपास सॉफ्टवेयर का सहारा लिए बिना आपके पास एक अच्छा लंबा पासवर्ड हो सकता है। कुछ ऐसा है जो mywifesnameisangelaandshehasanicebuttशब्दकोश के हमलों के लिए अजेय है, बहुत मजबूत है, और याद रखने में बहुत सरल है, लेकिन अनुमान लगाना असंभव है। और यह बोनस के साथ आता है यदि ब्राउनी इंगित करता है यदि आपको कभी भी अपनी पत्नी को अपना पासवर्ड देने की आवश्यकता होती है।

— मार्क हेंडरसन

7

क्षमा करें, मार्क, लेकिन यह गलत है। आपके द्वारा दिए गए पासफ़्रेज़ में 37 अक्षर हैं और इसलिए लगभग 44 बिट्स ऑफ एन्ट्रॉपी है, जो 7 यादृच्छिक प्रिंट करने योग्य वर्णों से कमजोर है, और उल्लेखनीय रूप से हमला करने योग्य है। विवरण के लिए क्लाउड शैनन के काम पर विकिपीडिया का लेख पढ़ें, लेकिन यह अपशगुन है कि लिखित अंग्रेजी अत्यधिक अनुमानित है - उदाहरण के लिए, "mywifesname" के बाद, शब्द "है" लगभग गारंटी है। शब्दों को शामिल करने वाले मजबूत पासवर्डों के लिए, एक शब्दकोष से एक साथ चार यादृच्छिक शब्द आपको कुछ 10 ** 23 संभावनाएं देंगे, जो कि 77 बिट्स के बारे में है; अभी भी महान नहीं है, लेकिन बुरा नहीं है।

— MadHatter

7

जब आप किसी पासवर्ड से लॉग इन करते हैं तो आप अपना पासवर्ड सर्वर पर भेजते हैं। इसका मतलब है कि सर्वर का ऑपरेटर आपके पासवर्ड तक पहुंच प्राप्त करने के लिए SSHD को संशोधित कर सकता है। सार्वजनिक कुंजी प्रमाणीकरण के साथ, वे आपकी निजी कुंजी प्राप्त नहीं कर सकते हैं क्योंकि केवल आपकी सार्वजनिक कुंजी सर्वर पर जाती है।

— रेमन
स्रोत

2

यह विशेष रूप से प्रासंगिक है जब आप टाइपो के कारण गलत सर्वर से कनेक्ट होते हैं। उदाहरण के लिए, कुछ समय में, .cg एक वाइल्डकार्ड था, जो ssh सक्षम के साथ एकल मशीन की ओर इशारा करता था। कभी भी आप गलत .cg .ch के लिए, आप उस बॉक्स से

— जुड़कर

@ b0fh वास्तव में। जहाँ तक मैं बता सकता हूँ, यह ssh के साथ पासवर्ड का उपयोग करके शुरू की गई एकमात्र वास्तविक भेद्यता है। यदि कोई पहले से ही आपके द्वारा कनेक्ट किए जा रहे सर्वर का मालिक है, या आपके (MITM) से कनेक्ट होने वाले IP पते को खराब कर सकता है, तो आप पहले ही खो चुके हैं।

— हॉब्स

6

ssh कीज़ आपके पासवर्ड पर मध्यम आधारित हमलों में आदमी को रोकती हैं।

जब आप एक कुंजी के साथ लॉगिन करने का प्रयास करते हैं तो सर्वर आपकी सार्वजनिक कुंजी के आधार पर एक चुनौती का निर्माण करेगा और इसे आपके क्लाइंट को भेज देगा। जो इसे डिक्रिप्ट करेगा और भेजने के लिए एक उचित प्रतिक्रिया का निर्माण करेगा।

आपकी निजी कुंजी कभी भी सर्वर को नहीं भेजी जाती है और सुनने वाला कोई भी व्यक्ति उस एकल सत्र को छोड़कर कुछ भी करने में असमर्थ होता है।

पासवर्ड के साथ उनके पास आपकी साख होगी।

मेरा समाधान एक USB कुंजी पर एक एन्क्रिप्टेड विभाजन पर उपयुक्त स्वरूपों में एक पोर्टेबल ssh कुंजी है। यह मुझे इसकी अनुमति देता है:
आसानी से खो जाने की स्थिति में उस कुंजी को वापस लेना।
प्रतिबंधित है जो सर्वर यह मुझे का उपयोग करने
और अभी भी इसे चारों ओर ले जाने की अनुमति देता है

हालांकि माउंट सॉफ्टवेयर स्थापित करना एक दर्द है (ट्रुकक्रिप्ट)

— Tacticus
स्रोत

1

ये गलत है। जैसे ही आप सर्वर की सार्वजनिक कुंजी जानते हैं (जो आप करते हैं यदि आपने इसे अपने कैश में जोड़ा है और पहले कनेक्शन पर MITM'd नहीं मिला है) तो आप MITM हमलों के लिए प्रतिरक्षा हैं। कुंजी / पासवर्ड-आधारित प्रमाणीकरण का इससे कोई लेना-देना नहीं है। पासवर्ड को तार पर स्पष्ट रूप से कभी नहीं भेजा जाता है, मशीन-स्तर प्रमाणीकरण (आपका / मेरी सार्वजनिक कुंजी क्या है) पर एक सुरक्षित कनेक्शन हमेशा उपयोगकर्ता-स्तर प्रमाणीकरण से पहले सेट किया जाता है (जो आपका पासवर्ड / मेरे लिए यह सार्वजनिक कुंजी है वह आपका है) ।

— थॉमस

3

थॉमस, वास्तव में कई लोग फिंगरप्रिंट परिवर्तन के बारे में चेतावनी को अनदेखा करते हैं। Pubkey अथॉरिटी MITM सुरक्षा की गारंटी देती है, भले ही सर्वर की निजी कुंजी किसी तरह समझौता हो जाए या मानव प्रकार "हाँ" अनुपस्थित हो: हमलावर को यातायात देखने में सक्षम नहीं होने और सार्वजनिक कुंजी भेजने के बीच चयन करना होगा जो लॉग नहीं करेगा, जो कि एक है जीत।

— स्कोर_उंडर

5

और उत्तर देने वाले के लिए: आपको ट्रुकक्रिप्ट का उपयोग करने की आवश्यकता नहीं है, ओपेनश निजी कुंजी अपने स्वयं के वैकल्पिक पासवर्ड-आधारित एन्क्रिप्शन के साथ आते हैं।

— स्कोर_उंडर

5

यह @MartinVejmelka कहती है, यह एक व्यापार बंद है।

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

पासवर्ड में निम्नलिखित समस्याएं हैं:

यदि यह छोटा है तो यह मजबूर किया जा सकता है
अगर यह लंबा है तो आसानी से भुला दिया जा सकता है
इसे कंधे पर लगाया जा सकता है

एक कुंजी लंबे समय तक परिमाण का आदेश है, और किसी भी बिंदु पर प्रदर्शित नहीं किया जाता है इसलिए यह इन तीन मुद्दों से बचा जाता है।

— रोरी अलसॉप
स्रोत

लेकिन एक महत्वपूर्ण फ़ाइल का उपयोग करने से पेन ड्राइव, या जो भी भंडारण आप उपयोग कर रहे हैं, खोने का मुद्दा जुड़ जाता है।

— जोहो पोर्टेला

1

किस बिंदु पर खोई हुई कुंजी को हटाया जा सकता है, और एक नई कुंजी जोड़ी गई है। पासवर्ड (विशेष रूप से साझा किए गए पासवर्ड) के साथ, यह मुझे एक दर्द हो सकता है, और इसमें बहुत अधिक कराहना शामिल है।

— SplinterReality

मेरे (हाल ही में सेवानिवृत्त) पासवर्ड में से एक 08Forging2?seminal*^Rajas-(Posed/|:। यह अनियमित रूप से उत्पन्न होता है लेकिन मुझे इसे याद रखने में कोई परेशानी नहीं है। और गुड लक शोल्डर-सर्फिंग या ब्रूट-फोर्सिंग।

— 14

1

@finnw :-) सही हार्स बैटरी स्टेपल security.stackexchange.com/q/6095/485

— रोरी Alsop

2

यहाँ पहले से ही उल्लेख किए गए अच्छे बिंदु।

मैं जो सबसे बड़ा जोखिम मानता हूं, उसे देखते हुए आपने एक मजबूत पासवर्ड के साथ मूल बातों का ध्यान रखा है, यह है कि बहुत सारे कंप्यूटरों में उपयोगकर्ता को साकार किए बिना keyloggers स्थापित हैं। यहां तक कि उपयोगी उपयोगिताओं की पूरी साइटें बनाने वाले लोग हैं जिनमें ट्रोजन शामिल हैं, इसलिए यह हम में से सबसे अच्छा हो सकता है। एक keylogger उदाहरण के लिए एक हैकर को लॉगिन विवरण ईमेल करेगा जो तब आसानी से सर्वर तक पहुंच सकता है।

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

— टेड हंसन
स्रोत

2

पासवर्ड पर SSH का एक संभावित लाभ यह है कि यदि आप SSH पासफ़्रेज़ को निर्दिष्ट नहीं करते हैं, तो आपको फिर से पासवर्ड टाइप करने की आवश्यकता नहीं है ... आपके कंप्यूटर को सर्वर पर आंतरिक रूप से भरोसा है क्योंकि इसके पास कुंजी है। उस ने कहा, मैं आमतौर पर SSH पासफ़्रेज़ का हमेशा उपयोग करता हूं इसलिए मैं यह नियम करता हूं कि इससे लाभ होता है।

मुझे लगता है कि क्यों उपयोगकर्ता गाइड अक्सर SSH पासवर्ड के लिए SSHpenSSHKeys के लिए Ubuntu मैनुअल से आता है पर SSH की सिफारिश करने के लिए सबसे अच्छा जवाब मिलता है। मैं उद्धृत करता हूं,

यदि आपको नहीं लगता कि यह महत्वपूर्ण है, तो अगले सप्ताह के लिए मिलने वाले सभी दुर्भावनापूर्ण लॉगिन प्रयासों को लॉग इन करने का प्रयास करें। मेरा कंप्यूटर - एक पूरी तरह से साधारण डेस्कटॉप पीसी - मेरे पासवर्ड का अनुमान लगाने के लिए 4,000 से अधिक प्रयास किए थे और पिछले सप्ताह अकेले में लगभग 2,500 ब्रेक-इन प्रयास किए थे। आपको लगता है कि आपके पासवर्ड में एक हमलावर के ठोकर खाने से पहले कितने हजार यादृच्छिक अनुमान हैं?

अनिवार्य रूप से यदि आपके पास विराम चिह्न, ऊपरी और निचले मामले, और संख्याओं के साथ एक ठोस ठोस लंबाई वाला पासवर्ड है ... तो आप शायद पासवर्ड प्रमाणीकरण के लिए ठीक होंगे। इसके अलावा अगर आप अपने लॉग की निगरानी करने की योजना बनाते हैं, और नेटवर्क वैसे भी "सुपर सिक्योर" सामान नहीं कर रहे हैं ... तो इसका उपयोग होम सर्वर के लिए करें। फिर हर तरह से, एक पासवर्ड अच्छी तरह से काम करता है।

— MikeMurko
स्रोत

1

Passwd ऑर्टिकल मेथड वास्तव में असुरक्षित है (imho)। इस तंत्र के साथ पासवर्ड को sshd सर्वर पर प्रसारित किया जाएगा (जैसे @ श्रमण ने पहले ही कहा है)। इसका मतलब है कि कुछ व्यक्ति पासवर्ड को पुनः प्राप्त करने के लिए sshd सर्वर को संशोधित कर सकते हैं। मैन-इन-द-मिडिल हमले के साथ स्थानीय नेटवर्क के अंदर इसे पूरा करना बहुत आसान है।

आप बस इस पैच ( https://github.com/jtesta/ssh-mitm ) को स्थापित करके sshd सर्वर को पैच कर सकते हैं । का प्रयोग करें arpspoofऔर iptablesग्राहक और प्रामाणिक sshd सर्वर के बीच अपने समझौता सर्वर डाल करने के लिए।

कृपया पासवर्ड को अक्षम करें: कॉन्फ़िगर फ़ाइल खोलें /etc/ssh/ssh_configऔर लाइन जोड़ें PasswordAuthentication no।

— Pioz
स्रोत

RSA फिंगरप्रिंट के लिए SSH क्लाइंट चेक सर्वर नहीं है? कम से कम एक बार इस विशेष सर्वर पर जाने के बाद, यह फिंगरप्रिंट को याद किया जाएगा, इसलिए संभावित MITM हमलों के मामले में SSH एक चेतावनी को रोशन करेगा, है ना?

— सेप्टाग्राम

1

हाँ। चेतावनी दिखाई देती है, लेकिन ओएस पुनर्स्थापना के कारण 99% समय लगता है, कॉन्फ़िगर ecc, अधिकांश उपयोगकर्ता चेतावनी को अनदेखा करेंगे और आगे बढ़ेंगे।

— Pioz

@ सेप्टग्राम कई शेल खाता प्रदाता नए ग्राहकों के लिए नए सर्वर के लिए वर्तमान सर्वर कुंजी फिंगरप्रिंट पोस्ट करने की आदत में नहीं हैं, नए सर्वरों के लिए उपयोगकर्ता खातों के प्रवास के लिए, आदि

— डेमियन येरिक

-2

आप -o StrictHostKeyChecking=noविकल्प के साथ बायपास कर सकते हैं । शेल स्क्रिप्ट में ssh का उपयोग करते समय यह बहुत उपयोगी है।

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost

— arganzheng
स्रोत