क्या आपकी SSH होस्ट की रोटेशन तैयार है?

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

सुरक्षित रोटेशन में चार अलग काम होते हैं: भरोसेमंद माध्यम से पुराना और नया फिंगरप्रिंट प्रकाशित करना, दोनों की को इतनी देर उपलब्ध रखना कि क्लाइंट नई की सीख लें, तय समय में पुरानी की हटाना, और यह साबित करना कि क्लाइंट पुराने हो चुके पहचान चिह्न को अस्वीकार करते हैं। मैंने टीमों को सर्वर का काम सही करते हुए भी डेवलपरों को सबसे खराब आदत सिखाते देखा है: होस्ट सत्यापन को रुकावट मानना। संचालन का काम चेतावनी आने से पहले सुरक्षित रास्ते को सामान्य बनाना है।

होस्ट पहचान और उपयोगकर्ता प्रमाणीकरण अलग हैं

होस्ट की साबित करती है कि किस SSH सर्वर ने जवाब दिया; उपयोगकर्ता की साबित करती है कि लॉग इन करने की मांग कौन कर रहा है। एक को बदलने से दूसरी नहीं बदलती। यह फर्क साधारण लगता है, फिर भी घटना संबंधी निर्देश अक्सर authorized_keys, निजी SSH की, होस्ट सर्टिफिकेट और /etc/ssh/ssh_host_* फाइलों को एक अस्पष्ट निर्देश, "SSH की रोटेट करें", में मिला देते हैं।

RFC 4253 सर्वर प्रमाणीकरण को ट्रांसपोर्ट हैंडशेक में रखता है। सर्वर अपनी निजी होस्ट की से एक्सचेंज हैश पर हस्ताक्षर करता है और क्लाइंट सार्वजनिक की को known_hosts, होस्ट सर्टिफिकेट अथॉरिटी या प्रमाणित SSHFP रिकॉर्ड जैसे भरोसेमंद स्रोत से मिलाता है। पासवर्ड, उपयोगकर्ता सर्टिफिकेट और सार्वजनिक उपयोगकर्ता की बाद में आते हैं। अगर क्लाइंट सर्वर की जांच बंद कर दे, तो डेवलपर किसी नकली सर्वर को पूरी तरह वैध उपयोगकर्ता क्रेडेंशियल दे सकता है।

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

कुछ भी बनाने से पहले दायरा लिखें। लोगों द्वारा इस्तेमाल किया जाने वाला हर होस्टनाम और उपनाम, हर गैर मानक पोर्ट, स्क्रिप्ट में सीधे लिखा हर पता, बैस्टियन रास्ता, CI रनर, डिप्लॉयमेंट एजेंट और साझा GlobalKnownHostsFile दर्ज करें। [host]:port, host से अलग known-hosts नाम है, जबकि उपनाम असली गंतव्य छिपा सकते हैं। git.example.net को कवर करने वाला लेकिन git.internal को छोड़ देने वाला रोटेशन रुक रुक कर होने वाली समस्या जैसा लगेगा, भले दोनों नाम एक मशीन तक जाते हों।

इस समय दिए जा रहे हर होस्ट-की एल्गोरिदम की सूची भी बनाएं। एक सर्वर पर Ed25519, ECDSA और RSA होस्ट की एक साथ हो सकती हैं। OpenSSH क्लाइंट के साथ एल्गोरिदम तय करता है, इसलिए एक ही daemon से जुड़ने वाले दो डेवलपर अलग सार्वजनिक की पिन कर सकते हैं। सिर्फ अपने लैपटॉप पर दिखी की को बदलना सर्वर की पूरी पहचान तय नहीं करता। कॉन्फिगर किए गए HostKey और सत्यापित सार्वजनिक-की फाइलों को आधिकारिक सूची मानें, फिर देखें कि समर्थित क्लाइंट समूह वास्तव में क्या तय करते हैं।

सर्वर बदलने से पहले दोनों फिंगरप्रिंट प्रकाशित करें

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

