क्या SSH होस्टनेम कैननिकलाइज़ेशन स्वीकृत लक्ष्य बदल सकता है?

ssh build लिखी हुई स्वीकृति उस मशीन को अधिकृत करे, यह ज़रूरी नहीं जो अंत में TCP कनेक्शन स्वीकार करती है। OpenSSH छोटे नाम को बढ़ा सकता है, अनुमत CNAME का अनुसरण कर सकता है, कॉन्फ़िगरेशन को दूसरी बार पढ़ सकता है, अलग उपयोगकर्ता या पोर्ट चुन सकता है और बने हुए नाम को कई पतों में से किसी एक पर रिज़ॉल्व कर सकता है। अगर कोई एजेंट गेटवे केवल एजेंट का दिया हुआ टेक्स्ट स्वीकृत करता है, तो स्वीकृति एक लक्ष्य का वर्णन कर सकती है जबकि SSH क्लाइंट किसी दूसरे लक्ष्य का उपयोग करे।

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

एक SSH कमांड में चार अलग पहचान होती हैं

SSH लक्ष्य केवल एक स्ट्रिंग नहीं है। उसे एक स्ट्रिंग मानने से ही यह गड़बड़ी पैदा होती है। सही स्वीकृति पथ चार पहचानों को अलग रखता है:

• माँगा गया नाम एजेंट का दिया तर्क है, जैसे build।
• प्रभावी होस्टनेम वह मान है जिसे OpenSSH Hostname प्रतिस्थापन और कैननिकलाइज़ेशन के बाद उपयोग करता है, जैसे build.ops.example।
• पीयर पता वह IP पता है जिसे क्लाइंट सॉकेट खोलते समय चुनता है।
• प्रमाणित पहचान वह होस्ट कुंजी या होस्ट प्रमाणपत्र है जिसे कनेक्शन के लिए स्वीकार किया गया।

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

OpenSSH खुद ssh_config में नामों का यह अंतर दिखाता है। %n कमांड लाइन पर दिया मूल दूरस्थ होस्टनेम है, जबकि %h कॉन्फ़िगरेशन का काम पूरा होने के बाद का दूरस्थ होस्टनेम है। %k एक और मान है: सेट होने पर HostKeyAlias, अन्यथा कमांड लाइन का मूल नाम। ये टोकन इसलिए हैं क्योंकि OpenSSH हर चरण के नाम को एक जैसा मानकर नहीं चल सकता।

इसी अंतर के कारण सफल होस्ट कुंजी जाँच अस्पष्ट प्राधिकरण निर्णय को ठीक नहीं कर सकती। प्रमाणीकरण साबित कर सकता है कि एंडपॉइंट के पास अपेक्षित कुंजी है। वह यह साबित नहीं कर सकता कि कार्ड पर केवल build दिखने पर व्यक्ति इसी एंडपॉइंट को अधिकृत करना चाहता था। प्राधिकरण पूछता है कि क्या यह कार्रवाई इस गंतव्य तक जा सकती है। प्रमाणीकरण पूछता है कि क्या जवाब देने वाला सर्वर पहचान रिकॉर्ड से मेल खाता है। दोनों जाँच जरूरी हैं और अलग समय पर होती हैं।

कैननिकलाइज़ेशन कनेक्शन से पहले नाम बदल सकता है

CanonicalizeHostname तय करता है कि OpenSSH स्पष्ट रूप से नाम बदलेगा या नहीं। इसका डिफ़ॉल्ट no है, जो नाम खोज सिस्टम रिज़ॉल्वर पर छोड़ देता है। yes होने पर OpenSSH सीधे कनेक्शन के लिए CanonicalDomains के सफ़िक्स आज़माता है। always होने पर ProxyCommand या ProxyJump के जरिए पहुँचे गंतव्य भी कैननिकलाइज़ होते हैं।

मान लें एजेंट यह कार्रवाई माँगता है:

host: build
user: deploy
command: /usr/local/bin/release status

क्लाइंट पर यह कॉन्फ़िगरेशन हो सकता है:

Host *
    CanonicalizeHostname yes
    CanonicalDomains ops.example
    CanonicalizeFallbackLocal no
    CanonicalizeMaxDots 1
    CanonicalizePermittedCNAMEs *.ops.example:*.hosts.example

