Де Linux має зберігати ваш пароль VPN? Не в профілі
Прапорці секретів NetworkManager вирішують, чи пароль тримає профіль, агент зв'язки ключів або ніхто. Відповідь залежить від того, коли запускається з'єднання.
Пароль VPN має десь жити: у профілі з'єднання, у зв'язці ключів, яку розблоковує робочий стіл, або ніде. NetworkManager називає цей вибір прапорцем секрету, і саме неправильний вибір — причина того, що з'єднання працює після входу і не працює як служба. Прапорець — це один рядок конфігурації, і він вирішує, який із трьох результатів ви отримаєте.
Три прапорці покривають майже всі випадки, і рішення залежить від того, коли запускається з'єднання.
Три прапорці секретів, три поведінки
Прапорець 0 означає, що секрет зберігається разом із з'єднанням, у будь-якому сховищі, де лежить профіль. Прапорець 1 робить його власністю агента: секрет надходить від агента секретів, наприклад зв'язки ключів робочого столу, і NetworkManager запитує його під час активації. Прапорець 2 означає не збережено, тому секрет ніколи не записується і має надаватися щоразу. Прапорець 4 позначає секрет як необов'язковий, для з'єднань, яким він справді не потрібен.
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
Задавайте прапорці для кожного секрету, а не для з'єднання. Одне з'єднання може мати пароль, що належить агенту, і збережену парольну фразу закритого ключа.
Вирішуйте за тим, коли запускається з'єднання
Якщо з'єднання запускає користувач, який увійшов, власність агента — розумне значення за замовчуванням: зв'язка ключів розблоковується під час входу, і секрет ніколи не лежить у файлі. Якщо з'єднання має піднятися до того, як хтось увійде, власність агента — неправильний вибір, бо немає зв'язки ключів сеансу, яку можна розблокувати.
Ось і все рішення. Усе інше — його варіант.
Для служби до входу підтримуваний шаблон — сховище системного рівня або захищений файл ключа, і захистом стають права доступу до файлу. Не розв'язуйте проблему, вставляючи пароль у shell-скрипт, який виконується під час завантаження.
Що дає зв'язка ключів, а що ні
Зв'язка ключів тримає секрет поза профілем з'єднання і прив'язує його до сеансу користувача. Вона не робить секрет доступним службі без сеансу і нічого не шифрує в мережі. Це окремі властивості, які люди часто змішують. Що вона справді дає, то це менший радіус ураження, коли профільний файл просочується.
Закритий ключ, на який посилається профіль, потребує власних прав, незалежно від того, де живе пароль.
Діагностика без вивалювання секретів
Назв з'єднань, UUID і прапорців зазвичай достатньо, щоб пояснити збій. nmcli connection show перелічує профіль, а прапорці секретів підказують, звідки пароль мав узятися.
Уникайте --show-secrets у заявках і чатах. Щойно його вставлено, це облікові дані в стенограмі.
Зберігання — це не відкликання
Видалення секрету з однієї зв'язки ключів не анулює облікові дані, які віддалений оператор уже прийняв. Відкликання облікового запису — дія на боці сервера, а локальне зберігання — окреме питання з окремим власником.
Вирішуйте обидва до інциденту, а не під час нього. Інтерактивне з'єднання користувача і служба до входу потребують різних відповідей, а спільний shell-скрипт не є ні тим, ні іншим. Документація NetworkManager про прапорці секретів перелічує значення повністю.