Gdzie Linux powinien przechowywać Twoje hasło VPN? Nie w profilu
Flagi tajemnic NetworkManagera decydują, czy hasło trzyma profil, agent pęku kluczy, czy nikt. Odpowiedź zależy od tego, kiedy połączenie się rozpoczyna.
Hasło VPN musi gdzieś żyć: w profilu połączenia, w pęku kluczy odblokowywanym przez pulpit albo nigdzie. NetworkManager nazywa ten wybór flagą tajemnicy, a wybór złej jest powodem, dla którego połączenie działa po zalogowaniu, a jako usługa zawodzi. Flaga to jedna linia konfiguracji i decyduje, który z tych trzech wyników otrzymasz.
Trzy flagi pokrywają prawie każdy przypadek, a decyzja dotyczy tego, kiedy połączenie się rozpoczyna.
Trzy flagi tajemnic, trzy zachowania
Flaga 0 oznacza, że tajemnica jest zapisywana razem z połączeniem, w dowolnym magazynie, który trzyma profil. Flaga 1 czyni ją własnością agenta: tajemnica pochodzi od agenta tajemnic, takiego jak pęk kluczy pulpitu, a NetworkManager pyta o nią przy aktywacji. Flaga 2 oznacza niezapisana, więc tajemnica nigdy nie jest zapisywana i trzeba ją podawać za każdym razem. Flaga 4 oznacza tajemnicę jako nie wymaganą, dla połączeń, które naprawdę jej nie potrzebują.
| 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 |
Ustawiaj flagi dla każdej tajemnicy, a nie dla połączenia. Jedno połączenie może mieć hasło będące własnością agenta i zapisaną frazę hasła klucza prywatnego.
Zdecyduj według tego, kiedy połączenie się rozpoczyna
Jeśli połączenie uruchamia zalogowany użytkownik, własność agenta jest rozsądnym ustawieniem domyślnym: pęk kluczy jest odblokowany przez logowanie i tajemnica nigdy nie leży w pliku. Jeśli połączenie musi wstać, zanim ktokolwiek się zaloguje, własność agenta jest złym wyborem, ponieważ nie ma pęku kluczy sesji do odblokowania.
To cała decyzja. Wszystko inne jest jej wariantem.
Dla usługi przed logowaniem obsługiwanym wzorcem jest magazyn na poziomie systemu albo chroniony plik klucza, a ochroną stają się uprawnienia pliku. Nie rozwiązuj problemu, wklejając hasło do skryptu powłoki uruchamianego przy starcie.
Co daje pęk kluczy, a czego nie
Pęk kluczy trzyma tajemnicę poza profilem połączenia i wiąże ją z sesją użytkownika. Nie udostępnia tajemnicy usłudze bez sesji i niczego nie szyfruje na łączu. To odrębne właściwości, które ludzie często łączą. To, co naprawdę daje, to mniejszy promień szkód, gdy wycieknie plik profilu.
Klucz prywatny, do którego odwołuje się profil, potrzebuje własnych uprawnień, niezależnie od tego, gdzie żyje hasło.
Diagnostyka bez wylewania tajemnic
Nazwy połączeń, UUID i flagi zwykle wystarczają, by wyjaśnić awarię. nmcli connection show wymienia profil, a flagi tajemnic mówią, skąd hasło miało pochodzić.
Unikaj --show-secrets w zgłoszeniach i czacie. Po wklejeniu jest danymi uwierzytelniającymi w zapisie rozmowy.
Przechowywanie to nie unieważnienie
Usunięcie tajemnicy z jednego pęku kluczy nie unieważnia danych uwierzytelniających, które zdalny operator już zaakceptował. Unieważnienie konta to działanie po stronie serwera, a lokalne przechowywanie to osobna sprawa z osobnym właścicielem.
Zdecyduj o obu przed incydentem, nie w jego trakcie. Interaktywne połączenie użytkownika i usługa przed logowaniem wymagają różnych odpowiedzi, a wspólny skrypt powłoki nie jest żadnym z nich. Dokumentacja NetworkManagera dotycząca flag tajemnic wymienia wartości w całości.