भरोसेमंद प्रशासनिक मशीन पर सार्वजनिक-की फाइलों से फिंगरप्रिंट निकालें, प्रोडक्शन नेटवर्क से यह न पूछें कि वह अभी क्या दिखा रहा है। OpenSSH डिफॉल्ट रूप से SHA-256 फिंगरप्रिंट दिखाता है। कमांड और आउटपुट का रूप यह है:

$ ssh-keygen -lf ssh_host_ed25519_key.pub -E sha256
256 SHA256:<base64-fingerprint> host.example.net (ED25519)

सिर्फ छोटा डाइजेस्ट प्रकाशित न करें। हर पहचान के साथ होस्टनाम और पोर्ट, एल्गोरिदम, SHA-256 फिंगरप्रिंट, स्थिति (current, new या retired), पहली बार इस्तेमाल का समय, हटाने का समय और रिकॉर्ड मंजूर करने वाला व्यक्ति या सिस्टम लिखें। समय क्षेत्र साफ लिखें। उपनाम एक की साझा करते हों तो उन्हें सूची में रखें। एक नाम के पीछे अलग नोड जानबूझकर अलग की दिखाते हों तो पूरा स्वीकृत सेट प्रकाशित करें और कारण बताएं।

एक उपयोगी प्रकाशन रिकॉर्ड ऐसा दिखता है:

Host: build.example.net:22
Algorithm: ssh-ed25519
Current: SHA256:<old-fingerprint>
New: SHA256:<new-fingerprint>
Overlap begins: 2026-08-10 15:00 UTC
Old key removed: 2026-08-17 15:00 UTC
Old key marked revoked: 2026-08-17 15:30 UTC
Owner: Platform operations

तारीखें उदाहरण हैं, क्रम नहीं। सर्वर बदलने के बाद प्रकाशित करना नियोजित काम को अचानक लिए जाने वाले भरोसे के फैसले में बदल देता है। सिर्फ नया मान प्रकाशित करने से डेवलपर अपने मौजूदा पिन से तुलना नहीं कर पाते। बदलाव के बाद पुराने रिकॉर्ड को retired स्थिति में दिखाते रहें, ताकि जांचकर्ता पुरानी मशीन और अनचाहे दोबारा इस्तेमाल को पहचान सकें।

फिंगरप्रिंट सार्वजनिक पहचान हैं, रहस्य नहीं। निजी होस्ट की सर्वर पर सुरक्षित रहती है, पर सार्वजनिक की और फिंगरप्रिंट इतने व्यापक रूप से बांटे जाने चाहिए कि बदलाव के दौरान किसी एक उपलब्ध प्रशासक को ढूंढना जरूरी न हो। प्रकाशन की मंजूरी को सुरक्षा बदलाव मानें: एक जैसे फिंगरप्रिंट देने वाली दो स्रोत फाइलें चैट में चिपकाए स्क्रीनशॉट से बेहतर प्रमाण हैं।

ओवरलैप से क्लाइंट नई की सुरक्षित रूप से सीखते हैं

पुरानी की हटाने से पहले पुरानी और नई होस्ट की साथ उपलब्ध रखें। इस ओवरलैप में स्थापित क्लाइंट पुरानी भरोसेमंद की से सर्वर को प्रमाणित करता है और फिर OpenSSH के [email protected] एक्सटेंशन से अतिरिक्त की सीख सकता है। निरंतर भरोसा पुरानी की देती है, इसलिए नई की कोई अप्रमाणित दावा नहीं बनती।

OpenSSH की ssh_config मैनुअल UpdateHostKeys को खास तौर पर आसान रोटेशन का तरीका बताती है। वह वास्तविक सिस्टम में जरूरी सीमाएं भी बताती है। क्लाइंट अतिरिक्त की तभी लेता है जब पहले से भरोसेमंद या उपयोगकर्ता द्वारा साफ तौर पर स्वीकार की गई साधारण की से प्रमाणीकरण हुआ हो और उपयोगकर्ता की known-hosts फाइल इस्तेमाल हुई हो। होस्ट सर्टिफिकेट या सिर्फ ग्लोबल known-hosts फाइल से प्रमाणीकरण होने पर यह रास्ता नई की नहीं सिखाता। उपयोगकर्ता UserKnownHostsFile बदल दे या VerifyHostKeyDNS चालू करे तो डिफॉल्ट भी बंद हो सकता है।

