प्रोडक्शन तक पहुँचने वाले एजेंटों के लिए SSH होस्ट सत्यापन

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

SSH दो अलग सुरक्षा सवाल पूछता है: «क्या मैं इच्छित सर्वर तक पहुँचा?» और «उस सर्वर पर यह खाता क्या कर सकता है?» दोनों में सार्वजनिक कुंजियों का इस्तेमाल होने के कारण टीमें अक्सर इन्हें मिला देती हैं। इस गलती से गलत दिशा में हुआ कनेक्शन पहले क्रेडेंशियल उजागर करता है और फिर अत्यधिक अधिकार वाला खाता प्रोडक्शन घटना में बदल जाता है।

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

उपयोगकर्ता प्रमाणीकरण से पहले होस्ट की पहचान जाँचें

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

होस्ट कुंजी सर्वर की होती है, न कि एडमिनिस्ट्रेटर या एजेंट की। फिंगरप्रिंट उस सार्वजनिक होस्ट कुंजी का छोटा रूप है, जिसे आम तौर पर SHA256 रूप में दिखाया जाता है। यदि deploy.example.internal सामान्यतः एक फिंगरप्रिंट दिखाता है और अचानक दूसरा दिखाने लगे, तो क्लाइंट के पास बदलाव का संकेत है। यह वैध रीबिल्ड हो सकता है। यह DNS त्रुटि, दोबारा इस्तेमाल किया गया पता, बास्टियन की गलती या सक्रिय अवरोधन प्रयास भी हो सकता है।

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

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

होस्ट सत्यापन यह सुनिश्चित नहीं करता कि मशीन स्वस्थ, सही ढंग से कॉन्फ़िगर या बदलाव के लिए सुरक्षित है। यह केवल क्रिप्टोग्राफ़िक पहचान की निरंतरता की पुष्टि करता है। यह सीमा उपयोगी है। rm -rf, स्कीमा माइग्रेशन या फ़ायरवॉल बदलाव उचित है या नहीं, इसका निर्णय होस्ट फिंगरप्रिंट से न लें।

बिना निगरानी वाले काम के लिए ट्रस्ट ऑन फर्स्ट यूज़ सही नहीं है

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

OpenSSH इस विकल्प को ssh_config मैनुअल में StrictHostKeyChecking के तहत समझाता है। yes के साथ क्लाइंट अनजान होस्ट कुंजी अपने-आप नहीं जोड़ता और बदली हुई कुंजी को अस्वीकार करता है। accept-new अनजान कुंजी को अपने-आप रिकॉर्ड करता है, लेकिन बदली हुई कुंजी को फिर भी अस्वीकार करता है। no या off के साथ वह ऐसे अधिक मामलों को स्वीकार करता है जिन पर ऑपरेटर का ध्यान जाना चाहिए।

accept-new को अक्सर समझदार समझौते की तरह पेश किया जाता है। जब होस्ट बार-बार बनाए जाते हैं, तो इससे बदलाव कम होते हैं। लेकिन इससे नेटवर्क पथ को शुरुआती पहचान रिकॉर्ड स्थापित करने का अधिकार भी मिल जाता है। इन्फ्रास्ट्रक्चर बदल सकने वाले एजेंट के लिए यह निर्णय गलत पक्ष ले रहा है।

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

रुकावट दूर करने के लिए वैश्विक कॉन्फ़िगरेशन फ़ाइल में StrictHostKeyChecking=no न रखें। यह पंक्ति अक्सर उस अस्थायी घटना से भी अधिक समय तक रहती है जिसके कारण उसे जोड़ा गया था और फिर चुपचाप उन होस्ट पर भी लागू होती है जिनके लिए नीति ढीली करने का इरादा नहीं था।

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

फिंगरप्रिंट तभी उपयोगी है जब उसका स्रोत स्वतंत्र हो

जिस एंडपॉइंट को आप सत्यापित करने की कोशिश कर रहे हैं, उसी से कॉपी किया गया फिंगरप्रिंट लगभग कुछ साबित नहीं करता। सार्वजनिक होस्ट कुंजियाँ इकट्ठी करने के लिए ssh-keyscan सुविधाजनक है और इसी सुविधा से एक आम जाल बनता है: ऑपरेटर इसे होस्टनाम पर चलाता है, परिणाम को known_hosts में चिपका देता है और होस्ट को सत्यापित मान लेता है। यदि DNS या रूटिंग पहले ही हमलावर की ओर जा रही हो, तो उसने हमलावर की कुंजी पिन कर दी।

