Mountain Duck SFTP: другий вхід після VPN
Шлюз і файловий сервер перевіряють різні речі. Використовуйте ім’я хоста від адміністратора SFTP, дайте відповідь на його запит і збережіть перевірку ключа хоста.
VPN підключається, у рядку меню видно тунель, а Mountain Duck усе одно просить вхід. Потім він просить код. Нічого не зламано: дві різні системи перевіряють вас, і друга ніколи не чула про першу. MFA у 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 можуть виглядати однаково в бічній панелі й поводитися зовсім по-різному всередині.