Mountain Duck SFTP: VPN-এর পরে দ্বিতীয় লগইন
গেটওয়ে ও ফাইল সার্ভার ভিন্ন ভিন্ন জিনিস যাচাই করে। SFTP প্রশাসকের হোস্টনাম ব্যবহার করুন, তার প্রম্পটের উত্তর দিন এবং হোস্ট কী যাচাই রাখুন।
VPN সংযোগ হয়, মেনু বারে একটি টানেল দেখা যায়, তবুও Mountain Duck লগইন চায়। তারপর একটি কোড চায়। কিছুই নষ্ট হয়নি: দুটি ভিন্ন সিস্টেম আপনাকে যাচাই করছে, আর দ্বিতীয়টি প্রথমটির কথা কখনও শোনেনি। VPN-এর এমএফএ গেটওয়েকে কিছু প্রমাণ করে। 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 চ্যালেঞ্জ সাইডবারে একই রকম দেখাতে পারে, অথচ ভেতরে সম্পূর্ণ ভিন্নভাবে আচরণ করে।