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 могут выглядеть одинаково в боковой панели и вести себя совершенно по-разному внутри.