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

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

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