OpenSSH पहले build.ops.example आज़माता है। अगर DNS अनुमत CNAME देकर build-07.hosts.example पर भेजता है, तो वही कैननिकल नाम बन सकता है। अनुरोध अब भी build कहता है, लेकिन क्लाइंट उस नाम से कनेक्ट नहीं करता। केवल अनुरोध दिखाने वाला स्वीकृति कार्ड महत्वपूर्ण बदलाव छिपा देता है।

सीमाओं पर ध्यान देना जरूरी है। CanonicalizeMaxDots का डिफ़ॉल्ट 1 है, इसलिए एक डॉट वाला नाम भी कैननिकलाइज़ेशन के योग्य है, केवल बिना डॉट का लेबल नहीं। CanonicalizeFallbackLocal का डिफ़ॉल्ट yes है; यदि कॉन्फ़िग किए कैननिकल डोमेन परिणाम न दें, तो OpenSSH मूल नाम सिस्टम रिज़ॉल्वर और उसके खोज नियमों को दे सकता है। इसे no रखने पर विफलता साफ दिखती है। स्वीकृति गेटवे के लिए स्पष्ट विफलता बेहतर है, क्योंकि स्थानीय खोज सूची नेटवर्क और समय के साथ बदल सकती है।

CNAME का अनुसरण अलग से सीमित होता है। CanonicalizePermittedCNAMEs का डिफ़ॉल्ट none है और इसके नियम अनुमत स्रोत पैटर्न को लक्ष्य पैटर्न से जोड़ते हैं। यह डिफ़ॉल्ट समझदार है। *:* जैसा व्यापक नियम DNS उपनाम को बिना सीमा वाला पुनर्लेखन बना देता है। संकरा नियम उस नेमस्पेस बदलाव को दर्ज करता है जिसकी सच में अपेक्षा है, जैसे ops.example के सेवा उपनाम से hosts.example के होस्ट तक।

OpenSSH मैनुअल इन नियंत्रणों को ठीक-ठीक बताता है, पर नीति परत केवल विकल्पों के मान कार्ड पर नहीं लिख सकती। उसे उसी क्लाइंट कॉन्फ़िगरेशन के साथ वही गणना चलानी होगी। स्वीकृति सेवा में सफ़िक्स खोज और CNAME नियम फिर से लिखने पर वे SSH क्लाइंट के संस्करण और स्थानीय कॉन्फ़िग बदलने के साथ अलग हो जाते हैं।

दूसरा कॉन्फ़िग पास DNS से अधिक बदल सकता है

कैननिकलाइज़ेशन चालू होने पर OpenSSH नए लक्ष्य नाम के साथ कॉन्फ़िगरेशन फिर पढ़ता है। दूसरा पास ऐसे Host और Match ब्लॉक सक्रिय कर सकता है जो मूल उपनाम से नहीं मिलते थे। इसलिए केवल DNS की पूर्व जाँच गंतव्य के दूसरे बदलाव छोड़ सकती है।

मान लें कैननिकल नाम इस ब्लॉक से मिलता है:

Match canonical host *.prod.ops.example
    User release
    Port 2222
    IdentityFile ~/.ssh/prod_release
    ProxyJump bastion.ops.example

deploy का अनुरोध पहले deploy.prod.ops.example बन सकता है, फिर अलग दूरस्थ उपयोगकर्ता, पोर्ट, पहचान फ़ाइल और जंप होस्ट चुन सकता है। OpenSSH अधिकतर निर्देशों के लिए पहले मिले मान का उपयोग करता है, इसलिए सेटिंग लागू होगी या नहीं, यह पहले के ब्लॉक और उनके क्रम पर निर्भर है। अकेले मिलते हुए ब्लॉक को पढ़कर अंतिम कॉन्फ़िग नहीं जाना जा सकता।

canonical शर्त केवल होस्टनेम कैननिकलाइज़ेशन के बाद दोबारा पढ़े जा रहे कॉन्फ़िग में मिलती है। final शर्त कैननिकलाइज़ेशन बंद होने पर भी अंतिम पास माँगती है। कैननिकलाइज़ेशन चालू हो तो canonical और final एक ही पास में मिलते हैं। host उस लक्ष्य से मिलता है जिसे Hostname या कैननिकलाइज़ेशन ने बदला है, जबकि originalhost कमांड लाइन के मान से मिलता है। इन बातों के कारण साधारण दिखने वाला कॉन्फ़िग भी स्थिति पर निर्भर है।