स्वतंत्र फिंगरप्रिंट मिलने के बाद कुंजियाँ इकट्ठी करने के लिए ssh-keyscan इस्तेमाल करें, भरोसे के स्रोत के रूप में नहीं। उदाहरण के लिए, एडमिनिस्ट्रेटर प्रोवाइडर कंसोल या हस्ताक्षरित बिल्ड रिकॉर्ड से होस्ट कुंजी का फिंगरप्रिंट प्राप्त कर सकता है और फिर उसे इकट्ठी की गई कुंजी से मिला सकता है।

ssh-keyscan -t ed25519 app-prod.internal > /tmp/app-prod.hostkey
ssh-keygen -lf /tmp/app-prod.hostkey -E sha256

दूसरी कमांड इस तरह का आउटपुट दिखाती है:

256 SHA256:exampleFingerprintMaterial app-prod.internal (ED25519)

SHA256: मान की स्वतंत्र रूप से प्राप्त मान से अक्षर-दर-अक्षर तुलना करें। एल्गोरिदम भी जाँचें। यदि रिकॉर्ड में ED25519 लिखा है और इकट्ठा परिणाम RSA है, तो दोनों को समान मानने के बजाय रुकें और जाँच करें।

इसके बाद केवल फिंगरप्रिंट वाली टिप्पणी नहीं, बल्कि सार्वजनिक कुंजी पिन करें। अलग फ़ाइल एजेंट के लक्ष्यों को डेवलपर द्वारा पुराने कंप्यूटरों के जमा किए गए निजी रिकॉर्ड से अलग रखती है:

app-prod.internal ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExamplePublicHostKeyMaterial
[192.0.2.44]:22 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExamplePublicHostKeyMaterial

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

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

SSH कॉन्फ़िगरेशन में रूट और होस्ट रिकॉर्ड पिन करें

एजेंट को ऐसा SSH कॉन्फ़िगरेशन चाहिए जो अस्पष्टता हटाए, न कि वर्कस्टेशन की आदतों पर निर्भर रहे। स्पष्ट एंट्री में गंतव्य नाम, अपेक्षित होस्ट-कुंजी फ़ाइल, खाता और कनेक्शन व्यवहार पिन करें।

Host app-production
    HostName app-prod.internal
    User agent_release
    Port 22
    UserKnownHostsFile ~/.ssh/agent_known_hosts
    GlobalKnownHostsFile /dev/null
    StrictHostKeyChecking yes
    UpdateHostKeys no
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    ForwardAgent no
    PermitLocalCommand no

यह अंश कई आम गलतियों को रोकता है। UserKnownHostsFile मानव द्वारा जमा किए गए होस्ट रिकॉर्ड पर अनपेक्षित निर्भरता से बचाता है। GlobalKnownHostsFile /dev/null बिना प्रबंधन वाली मशीन-स्तरीय फ़ाइल को चुपचाप भरोसे की सीमा बढ़ाने से रोकता है। UpdateHostKeys no एजेंट के काम के दौरान स्वचालित होस्ट-कुंजी अपडेट से पिन सेट बदलने नहीं देता। ForwardAgent no रिमोट मशीन को फ़ॉरवर्ड किए गए प्रमाणीकरण एजेंट के ज़रिए कहीं और पहुँचने से रोकता है।

OpenSSH का ssh_config मैनुअल बताता है कि UpdateHostKeys किसी भरोसेमंद कुंजी का स्वामित्व साबित करने वाले होस्ट के लिए होस्ट-कुंजी रोटेशन में मदद करता है। अनुशासित होस्ट प्रबंधन वाले इंटरैक्टिव फ्लीट के लिए यह उपयोगी हो सकता है। स्वायत्त एजेंट के लिए अपने-आप होने वाला बदलाव घटना की समीक्षा कठिन बनाता है। किसी व्यक्ति को प्रोडक्शन पहचान बदलाव को मंज़ूरी देकर नियंत्रित होस्ट फ़ाइल को जानबूझकर अपडेट करना चाहिए।

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

एजेंट को कोई क्रेडेंशियल पथ देने से पहले प्रभावी कॉन्फ़िगरेशन जाँचें:

ssh -G app-production | grep -E '^(hostname|user|stricthostkeychecking|userknownhostsfile|forwardagent|updatehostkeys) '

इस तरह के मान अपेक्षित हैं:

hostname app-prod.internal
user agent_release
stricthostkeychecking yes
userknownhostsfile /Users/operator/.ssh/agent_known_hosts
forwardagent no
updatehostkeys no

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