डिफॉल्ट मानकर न चलें। प्रतिनिधि होस्ट के लिए प्रभावी क्लाइंट कॉन्फिगरेशन देखें:

$ ssh -G build.example.net | grep -E '^(updatehostkeys|userknownhostsfile|stricthostkeychecking) '
stricthostkeychecking ask
updatehostkeys true
userknownhostsfile ~/.ssh/known_hosts ~/.ssh/known_hosts2

सर्वर पर निजी फाइलें अलग रखें और दोनों घोषित करें। यहां फाइल नाम उदाहरण हैं; अपने ऑपरेटिंग सिस्टम और कॉन्फिगरेशन प्रबंधन से मेल खाने वाले पथ इस्तेमाल करें:

HostKey /etc/ssh/ssh_host_ed25519_key_old
HostKey /etc/ssh/ssh_host_ed25519_key_new

रीलोड से पहले sshd -t चलाएं। sshd मैनुअल के अनुसार यह मोड कॉन्फिगरेशन की वैधता और की की स्थिति दोनों जांचता है, इसलिए daemon के दोबारा पढ़ने से पहले खराब सेटिंग या न पढ़ी जा सकने वाली फाइल मिल जाती है। सेवा प्रबंधक कुछ और न कहे तो सक्रिय सेशन बंद करने के बजाय रीलोड करें। फिर ऐसे साफ टेस्ट क्लाइंट से जुड़ें जो सिर्फ पुरानी की पर भरोसा करता है और सफल प्रमाणित सेशन के बाद उसकी अलग known-hosts फाइल देखें।

कई की कॉन्फिगर करने से हर क्लाइंट का एक ही की चुनना तय नहीं होता। एल्गोरिदम पसंद, क्लाइंट की उम्र, बदला हुआ HostKeyAlgorithms, सर्टिफिकेट और ग्लोबल ट्रस्ट स्टोर परिणाम बदलते हैं। हर प्रबंधित क्लाइंट वर्ग को कम से कम एक सामान्य कनेक्शन चक्र दें, कोई मनमाना घंटों का समय नहीं। हर सप्ताह जुड़ने वाले लैपटॉप और हर कुछ मिनट में जुड़ने वाले CI वर्कर को अलग अवधि चाहिए।

यह दिखावा न करें कि हर निजी known_hosts देखे बिना अपनाने का सटीक माप मिल जाएगा। प्रबंधित क्लाइंट बता सकते हैं कि वितरित ट्रस्ट फाइल में नई सार्वजनिक की है या नहीं। गैर प्रबंधित क्लाइंट के लिए गोपनीयता नीति की अनुमति पर क्लाइंट संस्करण के अनुसार सफल कनेक्शन देखें, स्पष्ट सत्यापन कमांड प्रकाशित करें और सामान्य उपयोग के लिए पर्याप्त ओवरलैप रखें। चुप्पी नई की फैलने का प्रमाण नहीं है।

बदलाव समय में स्थितियां और रोकने की शर्तें चाहिए

बदलाव अवधि में देखी जा सकने वाली स्थितियां, मालिक और वापसी की शर्तें होनी चाहिए। "दोपहर 3 बजे रोटेट करें" योजना नहीं है, क्योंकि वह ओवरलैप, क्लाइंट तैयारी या पुरानी पहचान कब अस्वीकार्य होगी, कुछ नहीं बताता। भरोसे का बदलाव और सर्वर डिप्लॉयमेंट एक ही समयरेखा पर रखें।

पांच पड़ाव रखें:

