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 می‌توانند در نوار کنار یکسان به نظر برسند و در زیر کاملاً متفاوت رفتار کنند.