सिक्योरिटी

    एक्सपायर होने वाले लिंक से SSH क्रेडेंशियल सुरक्षित तरीके से कैसे शेयर करें

    प्राप्तकर्ता की पब्लिक key को प्राथमिकता दें। प्राइवेट key या पासवर्ड भेजना ही हो, तो एक्सपायर होने वाले वन-टाइम लिंक से भेजें, होस्ट और यूज़रनेम अलग से।

    LinkPilot Team · TetraCore, LLC में LinkPilot को बनाने और चलाने वाले लोग · LinkPilot के बारे में

    आज रात किसी को सर्वर पर पहुंचना है, और क्रेडेंशियल उन तक अभी पहुंचना चाहिए। मन करता है कि प्राइवेट 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 या प्लेटफ़ॉर्म का वैसा ही विकल्प सेट करें, ताकि प्राप्तकर्ता को पहले लॉगिन पर उसे बदलना पड़े, और एक तय तारीख पर अकाउंट बंद करने की योजना बनाएं।
    • अंत की तारीख लिख लें, कुछ भी भेजने से पहले। “जब काम हो जाएगा” कोई तारीख नहीं है।
    1. प्राप्तकर्ता की पुष्टि करें, ऐसे चैनल से जिस पर आप पहले से भरोसा करते हैं: टिकट, कोई जाना-पहचाना ईमेल थ्रेड, या कॉल। गलत व्यक्ति तक पहुंचे क्रेडेंशियल के ज़्यादातर मामलों की वजह मिलता-जुलता एड्रेस या अपने आप भरा गया नाम होता है।
    2. सिर्फ़ सीक्रेट पेस्ट करें, वन-टाइम सीक्रेट लिंक टूल में। प्राइवेट key के लिए इसका मतलब है पूरा PEM ब्लॉक और कुछ नहीं। LinkPilot में टेक्स्ट स्टोर होने से पहले आपके ब्राउज़र में ही एन्क्रिप्ट होता है, इसलिए सर्विस के पास हमेशा सिर्फ़ एन्क्रिप्ट किया हुआ डेटा रहता है, और उसे डिक्रिप्ट करने की कुंजी URL के उस हिस्से में रहती है जिसे ब्राउज़र सर्वर को नहीं भेजते।
    3. एक्सपायरी असली समय के हिसाब से रखें। अगर वे इंतज़ार कर रहे हैं तो एक घंटा, किसी दूसरे टाइम ज़ोन में हैं तो 24 घंटे, और सात दिन सिर्फ़ तब जब कोई असली वजह हो। लिंक पहली बार खुलते ही मिट भी जाता है, इसलिए एक्सपायरी आखिरी बचाव है, मुख्य कंट्रोल नहीं।
    4. Pro अकाउंट पर पासफ़्रेज़ जोड़ें, जब क्रेडेंशियल संवेदनशील हो, और पासफ़्रेज़ किसी दूसरे चैनल से भेजें। Pro की ऑडिट टाइमलाइन यह भी दिखाती है कि सीक्रेट कब खोला गया।
    5. लिंक के साथ एक लाइन में मकसद लिखकर भेजें, कनेक्शन की कोई जानकारी नहीं।
    6. कनेक्शन की जानकारी अलग मैसेज में भेजें: होस्ट या एड्रेस, पोर्ट, यूज़रनेम, और लॉगिन का तरीका। इनमें से कोई भी अकेले सीक्रेट नहीं है, लेकिन 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
    

    उनसे कहें कि सीक्रेट लिंक तभी खोलें जब वे उसे इस्तेमाल करने के लिए तैयार हों, अपने कंट्रोल वाले डिवाइस पर और भरोसेमंद कनेक्शन पर। किसी साझा मशीन पर “बस देखने के लिए कि काम करता है” लिंक खोलने से उस मशीन की क्लिपबोर्ड हिस्ट्री में एक कॉपी रह जाती है।

    जांचें, फिर ऐक्सेस बंद करें

    जब तक ऐक्सेस की समय-सीमा खत्म नहीं हुई है, प्राप्तकर्ता से ठीक वही कनेक्शन टेस्ट करवाएं और पुष्टि करवाएं कि काम चल रहा है। टेस्ट पास करवाने के लिए परमिशन न बढ़ाएं; इसके बजाय दायरा ठीक करें।

    काम खत्म होने पर:

    1. पब्लिक key हटाएं authorized_keys से, या अकाउंट बंद करें, या सर्टिफ़िकेट को तय समय पर एक्सपायर होने दें।
    2. जो कुछ भी क्रेडेंशियल के साथ भेजा गया था, उसे रोटेट करें, उस अस्थायी पासवर्ड समेत जिसे पहले लॉगिन पर बदला जाना था और नहीं बदला गया।
    3. auth.log देखें, या अपना SSH ऑडिट सोर्स, ऐसे कनेक्शन के लिए जो तय समय के बाहर या अनजान एड्रेस से हुए हों।
    4. लिख लें कि किसके पास क्या था, कब से कब तक। रिकॉर्ड बना रहता है; क्रेडेंशियल नहीं।

    लिंक की एक्सपायरी तय करती है कि सीक्रेट कितने समय तक निकाला जा सकता था। क्रेडेंशियल की एक्सपायरी तय करती है कि उसे कितने समय तक इस्तेमाल किया जा सकता है। आपको दोनों चाहिए, और लोग दूसरी वाली ही भूलते हैं।

    इस लेख के लिए टूल

    अक्सर पूछे जाने वाले सवाल

    LinkPilot ऐसा सीक्रेट लिंक भेजता है जो खुलने के बाद मिट जाता है।

    आपके ब्राउज़र में ही एन्क्रिप्ट होता है, एक बार दिखता है और फिर हमेशा के लिए मिट जाता है। अकाउंट बनाने की ज़रूरत नहीं।

    सीक्रेट लिंक बनाएं

    आगे पढ़ें

    सिक्योरिटी

    ईमेल के बिना लॉगिन की जानकारी सुरक्षित कैसे शेयर करें

    ईमेल के बिना पासवर्ड शेयर करने के चार तरीके, कौन-सा कब सही है, और एक बार खुलते ही मिट जाने वाला अस्थायी लिंक बनाने के स्टेप।

    सिक्योरिटी

    क्लाइंट को webhook साइनिंग सीक्रेट सुरक्षित कैसे भेजें

    ईमेल या टिकट में कॉपी छोड़े बिना webhook साइनिंग सीक्रेट सौंपें: प्राप्तकर्ता की पुष्टि करें, वन-टाइम लिंक भेजें, सही जगह रखें, लीक हो तो रोटेट करें।

    सिक्योरिटी

    कॉन्ट्रैक्टर को अस्थायी डेटाबेस लॉगिन सुरक्षित कैसे भेजें

    सीमित दायरे और एक्सपायरी वाला डेटाबेस यूज़र बनाएं, पासवर्ड ईमेल की जगह वन-टाइम लिंक से भेजें, कनेक्शन सीमित करें और समय पर अकाउंट बंद करें।