खतरनाक समीक्षा तरीका यह है कि host=deploy, user=agent, port=22 स्वीकृत कर दिया जाए, फिर ssh deploy सामान्य क्लाइंट को देकर मान लिया जाए कि फ़ील्ड नहीं बदलेंगे। अगर क्लाइंट कॉन्फ़िग अब भी User, Port, ProxyJump, RemoteCommand, फ़ॉरवर्डिंग या पहचान चयन बदल सकता है, तो स्वीकृति ने प्रस्ताव को कवर किया, चली हुई कार्रवाई को नहीं।

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

कॉन्फ़िगरेशन का स्रोत भी लक्ष्य का हिस्सा है

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

मनमाने SSH फ़्लैग जोड़ सकने वाला एजेंट सावधानी से रखे डिफ़ॉल्ट को पार कर सकता है। -F दूसरी कॉन्फ़िग फ़ाइल चुनता है, जबकि -o सीधे Hostname, ProxyCommand, ProxyJump, Port, User, HostKeyAlias या फ़ॉरवर्डिंग निर्देश सेट कर सकता है। गेटवे को SSH कार्रवाई को प्रकार वाले फ़ील्ड में पढ़कर असमर्थित विकल्प रोकने चाहिए, न कि अपारदर्शी कमांड स्ट्रिंग स्वीकार करनी चाहिए। कच्चे फ़्लैग जरूरी हों, तो गंतव्य को प्रभावित करने वाले हर फ़्लैग को वर्गीकृत करें और उसका सामान्यीकृत मान स्वीकृति में रखें।

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

Match exec केवल शर्त की स्ट्रिंग तुलना नहीं है: OpenSSH दी गई कमांड उपयोगकर्ता के shell में चलाता है और शून्य निकास स्थिति को मेल मानता है। Match localnetwork सक्रिय स्थानीय इंटरफ़ेस के पतों के अनुसार कॉन्फ़िग बदल सकता है। मैनुअल भी सावधान करता है कि DHCP से कॉन्फ़िग नेटवर्क सुरक्षा-संवेदनशील सेटिंग के लिए भरोसेमंद कसौटी नहीं है। उसी ssh build अनुरोध को VPN जुड़ने, स्क्रिप्ट की निकास स्थिति बदलने या शामिल फ़ाइल आने पर दूसरा प्रभावी लक्ष्य मिल सकता है।

स्वीकृति एक्ज़ीक्यूटर गणना से पहले बंद इनपुट सेट बनाए। निश्चित क्लाइंट बाइनरी, नियंत्रित कॉन्फ़िग मूल, साफ वातावरण, ज्ञात फ़ाइल स्वामित्व, स्पष्ट पता परिवार और उपयोगकर्ता तथा सिस्टम कॉन्फ़िग की घोषित नीति अपनाएँ। उस सेट का डाइजेस्ट निकालकर निष्पादन टिकट में रखें। डाइजेस्ट कार्ड पर प्रमुख होने की जरूरत नहीं, लेकिन ऑडिट रिकॉर्ड में होना और उपयोग के समय फिर जाँचा जाना चाहिए।

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

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

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

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

कार्ड दिखने के बाद DNS उत्तर बदल सकता है

प्रभावी होस्टनेम स्थिर रहे, तब भी स्वीकृति और कनेक्शन के बीच उसका पता बदल सकता है। DNS रोटेशन, अलग नेटवर्क दृश्य, VPN बदलाव, रिज़ॉल्वर खोज पथ और सामान्य रिकॉर्ड अपडेट अलग उत्तर दे सकते हैं। स्वीकृति सेवा नाम रिज़ॉल्व करके पता दिखाए और SSH प्रक्रिया बाद में फिर रिज़ॉल्व करे, तो जाँच और उपयोग के समय में अंतर बनता है।

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

