SSH ProxyCommand और होस्ट-आधारित प्रमाणीकरण: कौन सा होस्ट हस्ताक्षर करता है?

लक्ष्य बास्टियन से आने वाला TCP कनेक्शन देख सकता है, जबकि प्रमाणीकरण करने वाला SSH क्लाइंट अभी भी वर्कस्टेशन पर चल रहा है।

Host behind-bastion
    ProxyCommand ssh -W %h:%p bastion

यहाँ सहायक बास्टियन में लॉग इन करता है और उसके SSH सर्वर से लक्ष्य तक अग्रेषित कनेक्शन माँगता है। वर्कस्टेशन का बाहरी SSH क्लाइंट उस स्ट्रीम के ज़रिए लक्ष्य का SSH प्रोटोकॉल बदलता है। बास्टियन परिवहन देता है; उसने लक्ष्य की ओर वाला SSH क्लाइंट शुरू नहीं किया है।

यह अंतर होस्ट-आधारित प्रमाणीकरण के लिए महत्वपूर्ण है। OpenSSH का ssh-keysign सहायक आवश्यक हस्ताक्षर बनाने के लिए स्थानीय होस्ट कुंजियों तक पहुँचता है। बास्टियन का नेटवर्क स्रोत पता होना वर्कस्टेशन को बास्टियन की होस्ट कुंजी से हस्ताक्षर करने पर मजबूर नहीं करता।

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

ssh -t bastion ssh target

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

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