nmcli постоянно спрашивает пароль VPN: сохраните секрет локально

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

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

Подтвердите диагноз, прежде чем что-либо менять

Разница между интерактивной и неинтерактивной активацией — это весь диагноз. Если nmcli --ask connection up завершается успешно, а обычная активация зависает, профиль верен, и источник секрета отсутствует. Это единственное сравнение избавляет вас от переписывания работающей конфигурации.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Читайте флаги, а не угадывайте их. Значения, означающие «спросить агента», — это то, что вы ищете, а точные имена ключей различаются между плагинами VPN, потому что живут в собственном словаре данных плагина. Профиль FortiSSL и профиль IPsec не обязательно используют одни и те же имена, поэтому работайте по выводу собственного профиля.

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

Перенесите секрет в файл ключа

Файл подключения находится в /etc/NetworkManager/system-connections/. Секреты там по умолчанию не хранятся, и в этом смысл только что прочитанных флагов. Установка флага в ноль сообщает NetworkManager, что значение хранится вместе с профилем, а не запрашивается при активации.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

Для профиля с двумя секретами схема повторяется: один флаг на секрет в разделе [vpn], а значения в [vpn-secrets]. Профиль IPsec обычно несёт предварительно общий ключ рядом с учётными данными пользователя, и плагин называет их иначе, чем обычное поле пароля, поэтому копируйте имена ключей из вывода vpn.data, а не из записи в блоге, где использовался другой плагин. Одно неверное имя ключа даёт профиль, который загружается и затем не проходит аутентификацию, что читается точно как неверный пароль. Перед повторным подключением сравните свой файл с работающим профилем того же плагина.

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

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

Перезагрузите, затем активируйте

Файл читается при загрузке подключения, поэтому правки недостаточно. Перезагрузите профили и затем явно поднимите подключение.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

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

Используйте UUID, когда имена неоднозначны. Машины с несколькими клиентскими профилями накапливают почти дубликаты, и активация неверного даёт сбой, который выглядит как проблема с учётными данными.

Когда сохранённый секрет не является проблемой

Профиль FortiSSL может отказать даже с правильными сохранёнными учётными данными, потому что клиент никогда не доверяет сертификату шлюза. Этот параметр не в главном диалоге; он находится за расширенными параметрами VPN, где вводится дайджест доверенного сертификата. Если журнал упоминает сертификат, а не пароль, вы в этой ветке, и никакое количество правки [vpn-secrets] не поможет.

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

Решите, допустимо ли хранение

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

Если политика запрещает хранение секретов VPN, не ослабляйте профиль, чтобы работала задача cron. Запускайте подключение из сеанса, где есть агент, или используйте другой механизм для автоматизации.

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