सही कनेक्शन के बाद भी खाता नुकसान सीमित करता है

सत्यापित होस्ट को भी गलत कमांड मिल सकती है, इसलिए एजेंट को छोटा और जानबूझकर सीमित काम वाला खाता दें। स्वायत्त कोडिंग एजेंट को वह SSH लॉगिन न दें जिसे ऑपरेटर हर आपात स्थिति में इस्तेमाल करता है।

खाते की सीमा के चार हिस्से हैं: खाता किस होस्ट तक पहुँचता है, किन फ़ाइलों और सेवाओं को प्रभावित कर सकता है, उसके पास विशेषाधिकार बढ़ाने के कौन-से रास्ते हैं और वह कितने समय तक उपयोगी रहेगा। अलग खाता इन सवालों के उत्तरों को जाँचने योग्य बनाता है। साझा deploy लॉगिन हर ऑटोमेशन रन को जिम्मेदारी तय करने की समस्या बना देता है और अक्सर व्यापक अधिकारों पर समाप्त होता है, क्योंकि हर नए वर्कफ़्लो को एक और अपवाद चाहिए।

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

जहाँ काम सीमित हो, वहाँ फ़ोर्स्ड कमांड से अधिकृत SSH सार्वजनिक कुंजी को सीमित करें। authorized_keys में सर्वर-साइड एंट्री उस क्रेडेंशियल को रैपर से बाँध सकती है:

command="/usr/local/sbin/agent-release-wrapper",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleAgentPublicKey agent-release

रैपर को सीमित तर्कों का विश्लेषण करना चाहिए, शेल मेटाकैरेक्टर अस्वीकार करने चाहिए, अनुरोधित ऑपरेशन लॉग करना चाहिए और तय पथ वाली निश्चित बाइनरी चलानी चाहिए। ऐसा रैपर न लिखें जो SSH_ORIGINAL_COMMAND में मनमाना स्ट्रिंग लेकर उसे sh -c को दे दे। इससे बस बिना सीमा वाला रिमोट शेल एक्सेस किसी फ़ंक्शन नाम के पीछे छिप जाता है।

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

कम समय के लिए मान्य SSH प्रमाणपत्र सफ़ाई का बोझ घटा सकते हैं, यदि आपके पास स्पष्ट जारी करने वाले नियंत्रणों वाला प्रमाणपत्र प्राधिकरण पहले से है। वे होस्ट सत्यापन की ज़रूरत खत्म नहीं करते। प्रमाणपत्र क्लाइंट खाते के बारे में कुछ बताता है, जबकि होस्ट फिंगरप्रिंट बताता है कि प्रमाणपत्र किस सर्वर ने प्राप्त किया।

कमांड समीक्षा में अस्पष्ट इरादा नहीं, प्रभाव दिखना चाहिए

कमांड की स्वीकृति तभी उपयोगी है जब व्यक्ति उसके प्रभाव का आकलन करने के लिए पर्याप्त संदर्भ देख सके। «रिलीज़ डिप्लॉय करें» एक इरादा है। app-production पर agent_release के रूप में sudo systemctl restart payments-api ऐसी कार्रवाई है जिसकी समीक्षा की जा सकती है।

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

रिमोट कार्रवाई के लिए एक उचित स्वीकृति रिकॉर्ड ऐसा हो सकता है:

Target: app-production (app-prod.internal)
Account: agent_release
Command: /usr/local/sbin/agent-release-wrapper activate 2025.04.17-rc2
Reason: activate the approved release after smoke tests

इस अनुरोध से इसकी तुलना करें:

ssh app-production "curl $URL | sudo sh"

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

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

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

खतरनाक विफलता का रास्ता आम तौर पर सामान्य शॉर्टकट की एक कड़ी होता है

ऑटोमेशन से जुड़ी अधिकांश SSH घटनाएँ किसी असाधारण क्रिप्टोग्राफ़िक हमले से शुरू नहीं होतीं। वे सेटअप के दौरान harmless लगे किसी शॉर्टकट से शुरू होती हैं।

मान लें कि किसी रिलीज़ एजेंट में StrictHostKeyChecking=accept-new, साझा डिप्लॉयमेंट खाता और केवल «run deploy» कहने वाला स्वीकृति प्रॉम्प्ट है। इन्वेंटरी अपडेट पूरा होने से पहले DNS रिकॉर्ड कुछ समय के लिए बदली हुई मशीन की ओर चला जाता है। एजेंट अनजान होस्ट देखता है, उसकी कुंजी रिकॉर्ड करता है, साझा खाते के कारण उस मशीन में लॉग इन करता है और डिप्लॉयमेंट रैपर चलाता है। साझा खाता आपातकालीन मरम्मत में भी इस्तेमाल होता है, इसलिए रैपर के पास व्यापक लेखन अधिकार हैं।

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