1. प्रकाशन पूरा: स्वतंत्र समीक्षक मंजूर सार्वजनिक-की फाइलों से हर पुराना और नया फिंगरप्रिंट दोबारा निकालते हैं।
2. ओवरलैप चालू: सर्वर दोनों पहचान देता है, कॉन्फिगरेशन sshd -t पास करता है और साफ क्लाइंट पुराना पिन इस्तेमाल करके प्रमाणित होने के साथ नई की सीखते हैं।
3. तैयारी पूरी: प्रबंधित ट्रस्ट स्टोर में नई की है, टेस्ट क्लाइंट समर्थित ऑपरेटिंग सिस्टम और रास्तों को कवर करते हैं और सहायता टीम के पास सही अपेक्षित फिंगरप्रिंट हैं।
4. कटओवर पूरा: सर्वर पुरानी निजी की देना बंद करता है, नए सेशन सख्त जांच के साथ चलते हैं और निगरानी में कोई अनपेक्षित नोड पुरानी की नहीं देता।
5. रिवोकेशन साबित: पुरानी पहचान देने वाला टेस्ट एंडपॉइंट अस्वीकार होता है और retired फिंगरप्रिंट रद्द स्थिति में प्रकाशित रहता है।

एक व्यक्ति को कटओवर रोकने का अधिकार दें। कोई प्रोडक्शन नोड अप्रकाशित की दिखाए, कोई रास्ता सूची से बाहर नोड पर जाए, समर्थित क्लाइंट नई की सीख या पा न सके, या वापसी में ऐसी निजी की चाहिए जिसे घटना टीम लीक मानती है, तो रुकें। सामान्य जीवनचक्र रोटेशन में ओवरलैप के दौरान पुरानी की पर वापस जा सकते हैं। चोरी हुई की को घटना के समय सुरक्षित वापसी विकल्प नहीं मान सकते।

सेवा वापसी और भरोसा वापसी अलग रखें। आप पुराने सर्वर पैकेज पर लौट सकते हैं और फिर भी retired पहचान को वापस न लाएं। सही कॉन्फिगरेशन, नई निजी की तक पहुंच और कंसोल या प्रदाता की पहुंच उपलब्ध रखें, ताकि टीम सत्यापन कमजोर किए बिना SSH ठीक कर सके। अगर SSH ठीक करने का इकलौता रास्ता SSH है, तो छिपा हुआ एकल विफलता बिंदु मौजूद है।

अवधि में लंबे समय तक चलने वाले मल्टीप्लेक्स सेशन शामिल करें। OpenSSH कनेक्शन शेयरिंग मास्टर कनेक्शन चालू रख सकती है और नए shell पुराने ट्रांसपोर्ट को दोबारा इस्तेमाल करते हैं। वे नया होस्ट-की एक्सचेंज नहीं करते, इसलिए कटओवर के बाद की पहचान साबित नहीं करते। जहां लागू हो, ssh -O exit host से टेस्ट कंट्रोल मास्टर बंद करें और जांचें कि सत्यापन प्रोब नया TCP कनेक्शन बनाते हैं।

retirement का ठीक समय तय करें और उसके बाद भी संवाद खुला रखें। छुट्टी से लौटे डेवलपर के पास पुराना पिन होगा। अपेक्षित नतीजा दस्तावेज वाला विफल कनेक्शन और सत्यापित अपडेट रास्ता है, अपवाद नहीं। सहायता टीम पहले फिंगरप्रिंट मिलाए, ssh-keygen -F से पुरानी एंट्री पहचाने और मंजूर रिकॉर्ड से बदले।

अलग ट्रस्ट फाइल से चेतावनी का अभ्यास करें

किसी के असली ~/.ssh/known_hosts को छुए बिना रोटेशन जांचें। अलग फाइल हर स्थिति दोहराने योग्य बनाती है और पुराने लैपटॉप पर महीनों पहले सीखी की के कारण गलत सफलता रोकती है। ऐसा स्टेजिंग एंडपॉइंट इस्तेमाल करें जो प्रोडक्शन की क्रम दिखा सके, या समान कॉन्फिगरेशन सीमा के साथ अलग पोर्ट पर अस्थायी sshd चलाएं।

