Запит TOTP у OpenConnect відсутній у NetworkManager: чотири перевірки

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

Перша перевірка: прочитайте, де зупинилася автентифікація

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

Прочитайте журнал з'єднання, перш ніж торкатися профілю. Якщо шлюз повідомляє про незавершену автентифікацію або вичерпаний виклик, клієнт так і не надіслав код. Якщо він повідомляє про недійсні облікові дані, проблема в паролі, і жодне налаштування TOTP її не виправить.

Запишіть точну послідовність запитів, яку очікує шлюз: ім'я користувача, пароль, потім код, або ім'я користувача, код, потім пароль. Деякі шлюзи змінюють порядок раундів, і клієнт, який знає лише перший порядок, застрягне на другому.

Друга перевірка: використовуйте клієнт, якому належить виклик

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

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

Клієнт запитує в тому порядку, в якому запитує шлюз. User agent важливий, бо деякі шлюзи підлаштовують потік входу під відомий клієнт, а загальний рядок може дати коротший потік, який ніколи не запитує код. Запустіть його один раз на передньому плані, перш ніж налаштовувати будь-яку фонову службу.

Якщо командний рядок запитує правильно, обліковий запис, шлюз і другий фактор гаразд. Проблема, що залишилася, — діалог плагіна, а не служба автентифікації. Це ізолює несправний компонент, не торкаючись сервера. Збережіть вивід команди разом із записом про інцидент.

Якщо командний рядок теж пропускає запит, зупиніться й перевірте конфігурацію шлюзу разом з його власником. Жоден настільний клієнт не може відповісти на виклик, якого сервер ніколи не надсилає.

Третя перевірка: подивіться, чи пропонує ваш плагін режим TOTP

Деякі збірки NetworkManager OpenConnect пропонують режим токена й поле user agent на вкладці Identity з'єднання. Встановіть user agent у значення, яке очікує шлюз, виберіть ручне введення TOTP і збережіть з'єднання.

Наявність цих полів залежить від версії плагіна та від того, який редактор з'єднань використовує робочий стіл. Окремий редактор може показувати параметри, які панель GNOME приховує, або навпаки. Перевірте версію встановленого пакета, перш ніж шукати приховане налаштування.

Якщо режим токена є, а запит усе одно не з'являється, у збірці немає передавання виклику між плагіном і загальним діалогом секретів. Повторне введення пароля, перевстановлення того самого пакета або очищення зв'язки ключів не створять поле, яке збірка не реалізує.

Четверта перевірка: ставтеся до згенерованого коду як до компромісу

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

Той, хто це вибере, має обмежити файл секрету правами root, тримати згенеровані значення поза історією оболонки й ставитися до скрипта як до матеріалу облікових даних. Обгортка, яка виводить код у термінал, викидає другий фактор. Спершу протестуйте обгортку на одноразовому обліковому записі.

Скрипт також має дотримуватися порядку запитів шлюзу. Якщо сервер запитує код до пароля, фіксована послідовність введення надсилає неправильне значення в неправильний запит і дає ту саму незавершену автентифікацію. Потренуйтеся з тестовим обліковим записом, перш ніж підключати його до завдання входу.

Переконайтеся, що шлюз і обліковий запис ті самі

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

Запишіть клієнт, його версію, user agent і послідовність запитів, яка спрацювала. Цей запис скаже наступній людині, чи проблема в збірці плагіна, у потоці шлюзу чи в політиці облікового запису, без ще одного раунду скидання паролів.

Завершіть одноразовим повторним підключенням після повного виходу. Збережений у кеші секрет може створювати враження, що зламаний потік виправлено, аж до наступного сеансу, і саме при другому підключенні відсутній запит зазвичай повертається.