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 могуць выглядаць аднолькава ў бакавой панэлі, а пад сподам паводзіць сябе цалкам па-рознаму.