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-ом, а редослед захтева може се разликовати од увежбаног.

Забележите клијент, његову верзију, кориснички агент и редослед захтева који је радио. Тај запис каже следећој особи да ли је проблем у изградњи додатка, току пролаза или политици налога, без још једног круга ресетовања лозинки.

Завршите једним поновним повезивањем након потпуног одјављивања. Кеширана тајна може учинити да покварен ток изгледа поправљен до следеће сесије, а управо при другом повезивању захтев који недостаје обично се враћа.