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 चैलेंज साइडबार में एक जैसे दिख सकते हैं और अंदर से बिल्कुल अलग व्यवहार कर सकते हैं।