कई A या AAAA रिकॉर्ड के लिए साफ नियम चाहिए। पतों का सेट दिखाकर क्लाइंट को कोई सदस्य आज़माने देना ठीक हो सकता है, पर स्वीकृति में कहना होगा कि दिखा हुआ सेट कवर है और ऑडिट लॉग में सफल सदस्य दर्ज होना चाहिए। सेट बदले तो पुरानी स्वीकृति नए पते तक न फैले। अधिक जोखिम वाले होस्ट के लिए एक चुना पता स्वीकृत करना समझने में आसान है।

प्रॉक्सी बदलता है कि स्थानीय DNS रिज़ॉल्यूशन कहाँ होता है। ProxyJump में क्लाइंट आम तौर पर जंप कनेक्शन से अंतिम होस्ट और पोर्ट तक ट्रैफ़िक पहुँचाने को कहता है। ProxyCommand लगभग कोई भी ट्रांसपोर्ट व्यवहार कर सकता है। स्थानीय रूप से दिखता पीयर पता प्रॉक्सी का हो सकता है, जबकि अंतिम नाम कहीं और रिज़ॉल्व हो। स्वीकृति में दोनों हॉप चाहिए: स्थानीय प्रक्रिया का ठोस प्रॉक्सी एंडपॉइंट और उसके भीतर भेजा अंतिम होस्ट मान। प्रॉक्सी पते को लक्ष्य मानना गंतव्य खोता है, उसे अप्रासंगिक मानना नेटवर्क पथ खोता है।

सही होस्ट कुंजी माँगे गए नाम को सही नहीं बनाती

सख्त होस्ट कुंजी जाँच लक्ष्य स्वीकृति से अलग सीमा बचाती है। उसे चालू रखें, पर वह नहीं बता सकती कि कैननिकल परिणाम मानव के इरादे में था या नहीं। साझा होस्ट कुंजियां, कई principal वाले होस्ट प्रमाणपत्र और स्पष्ट HostKeyAlias ऐसे नाम के तहत क्रिप्टोग्राफ़िक रूप से सही कनेक्शन बना सकते हैं जो स्वीकृति पर नहीं दिखा।

RFC 4251 का SSH प्रोटोकॉल ढाँचा स्थानीय डेटाबेस बताता है जो उपयोगकर्ता के टाइप किए होस्ट नाम को होस्ट कुंजी से जोड़ता है। OpenSSH उस मूल मॉडल के ऊपर कॉन्फ़िग-आधारित नाम जोड़ता है। HostKeyAlias क्लाइंट को होस्ट कुंजी रिकॉर्ड पढ़ते या लिखते और प्रमाणपत्र जाँचते समय असली नाम की जगह उपनाम इस्तेमाल करने को कहता है। यह टनल और एक पते पर कई सर्वरों के लिए उपयोगी है, लेकिन ऑडिट में दर्ज करने योग्य एक और नाम बनाता है।

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

RFC 4462 की GSS-API चेतावनी और साफ है। वह कहता है कि असुरक्षित DNS परिणाम से सर्वर लक्ष्य नाम नहीं बनाना चाहिए, क्योंकि हमलावर उपनाम या पता मैपिंग बदलकर सर्वर बन सकता है। एजेंट सामान्य सार्वजनिक कुंजी प्रमाणीकरण उपयोग करे, तब भी डिज़ाइन सीख वही है। असुरक्षित नाम बदलाव को उस पहचान का निर्णय नहीं करना चाहिए जिसे सुरक्षा नियंत्रण स्वीकृत बताता है।

होस्ट कुंजी सत्यापन कनेक्शन परिणाम को पूर्व जाँच रिकॉर्ड से फिर बाँधे। वास्तव में मिली फ़िंगरप्रिंट, खोज का नाम या उपनाम, प्रमाणपत्र principal का मेल और सख्त जाँच परिणाम लॉग करें। क्लाइंट नई कुंजी के संकेत पर लौटे, तो वह नया सुरक्षा निर्णय है। केवल इसलिए स्वचालित प्रक्रिया उसे स्वीकार न करे कि किसी ने पहले shell कमांड स्वीकृत की थी।

पूर्व जाँच में वही OpenSSH इनपुट होने चाहिए

