Запыт TOTP у OpenConnect адсутнічае ў NetworkManager: чатыры праверкі

Шлюз прымае пароль, запытвае код, а дыялог не прапануе для яго ніводнага поля. Нічога не было набрана памылкова: плагін NetworkManager завяршыў абмен сакрэтам, не запытаўшы шасцізначнае значэнне. Прайдзіце чатыры праверкі ніжэй па парадку, бо толькі адна з іх змяняе кліент. Астатні спіс выключае шлюз, уліковы запіс і зборку плагіна.

Праверка першая: прачытайце, дзе спынілася аўтэнтыфікацыя

Няправільны пароль правальваецца адразу. Адсутны другі фактар правальваецца пасля кроку ўліковых даных, звычайна з паўторным запытам або тайм-аўтам на баку шлюза. Час і журнал шлюза паказваюць, які раўнд застаўся без адказу.

Прачытайце журнал злучэння перад тым, як чапаць профіль. Калі шлюз паведамляе пра незавершаную аўтэнтыфікацыю або скончаны па часе выклік, кліент так і не адправіў код. Калі ён паведамляе пра несапраўдныя ўліковыя даныя, праблема ў паролі, і ніякая налада TOTP яе не выправіць.

Заўважце дакладную паслядоўнасць запытаў, якую чакае шлюз: імя карыстальніка, пароль, потым код, або імя карыстальніка, код, потым пароль. Некаторыя шлюзы змяняюць парадак раўндаў, і кліент, які ведае толькі першы парадак, застране на другім.

Праверка другая: выкарыстайце кліент, які валодае выклікам

Сам OpenConnect рэалізуе поўны дыялог, уключаючы раўнд выкліку. Прамы запуск — найбольш прадказальны спосаб пераканацца, што ўліковы запіс і шлюз працуюць:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

Кліент запытвае ў тым парадку, у якім запытвае шлюз. Агент карыстальніка важны, бо некаторыя шлюзы адаптуюць працэс уваходу пад вядомы кліент, а агульны радок можа даць карацейшы працэс, які ніколі не запытвае код. Запусціце яго адзін раз у пярэднім плане, перш чым ладзіць любую фонавую службу.

Калі камандны радок запытвае правільна, уліковы запіс, шлюз і другі фактар у парадку. Пакінутая праблема — дыялог плагіна, а не служба аўтэнтыфікацыі. Гэта ізалюе няспраўны кампанент, не кранаючы сервер. Захавайце вывад каманды з запісам аб інцыдэнце.

Калі камандны радок таксама прапускае запыт, спыніцеся і праверце канфігурацыю шлюза разам з яго ўладальнікам. Ні адзін настольны кліент не можа адказаць на выклік, які сервер ніколі не дасылае.

Праверка трэцяя: паглядзіце, ці прапануе ваш плагін рэжым TOTP

Некаторыя зборкі NetworkManager OpenConnect прапануюць рэжым токена і поле агента карыстальніка на ўкладцы Identity злучэння. Усталюйце агент карыстальніка ў значэнне, якое чакае шлюз, выберыце ручны ўвод TOTP і захавайце злучэнне.

Наяўнасць гэтых палёў залежыць ад версіі плагіна і ад таго, які рэдактар злучэнняў выкарыстоўвае працоўны стол. Асобны рэдактар можа паказваць параметры, якія хавае панэль GNOME, або наадварот. Праверце версію ўсталяванага пакета, перш чым шукаць схаваную наладу.

Калі рэжым токена ёсць, а запыт так і не з'яўляецца, у зборцы няма перадачы выкліку паміж плагінам і агульным дыялогам сакрэтаў. Паўторны ўвод пароля, пераўсталёўка таго ж пакета або ачыстка звязкі ключоў не ствараць поля, якога зборка не рэалізуе.

Праверка чацвёртая: стаўцеся да згенераванага кода як да кампрамісу

Скрыпт можа выклікаць oathtool для бягучага кода і перадаць імя карыстальніка, пароль і код у nmcli connection up --ask. Паслядоўнасць працуе, але агульны сакрэт у выніку захоўваецца ў месцы, чытэльным для любога, хто можа адкрыць скрыпт, і гэты чытач можа ствараць коды бясконца. Гэта пастаяннае пашырэнне паверхні ўліковых даных, а не выпраўленне кліента.

Той, хто выбера гэта, павінен абмежаваць файл сакрэту правамі root, трымаць згенераваныя значэнні па-за гісторыяй абалонкі і ставіцца да скрыпта як да матэрыялу ўліковых даных. Абгортка, якая выводзіць код у тэрмінал, адкідвае другі фактар. Спачатку праверце абгортку на часовым уліковым запісе.

Скрыпт таксама павінен прытрымлівацца парадку запытаў шлюза. Калі сервер запытвае код перад паролем, фіксаваная паслядоўнасць уводу адпраўляе няправільнае значэнне ў няправільны запыт і дае тую ж незавершаную аўтэнтыфікацыю. Адпрацуйце гэта на тэставым уліковым запісе, перш чым падключаць да задачы ўваходу.

Пераканайцеся, што шлюз і ўліковы запіс тыя ж

Праверце кожны абыход з тым жа шлюзам, тым жа ўліковым запісам і той жа групай тунэлю. Шлюз, які таксама патрабуе сертыфікат прылады, можа адхіліць кліент каманднага радка па прычыне, не звязанай з TOTP, і парадак запытаў можа адрознівацца ад адпрацаванага.

Запішыце кліент, яго версію, агент карыстальніка і паслядоўнасць запытаў, якая спрацавала. Гэты запіс падкажа наступнаму чалавеку, ці праблема ў зборцы плагіна, у працэсе шлюза або ў палітыцы ўліковага запісу, без чарговага раўнду скіду пароляў.

Скончыце, падключыўшыся яшчэ раз пасля поўнага выхаду. Закэшаваны сакрэт можа ствараць уражанне, што зламаны працэс выпраўлены, да наступнай сесіі, і менавіта пры другім падключэнні адсутны запыт звычайна вяртаецца.