SSH कुंजियाँ समझाई गईं
SSH कुंजी प्रमाणीकरण बिना पासवर्ड के सर्वर में लॉग इन करने का तरीका है: सर्वर जिस रहस्य की जाँच कर सके उसे टाइप करने के बजाय, आपका कंप्यूटर सर्वर द्वारा भेजी गई चुनौती पर हस्ताक्षर करके यह साबित करता है कि उसके पास निजी कुंजी है, और सर्वर अपने पास पहले से मौजूद सार्वजनिक कुंजी से हस्ताक्षर की जाँच करता है। निजी कुंजी कभी नेटवर्क पार नहीं करती, इसलिए रोकने को कुछ नहीं है, फ़िशिंग से ठगने को कुछ नहीं है, और अनुमान लगाने को कुछ नहीं है। इस लेख में बताया गया है कि कुंजी जोड़ी के दोनों हिस्से कैसे काम करते हैं, 2026 में किस प्रकार की कुंजी चुनें, फ़िंगरप्रिंट पहले कनेक्शन पर बीच वाले को कैसे रोकते हैं, authorized_keys और known_hosts को साफ़ कैसे रखें, और कुंजी लीक होने पर वास्तव में क्या करें। ब्राउज़र में कुंजी बनाने, जाँचने या बदलने के लिए SSH Key Suite का उपयोग करें, और जिन पासवर्डों का आप अब भी उपयोग करते हैं उनकी जाँच के लिए पासवर्ड लीक जाँच का उपयोग करें।
SSH कुंजी प्रमाणीकरण क्या है
हर लॉगिन सर्वर द्वारा पूछा गया एक सवाल है — क्या आप वही हैं जो आप होने का दावा करते हैं? — और पासवर्ड इसका जवाब रहस्य को ही सौंपकर देता है। यही पूरी व्यवस्था की कमज़ोरी है: रहस्य यात्रा करता है, उसे सुना जा सकता है, उसे दोबारा चलाया जा सकता है, और उसे तब तक बार-बार अनुमान लगाया जा सकता है जब तक वह टूट न जाए। SSH कुंजी प्रमाणीकरण जवाब को बदल देता है। रहस्य भेजने के बजाय, आपका कंप्यूटर एक निजी कुंजी से सर्वर की यादृच्छिक चुनौती पर हस्ताक्षर करता है जो आपकी मशीन को कभी नहीं छोड़ती, और सर्वर आपकी authorized_keys फ़ाइल में संग्रहीत सार्वजनिक कुंजी से हस्ताक्षर की जाँच करता है। प्रमाण हर बार नया होता है, क्योंकि चुनौती यादृच्छिक है; रहस्य कभी तार पर नहीं आता, इसलिए सुनने वाला कुछ भी ऐसा नहीं सीखता जिसे वह दोबारा उपयोग कर सके, और अनुमान लगाने के लिए कोई पासवर्ड नहीं है, क्योंकि इसमें कोई पासवर्ड शामिल ही नहीं है।
यह विचार आधुनिक इंटरनेट से भी पुराना है — सार्वजनिक-कुंजी क्रिप्टोग्राफी 1970 के दशक की है — लेकिन SSH ने इसे सर्वर तक पहुँचने का रोज़मर्रा का तरीका बना दिया, और प्रोटोकॉल तब से इसे निभा रहा है। जब आप ssh user@server चलाते हैं, तो क्लाइंट और सर्वर एक सत्र पर सहमत होते हैं, सर्वर आपके खाते से जुड़ी एक चुनौती प्रस्तुत करता है, और आपका SSH एजेंट निजी कुंजी से उस पर हस्ताक्षर करता है, आमतौर पर तब जब आपने पासफ़्रेज़ से कुंजी को एक बार अनलॉक कर लिया हो। यदि हस्ताक्षर सत्यापित हो जाता है, तो आप अंदर हैं। इस आदान-प्रदान में ऐसा कुछ भी नहीं है जो किसी साझा रहस्य पर निर्भर हो जिसे सर्वर भी जानता हो, और इसीलिए सर्वर में सेंध लगने से आपके क्रेडेंशियल उजागर नहीं होते: सर्वर के पास केवल सार्वजनिक कुंजियाँ हैं, और सार्वजनिक कुंजी लॉग इन करने के लिए बेकार है। यह असममितता — सर्वर सत्यापित कर सकता है लेकिन आपका रूप नहीं धर सकता — कुंजियों का पूरा सुरक्षा तर्क है, और यही कारण है कि निजी हिस्से पर नियंत्रण खोना ही एकमात्र मायने रखने वाली विफलता है।
सार्वजनिक कुंजी और निजी कुंजी
कुंजी जोड़ी दो हिस्से हैं जिनके नियम एक-दूसरे के उलट हैं, और अधिकांश SSH गलतियाँ उन्हें एक जैसा मानने से आती हैं। सार्वजनिक कुंजी हर जगह कॉपी करने के लिए है: इसे अपने हर सर्वर की authorized_keys में, अपने Git होस्टिंग खाते में, SSH कुंजियाँ स्वीकार करने वाली किसी भी सेवा में पेस्ट करें। इसे सार्वजनिक रिपॉजिटरी में प्रकाशित किया जा सकता है, स्लाइड पर छापा जा सकता है, या व्यवस्थापक को ईमेल किया जा सकता है, क्योंकि इससे कोई भी केवल हस्ताक्षर की जाँच कर सकता है। आपकी सार्वजनिक कुंजी जानने से हमलावर को लॉग इन करने के लिए कुछ नहीं मिलता, जैसे आपका मकान नंबर जानने से किसी को आपके मुख्य द्वार की चाबी नहीं मिलती। सार्वजनिक आधा हिस्सा ताला है, चाबी नहीं, और ताले दिखने के लिए ही बने होते हैं।
निजी कुंजी स्वयं चाबी है, और इसका नियम ठीक उलटा है: यह आपकी मशीन को कभी नहीं छोड़ती, केवल आप इसे पढ़ सकते हैं, और इसे कभी चैट, टिकट, ईमेल, फ़ोरम पोस्ट या साझा दस्तावेज़ में पेस्ट नहीं करना चाहिए — यह पूछने के लिए भी नहीं कि यह सुरक्षित है या नहीं। जिसके पास यह है, वह हर उस सर्वर पर आपकी तरह लॉग इन कर सकता है जो मिलती-जुलती सार्वजनिक कुंजी पर भरोसा करता है, बिना पासवर्ड पूछे और बिना दूसरे कारक के — जब तक आपने उसे कॉन्फ़िगर न किया हो। डिस्क पर यह ~/.ssh में रहती है, फ़ाइल अनुमतियों से सुरक्षित — chmod 600, केवल मालिक पढ़-लिख सकता है — और आदर्श रूप से पासफ़्रेज़ से भी, जो फ़ाइल को एन्क्रिप्ट करता है ताकि चुराई गई प्रति उन शब्दों के बिना बेकार रहे जो इसे अनलॉक करते हैं। पासफ़्रेज़ कुंजी का हिस्सा नहीं है; यह उस डिब्बे पर ताला है जिसमें चाबी रखी है। डिब्बा खो जाए तो ताला ही चोर और आपके सर्वरों के बीच एकमात्र चीज़ है, और इसीलिए बिना पासफ़्रेज़ की निजी कुंजी को कभी उस मशीन को नहीं छोड़ना चाहिए जिस पर आपका पूरा नियंत्रण है।
Ed25519 बनाम ECDSA बनाम RSA: 2026 में क्या चुनें
2026 में डिफ़ॉल्ट उत्तर Ed25519 है, और यही वह डिफ़ॉल्ट है जो यह साइट बनाती है। Ed25519 एक 256-बिट अंडाकार-वक्र कुंजी है: यह एक सेकंड के एक अंश में बनती है, तेज़ी से हस्ताक्षर करती है, और एक सार्वजनिक कुंजी देती है जो एक छोटी-सी पंक्ति में समा जाती है। यह 2014 से OpenSSH और हर आधुनिक सर्वर और क्लाइंट द्वारा समर्थित है, और इसकी सुरक्षा एक ऐसे वक्र पर टिकी है जिसे खुले में डिज़ाइन किया गया है, बिना किसी संदिग्ध स्थिरांक के। नई कुंजी के लिए कुछ और चुनने का कोई व्यावहारिक कारण नहीं है, जब तक कि आपके वातावरण में कुछ आपको मजबूर न करे। यदि आप इस लेख से एक ही सिफ़ारिश ले जाएँ, तो वह यही हो: Ed25519 बनाएँ, पासफ़्रेज़ सेट करें, और आगे बढ़ें।
अन्य प्रकार अपवादों के लिए मौजूद हैं। NIST P-256 या P-384 वक्रों पर ECDSA वहाँ सही विकल्प है जहाँ नीति NIST वक्र माँगती है — कुछ विनियमित वातावरण और पुराने हार्डवेयर टोकन उन्हें निर्दिष्ट करते हैं — और यह एक अच्छा विकल्प है यदि कोई ब्राउज़र या डिवाइस Ed25519 नहीं बना सकता। RSA सार्वभौमिक विकल्प बना हुआ है: RSA 2048 उपयोग करने लायक न्यूनतम है, RSA 3072 या 4096 वह विकल्प है जब दूसरा पक्ष अंडाकार वक्र बिल्कुल भी उपयोग नहीं कर सकता, जिसका आज मुख्य रूप से अर्थ है बहुत पुरानी प्रणालियाँ और कुछ एम्बेडेड डिवाइस। RSA 2048 से नीचे की कोई भी चीज़ — RSA 1024, DSA, ssh-dss — पुरानी है और इसे हटा देना चाहिए: SSH Key Suite इसे ठीक इसी कारण से कमज़ोर चिह्नित करता है। हालाँकि कुंजी का आकार पूरी कहानी नहीं है: उस लैपटॉप पर कॉपी की गई 4096-बिट RSA कुंजी जो अब आपके पास नहीं है, ठीक से रखी गई 256-बिट Ed25519 कुंजी से भी बदतर है, क्योंकि SSH कुंजियों की विफलता का तरीका लगभग कभी गणित नहीं होता। वह फ़ाइल होती है।
फ़िंगरप्रिंट और पहला कनेक्शन
जब आप पहली बार किसी सर्वर से जुड़ते हैं, तो SSH आपको कुछ ऐसा दिखाता है जो वर्णों की एक यादृच्छिक स्ट्रिंग जैसा लगता है और पूछता है कि क्या आप उस पर भरोसा करते हैं: 256 SHA256:M8zvXkwyrGfPUmaHSSdA1aFQkH8AVSRycOxaZHru7dQ। यह स्ट्रिंग सर्वर की होस्ट कुंजी का फ़िंगरप्रिंट है — सर्वर की सार्वजनिक कुंजी का हैश — और यह आपके और बीच वाले के बीच एकमात्र चीज़ है। यदि फ़िंगरप्रिंट आपके व्यवस्थापक द्वारा प्रकाशित मान से मेल खाता है, या उससे जिसे आपने किसी अलग चैनल से सत्यापित किया है, तो जवाब देने वाली मशीन वास्तव में वही सर्वर है जिस तक आप पहुँचना चाहते थे। यदि यह मेल नहीं खाता, तो रुकें: कोई कनेक्शन को रोक रहा हो सकता है, या सर्वर नई कुंजी के साथ फिर से बनाया गया हो सकता है, और किसी भी तरह से सुरक्षित कदम yes टाइप करने से पहले जाँच करना है। यह संकेत SSH का अपना सबसे महत्वपूर्ण काम कर रहा है, और जो लोग मुसीबत में पड़ते हैं वे वे हैं जिन्होंने बिना पढ़े yes टाइप करने का अभ्यास कर लिया है।
आप ssh-keygen -lf से जुड़ने से पहले ही फ़िंगरप्रिंट सत्यापित कर सकते हैं, जो प्रति कुंजी एक पंक्ति छापता है: बिट आकार, फ़िंगरप्रिंट, टिप्पणी, और कोष्ठकों में कुंजी का प्रकार, उदाहरण के लिए 256 SHA256:… [email protected] (ED25519)। SSH Key Suite फ़िंगरप्रिंट ठीक इसी प्रारूप में छापता है, ताकि ब्राउज़र में दिखने वाले मान की सर्वर द्वारा दिखाए गए मान से अक्षर-दर-अक्षर तुलना की जा सके। एक बार जब आप होस्ट कुंजी स्वीकार कर लेते हैं, तो SSH उसे ~/.ssh/known_hosts में सहेजता है और यदि यह कभी बदलती है तो ज़ोर से चेतावनी देता है — कनेक्ट करने से इनकार करते हुए। यह चेतावनी कोई परेशानी नहीं है जिसे किसी फ़्लैग से टाला जाए; यह बजता हुआ अलार्म है। एकमात्र नियमित अपवाद वह सर्वर है जिसे वैध रूप से फिर से बनाया गया है, जिस स्थिति में व्यवस्थापक को नया फ़िंगरप्रिंट पहले से प्रकाशित करना चाहिए था, और आप फिर से कनेक्ट करने से पहले ssh-keygen -R hostname से पुरानी प्रविष्टि हटा देते हैं।
authorized_keys की सफ़ाई और known_hosts
सर्वर की authorized_keys फ़ाइल की हर पंक्ति एक दरवाज़ा है, और दरवाज़े उस व्यक्ति के जाने के लंबे समय बाद भी खुले रहते हैं जिसे उनकी ज़रूरत थी। किसी ठेकेदार का लैपटॉप, कोई निरंतर-एकीकरण जॉब, किसी ऐसी मशीन पर बनाई गई कुंजी जिसे तब से मिटा दिया गया है, कोई सहकर्मी जो दो साल पहले टीम बदल चुका है — हर एक ऐसी पंक्ति है जो अब भी काम करती है, और हर एक ऐसा क्रेडेंशियल है जिसे आप अब नहीं देख रहे हैं। ऑडिट सरल है और हर कुछ महीनों में करने लायक है: फ़ाइल कॉपी करें, उसे SSH Key Suite के «जाँचें» टैब में पेस्ट करें, और देखें कि क्या वापस आता है। दोहराव — वही सार्वजनिक कुंजी दो बार — का अर्थ है कि किसी ने जाँचने के बजाय कुंजी फिर से पेस्ट कर दी, और उसे एक पंक्ति में समेट देना चाहिए। कमज़ोर प्रविष्टियाँ — 2048 से कम RSA, DSA, ssh-dss — हटा देनी चाहिए और बदल देनी चाहिए। और कोई भी पंक्ति जिसकी टिप्पणी में किसी ऐसे व्यक्ति, मशीन या उद्देश्य का नाम है जिसे आप अब पहचानते नहीं हैं, उसे तब तक बंद करने वाला दरवाज़ा मानना चाहिए जब तक उसका मालिक उसे अपना न बताए।
known_hosts दूसरी तरफ़ से उसी ध्यान का हक़दार है। यह हर उस सर्वर की होस्ट कुंजी दर्ज करता है जिससे आप जुड़े हैं, और SSH हर नए कनेक्शन की उससे जाँच करता है। कुछ प्रविष्टियाँ हैश की गई हैं — |1| के बाद base64 — जो होस्टनाम छिपाती हैं, यह उन लैपटॉपों के लिए एक गोपनीयता सुविधा है जो खो सकते हैं या जिनकी जाँच हो सकती है; SSH Key Suite उन प्रविष्टियों को हैश किया हुआ बताता है, यह दिखावा करने के बजाय कि वे पढ़ने योग्य हैं, क्योंकि हैश की गई प्रविष्टि को प्रकाशित फ़िंगरप्रिंट से सत्यापित नहीं किया जा सकता, केवल पहले से स्वीकृत के रूप में भरोसा किया जा सकता है। फ़ाइल स्वयं भी सबूत है: उन सर्वरों से भरा known_hosts जिनका आप अब उपयोग नहीं करते, वह मानचित्र है जहाँ आपके क्रेडेंशियल गए हैं, और उसे छाँटने में कुछ नहीं लगता। साथ में, दोनों फ़ाइलें दोनों दिशाओं में आपके SSH भरोसे का पूरा रिकॉर्ड हैं — कौन आपकी तरह लॉग इन कर सकता है, और किन मशीनों पर आप भरोसा करते हैं कि वे स्वयं हैं — और अगर कोई नहीं देखता तो दोनों चुपचाप सड़ जाती हैं।
जब कुंजी लीक हो जाए — और पासफ़्रेज़ पर टिप्पणी
लीक हुई कुंजी पहले जाँचने और बाद में कार्रवाई करने का रहस्य नहीं है; यह बदलने वाली कुंजी है, और कार्रवाई का क्रम छोटा है। एक नई कुंजी जोड़ी बनाएँ। हर सर्वर और हर सेवा की authorized_keys से पुरानी सार्वजनिक कुंजी हटा दें — आपके सर्वर, आपका Git होस्टिंग, आपकी डिप्लॉयमेंट पाइपलाइन, जहाँ भी कुंजी लगाई गई थी। फिर जाँचें कि पुरानी कुंजी किस तक पहुँच सकती थी और कुछ भी जगह से बाहर तो नहीं है: authorized_keys में नई पंक्तियाँ जो आपने नहीं जोड़ीं, उन घंटों में लॉगिन जब आप काम नहीं कर रहे थे, अपरिचित प्रक्रियाएँ। यदि आपको कुछ मिलता है, तो इसे डर नहीं, सेंध मानें, और वहाँ से जाँच करें। जो आपको नहीं करना है वह यह है कि पुरानी निजी कुंजी को अपने लैपटॉप से हटा दें और काम पूरा मान लें: अपनी प्रति हटाने से लीक हुई प्रतियों पर कोई असर नहीं होता, और authorized_keys में अब भी बैठी सार्वजनिक कुंजी अब भी काम करने वाला दरवाज़ा है।
पासफ़्रेज़ इस चेकलिस्ट को नहीं बदलता, लेकिन यह बदलता है कि आप इसे कितनी तत्परता से चलाते हैं। फ़ाइल के रूप में लीक हुई पासफ़्रेज़-संरक्षित कुंजी अब भी एक समस्या है — हमलावर ऑफ़लाइन, मशीन की गति से पासफ़्रेज़ का अनुमान लगाने की कोशिश कर सकता है — लेकिन एक मज़बूत पासफ़्रेज़ आपको अनुमान सफल होने से पहले रोटेट करने का समय देता है। अनएन्क्रिप्टेड कुंजी कोई समय नहीं देती, और इसीलिए यह साइट अपने जनरेटर के बारे में स्पष्ट है: संस्करण 1 अनएन्क्रिप्टेड कुंजियाँ बनाता है, बिना पासफ़्रेज़ विकल्प के, क्योंकि एन्क्रिप्टेड निजी कुंजियों के लिए OpenSSH का bcrypt KDF संस्करण 2 के दायरे में है। यदि आप यहाँ कुंजी बनाते हैं, तो chmod 600 से फ़ाइल सुरक्षित करें और अपनी मशीन पर ssh-keygen -p से पासफ़्रेज़ जोड़ें — इसमें दस सेकंड लगते हैं, यह फ़ाइल को उसी जगह बदल देता है, और यह इस पूरे लेख की सबसे मूल्यवान आदत है। कुंजी बनाएँ, पासफ़्रेज़ सेट करें, केवल सार्वजनिक आधा हिस्सा लगाएँ, साल में दो बार फ़ाइलों का ऑडिट करें, और भरोसा करने से पहले हर फ़िंगरप्रिंट सत्यापित करें: यही पूरी अनुशासन है, और यह एक इंडेक्स कार्ड पर समा जाती है।