Mountain Duck SFTP: VPN पछिको दोस्रो लगइन
गेटवे र फाइल सर्भरले फरक-फरक कुरा प्रमाणित गर्छन्। SFTP प्रशासकको होस्टनाम प्रयोग गर्नुहोस्, उनको प्रॉम्प्टको जवाफ दिनुहोस् र होस्ट कुञ्जी जाँच कायम राख्नुहोस्।
VPN जोडिन्छ, मेनु बारले टनेल देखाउँछ, र Mountain Duck अझै लगइन माग्छ। त्यसपछि कोड माग्छ। केही बिग्रेको छैन: दुई फरक प्रणालीले तपाईंलाई प्रमाणित गर्दै छन्, र दोस्रोले पहिलोको बारेमा कहिल्यै सुनेको छैन। VPN को MFA ले गेटवेलाई केही प्रमाणित गर्छ। SFTP सर्भरले आफ्नै खाताविरुद्ध आफ्नै प्रमाण माग्छ।
दुई प्रॉम्प्ट, दुई प्रणाली
गेटवे र फाइल सर्भर अलग नीति-क्षेत्र हुन्। तिनीहरूले एउटै डाइरेक्टरी साझा गर्न सक्छन्, वा तिनीहरू प्रयोग गर्ने व्यक्तिबाहेक केही पनि साझा नहुन सक्छ। VPN मा एक-पटकको कोड पास गर्दा SFTP होस्टमा सत्र बन्दैन, र SFTP होस्टले तपाईंले टनेल प्रयोग गर्नुभयो कि भएन भन्ने जान्न सक्दैन। हरेक प्रणालीले आफू मात्र सोध्ने ठान्छ।
| Layer | What it authenticates | Where the account lives |
|---|---|---|
| VPN | The tunnel endpoint | Gateway or identity provider |
| SFTP | The file session | SSH server or its directory |
| Folder access | Read and write within the share | Filesystem permissions |
तपाईंका नोटमा तीनवटैलाई अलग पङ्क्ति मान्नुहोस्। एउटा असफल हुँदा, कुन कन्सोल खोल्ने भनी पङ्क्तिले बताउँछ, र कामको ठूलो भाग त्यही हो।
SFTP प्रशासकको ठेगाना प्रयोग गर्नुहोस्
बुकमार्कलाई फाइल सेवा वास्तवमै सुन्ने होस्टनाम र पोर्ट चाहिन्छ, जुन अनिवार्य रूपमा VPN सर्भरको ठेगाना होइन। SFTP सेवा चलाउने प्रशासकलाई सोध्नुहोस्, र अरू क्लाइन्टले प्रयोग गर्ने होस्टनाम नै प्रयोग गर्नुहोस्।
सर्भर-पहिचान जाँच अक्षुण्ण राख्नुहोस्। Mountain Duck र Cyberduck पहिलो जडानमा होस्ट कुञ्जी देखाउँछन्, र प्रशासकले अर्को माध्यमबाट दिने मानसँग त्यसको तुलना गर्नु नै गलत सर्भरले तपाईंको प्रमाणहरू पाउनबाट रोक्ने कदम हो। बुकमार्क जोडियोस् भनेर त्यो जाँच बन्द गर्नु सुविधाको भेषमा लिइएको स्थायी निर्णय हो। यसले पछि फाइल तपाईंले चाहेको ठाउँमा गयो भन्ने एकमात्र प्रमाण पनि हटाउँछ।
सर्भरले पठाउने चुनौतीको जवाफ दिनुहोस्
परियोजनाको SFTP कागजातले एक-पटकका कोडका लागि चुनौती-प्रतिक्रिया समर्थन वर्णन गर्छ: सुरुको लगइन प्रॉम्प्ट, त्यसपछि सर्भरले मागेअनुसार कोडका लागि दोस्रो प्रॉम्प्ट। यो प्रवाह सर्भरको कन्फिगरेसनको हो, र क्लाइन्टले पासवर्ड फिल्डमा अर्को मान राखेर सर्भर-पक्षीय दुई-कारक बाध्यता थप्न सक्दैन।
त्यसैले बुकमार्कमा सामान्य खाता प्रमाणहरू हुनुपर्छ, र प्रॉम्प्ट देखा पर्दा कोड टाइप गर्नुपर्छ। परिवर्तनशील कोडलाई स्थायी पासवर्डका रूपमा राख्दा एक-पटक मात्र काम गर्ने र त्यसपछि गलत पासवर्डजस्तो देखिने तरिकाले असफल हुने बुकमार्क बन्छ। कोडलाई VPN प्रमाण फिल्डमा राख्दा असफलता फरक हुन्छ: गेटवेले त्यसलाई अस्वीकार गर्छ, र टनेल कहिल्यै माथि आउँदैन। दुई प्रॉम्प्ट, दुई ठाउँ, र तिनीहरू साट्दा दुवै बिग्रन्छन्।
स्वचालित माउन्टले बटन थिच्न सक्दैन
बुकमार्क पृष्ठभूमिमा फेरि जोडियो भने, अन्तरक्रियात्मक चुनौतीको जवाफ दिने कोही हुँदैन। माउन्ट फेरि प्रयास गर्छ, सर्भर फेरि सोध्छ, र लग सफल हुनै नसक्ने प्रयासले भरिन्छ। व्यक्ति आवश्यक पर्ने नीतिको यो इमानदार परिणाम हो।
अन्तरक्रियाको योजना बनाउनुहोस्: तपाईं उपस्थित हुँदा टनेल र बुकमार्क जोड्नुहोस्, र पछिका स्वचालित पुनःजडानलाई उत्तम प्रयास मान्नुहोस्। कार्यप्रवाहलाई साँच्चै निगरानीविनाको पहुँच चाहिएमा, सर्भर मालिकले अर्को प्रमाणीकरण व्यवस्था स्वीकृत गर्नुपर्छ, जो बुकमार्क सेटिङ होइन, नीति परिवर्तन हो।
माउन्ट भनेको अनुमति होइन
माउन्ट गरिएको भोल्युमले सत्र प्रमाणित भएको प्रमाणित गर्छ। त्यसले खाता त्यो सर्भरमा जहाँ पनि लेख्न सक्छ भनी प्रमाणित गर्दैन। लक्षित फोल्डर जाँच्नुहोस्, तपाईंलाई साँच्चै चाहिने कार्य प्रयास गर्नुहोस्, र जवाफ महत्त्वपूर्ण हुँदा सर्भरको पक्षबाट नतिजा पुष्टि गर्नुहोस्। Finder को साइडबारले भोल्युम देखाउँछ; त्यसले पछाडिका अनुमतिबारे केही भन्दैन।
अर्को प्रोटोकलका लागि, यो क्रम प्रतिलिपि गर्नुको सट्टा त्यो प्रदायकको कागजातमा उल्लेखित प्रमाणीकरण विधि प्रयोग गर्नुहोस्। क्लाउड साइन-इन र SSH चुनौती साइडबारमा उस्तै देखिन सक्छन् र भित्रबाट पूर्ण रूपमा फरक व्यवहार गर्छन्।