उपयोगी पूर्व जाँच क्लाइंट की अंतिम कॉन्फ़िग को दोहराती है और दूरस्थ कमांड चलाए बिना कनेक्शन पथ देखती है। ssh -G Host और Match ब्लॉक के मूल्यांकन के बाद कॉन्फ़िग दिखाता है। ssh -vvv रिज़ॉल्यूशन, कनेक्शन और होस्ट कुंजी निदान जोड़ता है; OpenSSH मैनुअल में तीन -v अधिकतम विस्तार हैं।

नियंत्रित वातावरण में यह क्रम चलाएँ और build को ठीक उसी अनुरोधित टोकन से बदलें:

ssh -G build | awk '
  $1 == "hostname" || $1 == "user" || $1 == "port" ||
  $1 == "proxyjump" || $1 == "proxycommand" ||
  $1 == "hostkeyalias" || $1 == "canonicalizehostname" {
    print
  }
'
ssh -vvv -o BatchMode=yes -o SessionType=none \
  -o ConnectTimeout=5 build 2>&1

पहली कमांड का आउटपुट इस रूप में होता है:

user deploy
hostname build-07.hosts.example
port 22
canonicalizehostname true
proxyjump none

विस्तृत रन की पंक्तियां OpenSSH रिलीज़ के अनुसार बदलती हैं, लेकिन बढ़ा हुआ होस्ट, चुना पता और पोर्ट, कॉन्फ़िग पास तथा कुंजी विनिमय में मिली होस्ट कुंजी बताती हैं। एक्ज़ीक्यूटर से संरचित तथ्य लें, डिबग टेक्स्ट को स्थिर API न मानें। जाँच करने वाले ऑपरेटर के लिए कमांड अच्छे हैं; उत्पादन को वही तथ्य सॉकेट खोलने वाले कार्यान्वयन से लेने चाहिए।

इस निदान में दो जाल हैं। पहला, ssh -G निकली क्लाइंट कॉन्फ़िग दिखाता है, पर यह साबित नहीं करता कि बाद का कनेक्शन कौन सा पता चुनेगा और पाएगा। दूसरा, SessionType=none के साथ भी विस्तृत जाँच नेटवर्क कनेक्शन खोलकर कुंजी विनिमय कर सकती है; इसे तभी चलाएँ जब जाँच खुद अधिकृत हो। BatchMode=yes इंटरैक्टिव पासवर्ड और होस्ट कुंजी संकेत रोकता है, पर कनेक्शन को स्थानीय गणना नहीं बनाता।

दोहराई जा सकने वाली जाँच के लिए सभी इनपुट अलग करें। -F से अपेक्षित उपयोगकर्ता कॉन्फ़िग दें, क्लाइंट बिल्ड के सिस्टम कॉन्फ़िग व्यवहार को शामिल करें, Include या टोकन विस्तार के वातावरण चर तय करें और OpenSSH संस्करण दर्ज करें। यह भी दर्ज करें कि कंट्रोल सॉकेट पुराना मल्टीप्लेक्स कनेक्शन उपयोग कर सकता है या नहीं। निष्पादन पुराने मास्टर सत्र से जुड़ जाए तो नए DNS और कॉन्फ़िग की पूर्व जाँच बेकार है।

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

स्वीकृति रिकॉर्ड में बदलाव दिखना चाहिए

अच्छा कार्ड बदलाव स्पष्ट करता है, लेकिन व्यक्ति को डिबग लॉग नहीं पढ़ाता। माँगा लक्ष्य, प्रभावी लक्ष्य और पता साथ रखें। बदलाव न हो तो संक्षेप में कहें। कैननिकलाइज़ेशन या Match ब्लॉक ने महत्वपूर्ण फ़ील्ड बदला हो तो पुराना और नया मान दिखाएँ।

व्यावहारिक स्वीकृति रिकॉर्ड यह रूप ले सकता है:

{
  "requested": {
    "host": "build",
    "user": "deploy",
    "command": "/usr/local/bin/release status"
  },
  "effective": {
    "host": "build-07.hosts.example",
    "address": "192.0.2.44",
    "port": 22,
    "user": "deploy",
    "proxy": null,
    "host_key_alias": null
  },
  "resolution": {
    "canonicalized": true,
    "source": "build.ops.example",
    "permitted_cname": true
  },
  "binding": "sha256:REDACTED"
}

