आज रात किसी को सर्वर पर पहुंचना है, और क्रेडेंशियल उन तक अभी पहुंचना चाहिए। मन करता है कि प्राइवेट key या root पासवर्ड Slack में पेस्ट कर दें। लेकिन key जिस भी मैसेज से होकर गुज़रती है, वह उसकी एक कॉपी रख लेता है। इसीलिए बेहतर रास्ता है एक्सपायर होने वाला वन-टाइम लिंक: सीक्रेट एक बार निकाला जाता है और फिर मिट जाता है।
फिर भी लिंक सिर्फ़ पहुंचाने का कदम है। उसे बनाने से पहले सही क्रेडेंशियल चुनें, उसका दायरा काम तक सीमित करें, और तय करें कि बाद में उसे कैसे हटाएंगे। यह गाइड इन सब पर बात करती है, और यह भी बताती है कि सर्वर ऐक्सेस की जानकारी शेयर करने वाले वन-टाइम लिंक में क्या डालें और क्या बाहर रखें।
आप असल में कौन-सा SSH क्रेडेंशियल शेयर कर रहे हैं?
SSH ऐक्सेस चार अलग चीज़ों पर टिका हो सकता है, और उन्हें शेयर करने के नियम बहुत अलग हैं।
| क्रेडेंशियल | यह क्या है | क्या इसे कभी भेजा जाना चाहिए? |
|---|---|---|
| पब्लिक key | वह आधा हिस्सा जो सर्वर स्टोर करता है | हां, बेझिझक। यह सीक्रेट नहीं है। |
| प्राइवेट key | वह आधा हिस्सा जो यूज़र के पास रहता है | सिर्फ़ तब, जब वह प्राप्तकर्ता के लिए बनाई गई हो, और सिर्फ़ एक बार |
| पासवर्ड | एक साझा स्ट्रिंग जिसे सर्वर जांचता है | एक बार, अस्थायी वैल्यू के रूप में जिसे आप बाद में बदल देंगे |
| SSH सर्टिफ़िकेट | आपके CA से साइन की गई key, जिसकी एक वैधता अवधि होती है | सर्टिफ़िकेट सीक्रेट नहीं है, उसके पीछे की key सीक्रेट है |
सबसे अच्छा हैंडओवर वह है जिसमें कुछ भी सीक्रेट नहीं भेजना पड़ता। अगर
प्राप्तकर्ता के पास पहले से SSH key पेयर है, तो उनसे उनकी पब्लिक key मांगें, उसे
सही अकाउंट की ~/.ssh/authorized_keys में जोड़ें, और उन्हें कनेक्ट करने को कहें।
बाद में वह एक लाइन हटाते ही उनका ऐक्सेस खत्म हो जाता है।
उनके लिए अलग key बनाएं, अगर उनके पास key नहीं है और वे खुद नहीं बना सकते। अपनी रोज़ की प्राइवेट key कभी न भेजें। प्राप्तकर्ता के लिए बनाई गई key का दायरा सीमित किया जा सकता है, उसे लॉग किया जा सकता है और बाकी किसी चीज़ को छुए बिना डिलीट किया जा सकता है।
बार-बार की ज़रूरत के लिए सर्टिफ़िकेट या मैनेज्ड ऐक्सेस चुनें। अगर उसी व्यक्ति को बार-बार ऐक्सेस चाहिए, तो बार-बार के वन-टाइम हैंडओवर गलत टूल हैं। छोटी वैधता वाला SSH सर्टिफ़िकेट, या Teleport या Tailscale SSH जैसा ऐक्सेस टूल, एक्सपायरी को क्रेडेंशियल के अंदर ही रखता है, उसे पहुंचाने के तरीके पर ऊपर से नहीं जोड़ता।
शेयर करने से पहले क्रेडेंशियल का दायरा सीमित करें
आप जो भी भेजें, उसे उतना ही छोटा रखें जितना काम इजाज़त दे:
- एक अकाउंट, एक होस्ट। key उस सर्विस अकाउंट में जोड़ें जिसके ज़िम्मे यह काम है, root में नहीं, और सिर्फ़ उसी मशीन पर जिससे काम जुड़ा है।
- key क्या कर सकती है, यह सीमित करें,
authorized_keysके विकल्पों से, जैसेfrom="203.0.113.5",no-port-forwarding, या जहां काम एक ही स्क्रिप्ट है वहांcommand=रैपर। - पासवर्ड की उम्र तय करें। अगर आप पासवर्ड शेयर कर रहे हैं, तो
passwd -eया प्लेटफ़ॉर्म का वैसा ही विकल्प सेट करें, ताकि प्राप्तकर्ता को पहले लॉगिन पर उसे बदलना पड़े, और एक तय तारीख पर अकाउंट बंद करने की योजना बनाएं। - अंत की तारीख लिख लें, कुछ भी भेजने से पहले। “जब काम हो जाएगा” कोई तारीख नहीं है।
एक्सपायर होने वाले लिंक से SSH क्रेडेंशियल कैसे शेयर करें
- प्राप्तकर्ता की पुष्टि करें, ऐसे चैनल से जिस पर आप पहले से भरोसा करते हैं: टिकट, कोई जाना-पहचाना ईमेल थ्रेड, या कॉल। गलत व्यक्ति तक पहुंचे क्रेडेंशियल के ज़्यादातर मामलों की वजह मिलता-जुलता एड्रेस या अपने आप भरा गया नाम होता है।
- सिर्फ़ सीक्रेट पेस्ट करें, वन-टाइम सीक्रेट लिंक टूल में। प्राइवेट key के लिए इसका मतलब है पूरा PEM ब्लॉक और कुछ नहीं। LinkPilot में टेक्स्ट स्टोर होने से पहले आपके ब्राउज़र में ही एन्क्रिप्ट होता है, इसलिए सर्विस के पास हमेशा सिर्फ़ एन्क्रिप्ट किया हुआ डेटा रहता है, और उसे डिक्रिप्ट करने की कुंजी URL के उस हिस्से में रहती है जिसे ब्राउज़र सर्वर को नहीं भेजते।
- एक्सपायरी असली समय के हिसाब से रखें। अगर वे इंतज़ार कर रहे हैं तो एक घंटा, किसी दूसरे टाइम ज़ोन में हैं तो 24 घंटे, और सात दिन सिर्फ़ तब जब कोई असली वजह हो। लिंक पहली बार खुलते ही मिट भी जाता है, इसलिए एक्सपायरी आखिरी बचाव है, मुख्य कंट्रोल नहीं।
- Pro अकाउंट पर पासफ़्रेज़ जोड़ें, जब क्रेडेंशियल संवेदनशील हो, और पासफ़्रेज़ किसी दूसरे चैनल से भेजें। Pro की ऑडिट टाइमलाइन यह भी दिखाती है कि सीक्रेट कब खोला गया।
- लिंक के साथ एक लाइन में मकसद लिखकर भेजें, कनेक्शन की कोई जानकारी नहीं।
- कनेक्शन की जानकारी अलग मैसेज में भेजें: होस्ट या एड्रेस, पोर्ट, यूज़रनेम, और लॉगिन का तरीका। इनमें से कोई भी अकेले सीक्रेट नहीं है, लेकिन key के साथ मिलकर यही पूरा लॉगिन है।
अगर लिंक बताता है कि वह पहले ही खुल चुका है और प्राप्तकर्ता कहता है कि उसने नहीं खोला, तो बहस न करें। क्रेडेंशियल को एक्सपोज़ हुआ मानें, key हटाएं या पासवर्ड बदलें, और नया क्रेडेंशियल बनाएं।
सर्वर ऐक्सेस की जानकारी शेयर करने के लिए वन-टाइम लिंक
सीक्रेट के अंदर क्या जाए, यह सवाल हर बार उठता है। एक अच्छा नियम यह है कि लिंक में वह चीज़ जाए जिसका हमलावर अंदाज़ा नहीं लगा सकता, और सामान्य मैसेज में वे चीज़ें जिनका अंदाज़ा लगाया जा सकता है।
वन-टाइम लिंक में:
- प्राइवेट key, या अस्थायी पासवर्ड
- key का पासफ़्रेज़, अगर key बनाते समय सेट किया गया था
- और कुछ नहीं
सामान्य मैसेज में, अलग से भेजें:
- होस्टनेम या IP एड्रेस और पोर्ट
- किस अकाउंट से लॉग इन करना है
- key इस्तेमाल करनी है या पासवर्ड
- होस्ट key का फ़िंगरप्रिंट, ताकि प्राप्तकर्ता पहले कनेक्शन पर सर्वर की पुष्टि कर सके
- एक छोटा नोट कि ऐक्सेस किसलिए है और कब खत्म होगा
स्क्रीनशॉट और टर्मिनल लॉग न लिंक में डालें, न मैसेज में। चालू सेशन के स्क्रीनशॉट में अक्सर टोकन, अंदरूनी एड्रेस और दूसरे यूज़रनेम आ जाते हैं, जिन्हें कभी कहीं जाना ही नहीं था।
प्राप्तकर्ता को key सुरक्षित तरीके से रखने में मदद करें
अगर key Downloads में ऐसी परमिशन के साथ पड़ी रह जाए जिससे सब उसे पढ़ सकें, तो सुरक्षित हैंडओवर भी बेकार है। कनेक्शन की जानकारी के साथ ये निर्देश भी भेजें:
# save the key, then lock it down
chmod 600 ~/.ssh/acme_deploy
ssh-add ~/.ssh/acme_deploy
# verify the host key fingerprint against the one you were sent
ssh -i ~/.ssh/acme_deploy deploy@203.0.113.5
उनसे कहें कि सीक्रेट लिंक तभी खोलें जब वे उसे इस्तेमाल करने के लिए तैयार हों, अपने कंट्रोल वाले डिवाइस पर और भरोसेमंद कनेक्शन पर। किसी साझा मशीन पर “बस देखने के लिए कि काम करता है” लिंक खोलने से उस मशीन की क्लिपबोर्ड हिस्ट्री में एक कॉपी रह जाती है।
जांचें, फिर ऐक्सेस बंद करें
जब तक ऐक्सेस की समय-सीमा खत्म नहीं हुई है, प्राप्तकर्ता से ठीक वही कनेक्शन टेस्ट करवाएं और पुष्टि करवाएं कि काम चल रहा है। टेस्ट पास करवाने के लिए परमिशन न बढ़ाएं; इसके बजाय दायरा ठीक करें।
काम खत्म होने पर:
- पब्लिक key हटाएं
authorized_keysसे, या अकाउंट बंद करें, या सर्टिफ़िकेट को तय समय पर एक्सपायर होने दें। - जो कुछ भी क्रेडेंशियल के साथ भेजा गया था, उसे रोटेट करें, उस अस्थायी पासवर्ड समेत जिसे पहले लॉगिन पर बदला जाना था और नहीं बदला गया।
auth.logदेखें, या अपना SSH ऑडिट सोर्स, ऐसे कनेक्शन के लिए जो तय समय के बाहर या अनजान एड्रेस से हुए हों।- लिख लें कि किसके पास क्या था, कब से कब तक। रिकॉर्ड बना रहता है; क्रेडेंशियल नहीं।
लिंक की एक्सपायरी तय करती है कि सीक्रेट कितने समय तक निकाला जा सकता था। क्रेडेंशियल की एक्सपायरी तय करती है कि उसे कितने समय तक इस्तेमाल किया जा सकता है। आपको दोनों चाहिए, और लोग दूसरी वाली ही भूलते हैं।
