Прочитайте название параметра буквально. Оно называет ключ, и путаница начинается, когда разблокируемый файл принимают за учётную запись, которая проходит аутентификацию. Вставьте пароль учётной записи в этот параметр, и клиент попытается открыть им файл ключа, что не удаётся по причинам, не имеющим никакого отношения к входу в VPN.

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

Два секрета, две разные задачи

Читайте роли как доступ к файлу в противовес допуску в сеть. Пароль ключа расшифровывает закрытый ключ PEM, указанный в --sslkey, чтобы можно было предъявить клиентский сертификат TLS. Это расшифрование происходит локально, внутри процесса клиента, и сама парольная фраза никогда не уходит на шлюз. Шлюз видит сертификат и подпись, сделанную ключом. Руководство OpenConnect держит --key-password рядом с --certificate и --sslkey, а в сборках, которые могут использовать ключ в TPM, тот же параметр несёт вместо этого пароль корневого ключа хранилища.

Пароль учётной записи другого рода. Он входит в обмен аутентификации: форма с именем пользователя и паролем, токен, круг SAML или некая комбинация, которую объявляет шлюз. Некоторые развёртывания вовсе не спрашивают его, когда сертификат является единственным фактором, а некоторые спрашивают даже после сертификата, потому что сертификат доказывает устройство, а учётная запись — человека.

Смешение двух даёт вводящие в заблуждение ошибки. Шлюз, отклоняющий вход, обычно сообщает об ошибке аутентификации, тогда как неверная парольная фраза ключа обычно терпит неудачу раньше, когда уровень TLS не может прочитать файл ключа. Это разные этапы с разными исправлениями, и имена достаточно похожи, чтобы люди путали их и потом гонялись за не тем журналом. Отметьте, какой запрос появился, прежде чем менять любую настройку, потому что формулировка запроса — самая дешёвая диагностика, которая у вас есть.

Когда пароль ключа действительно нужен

Параметр имеет смысл только тогда, когда есть зашифрованный ключ, который нужно разблокировать. Если вы подключаетесь с именем пользователя и паролем и без клиентского сертификата, --key-password не на что действовать, и его добавление ничего не меняет. Если вы подключаетесь с --certificate и --sslkey, запрашивается ли парольная фраза вообще, решает формат самого файла ключа.

Оба секрета в одной команде обычны в управляемых средах: сертификат устройства в зашифрованном ключе плюс вход для каждого пользователя. Правильная последовательность — дать клиенту локально запросить парольную фразу ключа, завершить рукопожатие сертификата и затем отдельно обработать запрос учётной записи от шлюза. Попытка заранее заполнить оба через один переиспользуемый скрипт — это место, где путаница обычно и начинается.

Полезная диагностика — посмотреть, когда происходит сбой. Если клиент останавливается до начала любой сетевой аутентификации, подозревайте файл ключа, его формат или парольную фразу. Если сеанс TLS установлен и затем шлюз отклоняет пользователя, ключ сделал своё дело, и проблема в обмене учётной записи.

Держите оба секрета вне истории оболочки

Аргументы командной строки доступны для чтения другим локальным пользователям через таблицу процессов и часто попадают в историю оболочки, скрипты и стенограммы поддержки. OpenConnect умеет читать пароль учётной записи со стандартного ввода с помощью --passwd-on-stdin, а парольная фраза ключа может приходить из интерактивного запроса или от агента, а не из аргумента. Ни один механизм сам по себе не делает секрет безопасным, но оба держат его вдали от самых открытых мест.

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

Диагностический вывод — это тихая утечка. Журналы клиента при большей подробности могут показывать тела запросов или значения параметров, а скопированная стенограмма терминала легко вставляется в тикет, поэтому прочитайте вывод, прежде чем им делиться.

Мёртвая кнопка на рабочем столе — это другая неисправность

Запись VPN на рабочем столе, которая показывает крутящийся индикатор, а затем ничего, обычно вовсе не является проблемой аутентификации. Кнопка принадлежит сетевому менеджеру, апплету производителя или плагину, который запускает OpenConnect от вашего имени, и отсутствующий компонент или нечитаемый профиль могут дать именно этот симптом. Выясните, какой процесс запускает кнопка, и прочитайте его ошибку, прежде чем трогать учётные данные.

Соблазнительно ослабить проверку сертификата или отключить проверку, когда графический интерфейс отказывается подключаться. Это превращает неисправность интеграции клиента в снижение безопасности и редко исправляет проблему запуска. Оставьте проверку сервера нетронутой, убедитесь, что профиль указывает на нужный шлюз, и проверьте, действительно ли установлен помощник, которого ожидает интерфейс.

Короткий контрольный список разделяет случаи. Локальный сбой до выхода любого пакета указывает на ключ или установку клиента. Отказ шлюза после сеанса TLS указывает на обмен учётной записи. Кнопка, которая никогда не запускает клиент, указывает на интеграцию с рабочим столом. Три разные неисправности, одна из которых — пароль, который вы собирались вставить не в то поле.

Похожие статьи