बाइंडिंग में अनुरोधित और प्रभावी फ़ील्ड की तय एन्कोडिंग, दूरस्थ कमांड, फ़ॉरवर्डिंग विकल्प, संबंधित कॉन्फ़िग पहचान, चुना पता या स्वीकृत पता सेट और छोटी समाप्ति शामिल हो। कनेक्टर सॉकेट खोलने से ठीक पहले बाइंडिंग फिर निकाले। DNS, कॉन्फ़िग, कमांड, उपयोगकर्ता, पोर्ट या प्रॉक्सी मार्ग अलग हो तो रुक जाए।

केवल इसलिए कार्ड से फ़ील्ड न हटाएँ कि वह बाइंडिंग में है। मनुष्य वही अधिकृत करते हैं जो उन्हें दिखता है। build -> build-07.hosts.example (192.0.2.44) को एक पढ़ने योग्य बदलाव की तरह दिखाएँ, फिर उपयोगकर्ता, पोर्ट, प्रॉक्सी और कमांड रखें। कच्ची फ़िंगरप्रिंट और कॉन्फ़िग स्रोत विस्तार वाले विवरण में रह सकते हैं, सिवाय उस समय के जब नई या बदली होस्ट पहचान पर ध्यान चाहिए।

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

प्रॉक्सी और कनेक्शन पुन: उपयोग की अलग बाइंडिंग चाहिए

प्रॉक्सी के साथ कैननिकलाइज़ेशन अलग चलता है। CanonicalizeHostname yes केवल बिना ProxyCommand या ProxyJump कनेक्शन पर लागू है; always प्रॉक्सी कनेक्शन भी शामिल करता है। एक शब्द का अंतर अंतिम नाम बदलकर दूसरा कॉन्फ़िग पास चला सकता है। स्वीकृति सिस्टम वास्तविक मान दर्ज करे, यह न माने कि यह हर जगह चालू या बंद है।

हर जंप होस्ट अपनी SSH कनेक्शन है, जिसका अनुरोधित नाम, प्रभावी नाम, पता, उपयोगकर्ता, पोर्ट और प्रमाणित होस्ट कुंजी है। टनल का अंतिम लक्ष्य भी अपनी पहचान रखता है। केवल अंतिम लेबल स्वीकृत करने से अप्रत्याशित या कब्ज़े वाला जंप मार्ग छूटता है। केवल जंप सर्वर स्वीकृत करने से उसका अंतिम फ़ॉरवर्ड गंतव्य छूटता है।

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

यही नियम दोबारा कोशिश पर लागू है। एक पता विफल होने पर दूसरा पता तभी अधिकृत है जब दिखाए स्वीकृत सेट में था। प्रॉक्सी फ़ॉलबैक, वैकल्पिक पोर्ट या नया कैननिकल नाम साधारण ट्रांसपोर्ट विवरण नहीं हैं। वे प्राधिकरण की वस्तु बदलते हैं और नया निर्णय माँगते हैं।

ऑडिट प्रमाण में इरादा और परिणाम दोनों रहें

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

Sallyport अपने साथ आए sp-ssh सहायक से SSH कार्रवाई चलाता है जबकि कुंजियां एन्क्रिप्टेड वॉल्ट में रहती हैं, इसलिए एजेंट को SSH निजी कुंजी नहीं मिलती। इसकी Activity और Sessions जर्नल एक एन्क्रिप्टेड, हैश-चेन ऑडिट लॉग से बनती हैं, जिससे स्वीकृति और निष्पादन पथ केवल shell जैसी स्ट्रिंग के बजाय अनुरोधित और देखे गए दोनों लक्ष्य रख सकते हैं।

रिकॉर्ड रखना पर्याप्त नहीं है। परीक्षण योग्य नियम बनाएँ: चला पता स्वीकृत उम्मीदवार सेट में था, प्रभावी होस्ट और पोर्ट टिकट से मिले, स्वीकृत होस्ट पहचान दर्ज हुई और हर प्रयास या प्रॉक्सी हॉप अधिकृत था। परीक्षण को CanonicalizeHostname, अनुमत CNAME, Match canonical ब्लॉक और दो DNS उत्तर वाला कॉन्फ़िग दें। पूर्व जाँच और कनेक्शन के बीच एक तथ्य बदलें और पक्का करें कि निष्पादन रुकता है।

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