SSH ProxyCommand र होस्ट-आधारित प्रमाणीकरण: कुन होस्टले हस्ताक्षर गर्छ?

प्रमाणीकरण गर्ने SSH क्लाइन्ट अझै वर्कस्टेशनमा चलिरहेको बेला लक्ष्यले बास्टियनबाट आउने TCP जडान देख्न सक्छ।

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

यहाँ सहायक बास्टियनमा लगइन गर्छ र त्यसको SSH सर्भरलाई लक्ष्यतर्फ अगाडि पठाइएको जडान माग्छ। वर्कस्टेशनको बाहिरी SSH क्लाइन्टले त्यो स्ट्रिममार्फत लक्ष्यको SSH प्रोटोकल आदानप्रदान गर्छ। बास्टियनले ढुवानी दिन्छ; यसले लक्ष्यतर्फको SSH क्लाइन्ट सुरु गरेको छैन।

होस्ट-आधारित प्रमाणीकरणका लागि यो भिन्नता महत्त्वपूर्ण छ। OpenSSH को ssh-keysign सहायकले आवश्यक हस्ताक्षर बनाउन स्थानीय होस्ट कुञ्जीहरू प्रयोग गर्छ। बास्टियनको सञ्जाल स्रोत ठेगाना हुनुले वर्कस्टेशनलाई बास्टियनको होस्ट कुञ्जीले हस्ताक्षर गर्न बाध्य पार्दैन।

यससँग तुलना गर्नुहोस्:

ssh -t bastion ssh target

यसले बास्टियनमा अर्को SSH कार्यक्रम सुरु गर्छ। त्यसको स्थानीय कन्फिगरेसन र उपलब्ध होस्ट कुञ्जीहरू त्यो मेसिनका हुन्, त्यसैले यो बास्टियन र लक्ष्यबीच पहिले नै कन्फिगर गरिएको होस्ट-आधारित विश्वास व्यवस्थामा सहभागी हुन सक्छ। यसलाई अझै लक्ष्यको सम्बन्धित अनुमति र नाम जाँच आवश्यक छ।

दोस्रो रूपले सत्र कसरी काम गर्छ पनि बदल्छ: यसले टाढाको आदेश चलाउँछ र टर्मिनल प्रयोग गर्छ। यो हरेक SSH फाइल स्थानान्तरण वा स्वचालन ढुवानीका लागि पारदर्शी विकल्प होइन। स्रोत ठेगाना पर्याप्त देखियोस् भनेर सर्भरको विश्वास जाँच कमजोर बनाउनुको सट्टा कुन मेसिनले लक्ष्यसामु प्रमाणीकरण गर्नुपर्ने हो त्यसअनुसार व्यवस्था छान्नुहोस्।