पहले मंजूर पुरानी सार्वजनिक की से known_hosts.test बनाएं। लाइन समीक्षा किए गए आर्टिफैक्ट से बनाएं, लाइव स्कैन से नहीं। फिर HostKeyAlias से प्रोडक्शन का तार्किक नाम पिन करके स्टेजिंग एंडपॉइंट से जुड़ें:

$ ssh -F /dev/null \
  -o HostKeyAlias=build.example.net \
  -o UserKnownHostsFile=./known_hosts.test \
  -o GlobalKnownHostsFile=/dev/null \
  -o StrictHostKeyChecking=yes \
  -o UpdateHostKeys=yes \
  -p 2222 test-host.example.net true

एंडपॉइंट दोनों की देता हो तो पहली बार सफल होना चाहिए। ssh-keygen -F build.example.net -f ./known_hosts.test से फाइल देखें और मंजूर नई की मौजूद होने की पुष्टि करें। लौटे हर सार्वजनिक-की फील्ड का फिंगरप्रिंट निकालकर प्रकाशन रिकॉर्ड से मिलाएं। शून्य निकास स्थिति सिर्फ कनेक्शन साबित करती है, पहचान सेट नहीं।

फिर टेस्ट एंडपॉइंट को सिर्फ नई की देने के लिए कॉन्फिगर करें और नया कनेक्शन बनाएं। प्रमाणित ओवरलैप से नई की सीखने के कारण कनेक्शन सफल होना चाहिए। सिर्फ पुराना पिन वाला स्नैपशॉट लौटाकर नए-ही एंडपॉइंट पर दोहराएं। StrictHostKeyChecking=yes के साथ यह विफल होना चाहिए। यह नकारात्मक केस साबित करता है कि ओवरलैप चूकने वाले गैर प्रबंधित क्लाइंट चुपचाप स्वीकार करने के बजाय रुकते हैं।

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

StrictHostKeyChecking=no को अभ्यास का समाधान कभी न बनाएं। मौजूदा OpenSSH मैनुअल कहती है कि यह सेटिंग कुछ सीमाओं के साथ बदली की पर आगे बढ़ती है, जबकि accept-new बदली की को अस्वीकार करता है। अकेला accept-new भी रोटेशन नहीं संभालता, क्योंकि पहले से ज्ञात नाम के लिए नई की बदली हुई की है। प्रमाणित ट्रस्ट सामग्री दें या ओवरलैप तरीका अपनाएं।

रिवोकेशन का नतीजा अस्वीकृति हो, सफाई का सुझाव नहीं

इच्छित सर्वर से पुरानी निजी की हटाने से सिर्फ यह साबित होता है कि वह सर्वर अब उसे नहीं दे रहा। रिवोकेशन का मतलब क्लाइंट उस सार्वजनिक की को फिर कहीं दिखने पर अस्वीकार करे, चाहे वह भूला हुआ नोड हो या चुराई निजी की वाला हमलावर एंडपॉइंट। known_hosts से पुरानी लाइन मिटाना उलटा है: वह retired पहचान पहचानने की याद मिटाता है।

OpenSSH known-hosts फाइल @revoked मार्कर स्वीकार करती हैं। ऐसी मिलती की कभी स्वीकार नहीं होती और मिलने पर चेतावनी देती है। प्रबंधित सिस्टम ग्लोबल revoked एंट्री बांट सकते हैं, जबकि छोटा वातावरण अलग रिवोकेशन फाइल या बनाई हुई ट्रस्ट बंडल रख सकता है। ठीक मंजूर पुरानी सार्वजनिक की इस्तेमाल करें और होस्टनाम पैटर्न सोचकर सीमित करें:

@revoked build.example.net ssh-ed25519 <old-public-key-data>

सेट बड़ा होने या होस्ट सर्टिफिकेट जुड़ने पर Key Revocation List उपयोगी है। पुरानी सार्वजनिक की से टेस्ट KRL बनाकर डिप्लॉयमेंट से पहले पूछें:

