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 چیلنج سائیڈ بار میں یکساں نظر آ سکتے ہیں اور اندر سے بالکل مختلف برتاؤ کر سکتے ہیں۔