हर नियंत्रण इस कड़ी के अलग बिंदु को रोकता है:

1. पहले से पिन किया गया होस्ट रिकॉर्ड बदली हुई मशीन को तब तक अस्वीकार करता है, जब तक ऑपरेटर उसे सत्यापित न कर दे।
2. अलग खाता उस नुकसान को सीमित करता है जो तब भी हो सकता है जब स्वीकृत लक्ष्य किसी ऐसे तरीके से गलत हो जिसे होस्ट पहचान पकड़ नहीं सकती।
3. पूरी कमांड वाला स्वीकृति रिकॉर्ड समीक्षक को अनपेक्षित लक्ष्य या ऊँचे विशेषाधिकार वाली कार्रवाई पहचानने का मौका देता है।
4. सत्र और कॉल का ट्रेल विफलता के बाद टीम को अनुरोध, स्वीकृति, लक्ष्य और परिणाम फिर से समझने देता है।

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

होस्ट-कुंजी रोटेशन के लिए अपवाद बटन नहीं, बदलाव की प्रक्रिया चाहिए

होस्ट कुंजियाँ वैध कारणों से बदलती हैं: मशीन रीबिल्ड होती है, इमेज बदली जाती है, कोई एल्गोरिदम हटाया जाता है या संदिग्ध उजागर होने के बाद ऑपरेटर क्रेडेंशियल बदलता है। इन्हें चेतावनी संवाद बंद करने के बजाय प्रमाण सहित नियोजित पहचान बदलाव मानें।

होस्ट के लिए जिम्मेदार व्यक्ति को नई मशीन के कंसोल या किसी अन्य प्रमाणित प्रबंधन पथ से नई सार्वजनिक होस्ट कुंजी प्राप्त करनी चाहिए। उसे नियंत्रित known-hosts फ़ाइल में नई एंट्री प्रकाशित करनी चाहिए, बदलाव का कारण दर्ज करना चाहिए और कटओवर सफल होने के बाद ही पुरानी एंट्री हटानी चाहिए। यदि संक्रमण के दौरान मशीन को सेवा जारी रखनी हो, तो OpenSSH एक ही होस्टनाम के लिए एक से अधिक स्वीकृत होस्ट कुंजी रख सकता है। इससे तय अवधि में क्लाइंट पुरानी और नई दोनों पहचान स्वीकार कर सकते हैं।

रोटेशन रिकॉर्ड छोटा लेकिन विशिष्ट रखें: होस्टनाम, ज़रूरत होने पर पता, पुराना फिंगरप्रिंट, नया फिंगरप्रिंट, कारण, सत्यापनकर्ता और दोहरी-कुंजी अवधि की समाप्ति। «SSH changed» लिखा टिकट यह बताने के लिए पर्याप्त नहीं है कि बदलाव नियोजित था या किसी ने क्लाइंट को impostor पर भरोसा करना सिखाया।

एजेंट को ssh-keygen -R hostname चलाकर अपने-आप दोबारा कनेक्ट करने का निर्देश कभी न दें। पुराना रिकॉर्ड हटाने से पहले ही गड़बड़ी का संकेत मिट जाता है। सत्यापन के बाद ऑपरेटर समीक्षा किए गए अपडेट के हिस्से के रूप में यह कमांड चला सकता है, लेकिन एजेंट वर्कफ़्लो में यह रिकवरी लॉजिक नहीं होना चाहिए।

ऑडिट रिकॉर्ड से निर्णय को फिर से समझा जा सके

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

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

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

Sallyport सत्र और गतिविधि जर्नल को लिखने की अनुमति से अलग, एन्क्रिप्टेड और हैश-चेन वाले ऑडिट लॉग से प्रोजेक्ट करता है; sp audit verify वॉल्ट कुंजी के बिना ऑफलाइन चेन की जाँच कर सकता है। किसी अपवाद की जाँच के लिए ऐसे प्रमाण का इस्तेमाल करें, लेकिन होस्ट पिनिंग, खाते की सीमाएँ और स्वीकृति का पाठ उस समय तय कर लें जब घटना अभी पढ़ने का कारण न बनी हो।

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