$ ssh-keygen -k -f revoked-hostkeys.krl ssh_host_ed25519_key_old.pub
$ ssh-keygen -Q -f revoked-hostkeys.krl ssh_host_ed25519_key_old.pub
ssh_host_ed25519_key_old.pub (<comment>): REVOKED

रद्द की के लिए क्वेरी गैर शून्य स्थिति देती है, इसलिए automation को इसे जानबूझकर समझना चाहिए, विफल टेस्ट नहीं मानना चाहिए। टेस्ट क्लाइंट का RevokedHostKeys KRL पर लगाएं, पुरानी पहचान वाले एंडपॉइंट से जुड़ें और अस्वीकृति जरूरी करें। फिर नई पहचान वाले एंडपॉइंट पर सफलता जरूरी करें। दोनों जरूरी हैं: खराब या न पढ़ी जा सकने वाली फाइल सिर्फ retired पहचान की जगह हर कनेक्शन रोक सकती है।

ssh-keygen -R host hashed उपयोगकर्ता फाइल संपादित करने के लिए उपयोगी है, पर रिवोकेशन नहीं। वह नाम की सभी एंट्री, सही नई की भी, हटा देता है और अगला कनेक्शन फिर भरोसे का फैसला बनता है। इसे stored एंट्री और प्रकाशित रिकॉर्ड मिलाने के बाद ही इस्तेमाल करें और फिर मंजूर नई की जोड़ें। -R के बाद अप्रमाणित ssh-keyscan चलाने वाली सहायता स्क्रिप्ट भरोसा छोड़ने को automation बना देती है।

रद्द सार्वजनिक सामग्री रखें। नीति के अनुसार सुरक्षित retired निजी की नष्ट की जा सकती है, लेकिन उसकी सार्वजनिक की, फिंगरप्रिंट, मंजूरी रिकॉर्ड और रिवोकेशन टेस्ट रखें। महीनों बाद पुरानी image लौटे तो इन्हीं से पहचान होगी।

Automation सुरक्षित रूप से रुके, पर कमजोर न हो

बिना उपयोगकर्ता वाले काम को जांच बंद करने के बजाय संभाला हुआ ट्रस्ट स्रोत चाहिए। CI रनर, डिप्लॉयमेंट एजेंट और स्वायत्त कोडिंग एजेंट अक्सर सबसे पहले रोटेशन देखते हैं, क्योंकि वे दिन भर छोटे कनेक्शन बनाते हैं। जब image में एक होस्ट की पक्की हो और नवीनीकरण का मालिक न हो, तो आम आपात patch StrictHostKeyChecking=no है। वह उपलब्धता गलती को प्रमाणीकरण विफलता बना देता है।

हर automation वर्ग के लिए ट्रस्ट पहुंचाने का मॉडल चुनें। ओवरलैप में image में दोनों मंजूर की डालें, केंद्रीय ग्लोबल known-hosts फाइल mount करें, KnownHostsCommand से मंजूर लाइन लौटाएं, DNSSEC के साथ सत्यापित SSHFP इस्तेमाल करें या होस्ट सर्टिफिकेट अथॉरिटी पर भरोसा करें। OpenSSH मैनुअल कहती है कि KnownHostsCommand सामान्य known-hosts रूप देता है और उपयोगकर्ता व ग्लोबल फाइलों के साथ चलता है। कमांड असामान्य रूप से बंद हो तो कनेक्शन रुकता है, जो सही डिफॉल्ट है, पर ट्रस्ट सेवा को job की उपलब्धता जरूरत पूरी करनी होगी।

Batch व्यवहार साफ रखें:

Host build.example.net
    BatchMode yes
    StrictHostKeyChecking yes
    UserKnownHostsFile /etc/company/ssh_known_hosts
    UpdateHostKeys no

इस प्रबंधित फाइल उदाहरण में UpdateHostKeys no जानबूझकर है। कॉन्फिगरेशन प्रबंधन फाइल का मालिक है, इसलिए हर अस्थायी worker को बदलने देना ऐसा state बनाता है जिसे न रख सकते हैं न audit कर सकते हैं। डेवलपर की अपनी user file में UpdateHostKeys yes बेहतर हो सकता है। वही निर्देश सही या गलत इस पर है कि ट्रस्ट वितरण किसका काम है।

उपनाम, jump host, सीधे IP और गैर मानक पोर्ट को अलग पहचान की तरह जांचें। ProxyJump रास्ता फिर भी गंतव्य होस्ट प्रमाणित करता है और jump host का अपना pin है। container read-only known-hosts file mount कर सकता है। sandbox agent अलग SSH binary चला सकता है या user config directory अनदेखी कर सकता है। वास्तविक execution environment में ssh -G target चलाकर प्रभावी सेटिंग देखें, workstation config से समानता न मानें।

Agent द्वारा चलाए SSH में credential और host trust अलग control रखें। Sallyport अपने शामिल sp-ssh helper से SSH action करता है और SSH की उसके encrypted vault में रहती हैं, इसलिए agent को secret नहीं मिलता। यह credential custody बचाता है; rotation plan को फिर भी प्रमाणित host identity source और जांचा rejection path चाहिए।

Window में automation विफल हो तो expected और observed fingerprint लिखे, private material नहीं। कमजोर setting के साथ अपने आप retry न करें। job रोकें, stderr और effective config बचाएं और mismatch को publication record के owner तक पहुंचाएं।

वही automation test ऐसे disposable worker से चलाएं जिसमें home directory का पुराना state न हो। उसे उत्पादन में इस्तेमाल होने वाला ठीक managed trust bundle दें, वास्तविक job command चलाएं और ssh -G output परिणाम के साथ archive करें। इससे rotation test का आसान झूठ पकड़ा जाता है: runner स्वस्थ इसलिए दिखता है क्योंकि पुराने interactive session ने writable file भर दी थी जिसे image specification ने कभी घोषित नहीं किया।

Server के new-only होने के बाद bundle की copy से नई key हटाकर failure path जांचें। job को remote command भेजने से पहले रुकना चाहिए और wrapper को SSH का exit status रखना चाहिए। फिर नई key बांटकर दोहराएं। deployment framework हर SSH error को सामान्य timeout बनाए तो window से पहले observability ठीक करें, क्योंकि responders को rejected identity, network loss और user authentication failure अलग करने होंगे।

Fleet config में जरूरत से अधिक trust बढ़ाने वाली चीज देखें। wildcard known-hosts line एक मंजूर key को कई नामों के लिए valid बना सकती है, जबकि shared host keys client के लिए अलग machines को एक जैसा बनाती हैं। दोनों design जानबूझकर हो सकते हैं, पर rotation record में scope लिखें। machines की पहचान अलग हो तो host-specific line चुनें और job द्वारा इस्तेमाल असली hostname string जांचें।

अंत में autonomous jobs के SSH binary और configuration contract को pin करें। Base-image update host identity बदलते समय defaults भी बदल सकता है, जिससे कारण अलग करना कठिन होगा। cutover से पहले और बाद client version, effective host-key algorithms, trust-file digest और logical hostname रखें। ये सार्वजनिक operational facts बताते हैं कि failed job ने गलत server देखा, नई key नहीं पाई या offered algorithm तय नहीं कर सका।

DNS और होस्ट सर्टिफिकेट वितरण का काम बदलते हैं

SSHFP और होस्ट सर्टिफिकेट हर होस्ट का pin संभालना घटा सकते हैं, पर ट्रस्ट रोटेशन की योजना नहीं हटाते। वे स्थिर भरोसे का आधार दूसरी जगह रखते हैं। इन्हें तब इस्तेमाल करें जब उस आधार को हजारों अलग known-hosts एंट्री से बेहतर चला सकें।

RFC 4255 SSHFP रिकॉर्ड तय करता है और फिंगरप्रिंट पर भरोसा करने से पहले प्रमाणित DNS data मांगता है। व्यवहार में DNSSEC validation client से record तक सही होनी चाहिए। सामान्य unsigned DNS record तुलना में मदद करता है, लेकिन DNS जवाब बदल सकने वाले attacker के सामने पहचान नहीं बनाता। OpenSSH का VerifyHostKeyDNS yes सिर्फ secure match पर अपने आप भरोसा करता है; insecure result को सामान्य confirmation चाहिए।

ओवरलैप में पुराने और नए SSHFP record प्रकाशित करें, DNS cache और managed resolver के देखने का इंतजार करें, फिर पुरानी private key हटने पर पुराना record हटाएं। मंजूर public file से ssh-keygen -r hostname -f public_key_file चलाकर record बनाएं। client जिस resolver path से चलता है उसी से served record और validation status देखें। कम TTL cache समय घटाता है, टूटा DNSSEC या गलत record ठीक नहीं करता।

Host certificate client को हर host key pin करने के बजाय @cert-authority *.example.net जैसी host CA entry पर भरोसा करने देते हैं। सही principal और validity वाली नई certified host key मिलने पर client उसे मौजूदा CA के तहत लेता है। बड़े बदलते fleet के लिए यह साफ है, लेकिन CA शक्तिशाली trust anchor बनता है। उसकी private key बचाएं, issuance सीमित करें, certificate serial और principal log करें और CA revocation अलग अभ्यास करें।

सिर्फ एक कठिन rotation हटाने के लिए host CA न लगाएं। इससे issuance, expiry, principal naming और CA rollover का काम आता है। छोटा स्थिर fleet साफ pins ठीक चला सकता है। बड़ा अस्थायी fleet certificate से लाभ लेता है क्योंकि instance identity संगठन के authority से जल्दी बदलती है।

मॉडल कोई भी हो, trust कहां शुरू होता है लिखें। Host certificate से authentication पर UpdateHostKeys लागू नहीं होता और global known-hosts file वाला client user-file mechanism से additions नहीं सीखता। प्राथमिकता लिखे बिना मॉडल मिलाने से laptop पर rotation चलता और CI में टूटता है।

Window के बाद बचने वाले सबूत के साथ रोटेशन बंद करें

पूरा rotation यह प्रमाण छोड़ता है कि क्या बदला, किसने मंजूर किया, client ने क्या स्वीकार किया और पुरानी identity अस्वीकार हुई या नहीं। बनी public keys, दोबारा निकले SHA-256 fingerprint, sshd -t result, effective server config, publication revision, client test matrix, cutover timestamps, revocation artifact और captured negative test रखें। ticket में private key न रखें।

Window के बाद server की असली स्थिति दर्ज करें। हर production route से हर node पूछकर approved set से तुलना करें, पर network collection observation है, अपना trust source नहीं। signed या अन्य प्रमाणित publication से मिलाएं। autoscaling image और बंद recovery node भी देखें; stale host keys अक्सर बदली capacity से लौटती हैं, उसी machine से नहीं जो window में बदली थी।

Sallyport की Activity journal और Sessions journal agent द्वारा किए SSH actions का tamper-evident record रख सकती हैं, जो encrypted hash-chained audit log से निकलता है। sp audit verify vault key के बिना ciphertext पर chain offline जांचता है, इसलिए change record में action evidence जोड़ सकता है, लेकिन यहां बताए host-key tests को नहीं बदलता।

Fleet व्यवहार के आधार पर follow-up तारीख रखें। retired fingerprint के कारण अभी विफल client, unexpected identity देने वाले node और घटना में bypass flag पाने वाली script खोजें। temporary overlap config और test endpoint हटाएं। जब तक retired private key backup, image या unauthorized copy में बच सकती है, revocation चालू रखें।

Host-key warning दुर्लभ और गंभीर रहनी चाहिए। अच्छा rotation उसे दबाता नहीं। वह trust transition इतनी जल्दी कर देता है कि expected client को चेतावनी अनदेखी न करनी पड़े, फिर साबित करता है कि retired identity लौटने पर warning अभी भी connection रोकती है।