nmcli blijft om het VPN-wachtwoord vragen: bewaar het geheim lokaal

Hetzelfde profiel, twee sessies: het verbindt vanaf de desktop en blijft via SSH hangen op een prompt die niets kan beantwoorden. Niets is kapot en geen enkele instelling is verloren. NetworkManager vraagt een geheimenagent om de inloggegevens, en een geheimenagent is een desktopcomponent die niet bestaat in de sessie die u gebruikt.

Voer de onderstaande reeks uit en de tunnel komt omhoog zonder scherm, met de kanttekening dat het opslaan van een geheim verandert wie dat profiel kan gebruiken.

Bevestig de diagnose voordat u iets wijzigt

Het verschil tussen interactieve en niet-interactieve activering is de hele diagnose. Als nmcli --ask connection up slaagt terwijl een gewone activering vastloopt, is het profiel correct en ontbreekt de bron van het geheim. Die ene vergelijking bespaart u het herschrijven van een werkende configuratie.

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

Lees de vlaggen in plaats van ze te raden. Waarden die "vraag een agent" betekenen, zijn wat u zoekt, en de exacte sleutelnamen verschillen tussen VPN-plugins omdat ze in het eigen datawoordenboek van de plugin leven. Een FortiSSL-profiel en een IPsec-profiel gebruiken niet noodzakelijk dezelfde namen, dus werk vanuit de uitvoer van uw eigen profiel.

Controleer ook of het plugin-pakket voor dat protocol is geïnstalleerd. Een ontbrekende plugin verschijnt als een onbekend verbindingstype of als een activeringsfout die niets over wachtwoorden zegt, en achter het geheim aan jagen in die toestand verspilt hetzelfde uur twee keer. Eén pakketquery is goedkoper dan een hele middag sleutelbestanden bewerken.

Verplaats het geheim naar het sleutelbestand

Het verbindingsbestand staat onder /etc/NetworkManager/system-connections/. Geheimen worden daar standaard niet bewaard, en dat is het punt van de vlaggen die u net hebt gelezen. Een vlag op nul zetten vertelt NetworkManager dat de waarde bij het profiel is opgeslagen in plaats van bij activering te worden gevraagd.

[vpn]
password-flags=0

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

Voor een profiel met twee geheimen herhaalt het patroon zich: één vlag per geheim in de sectie [vpn], en de waarden in [vpn-secrets]. Een IPsec-profiel draagt meestal een vooraf gedeelde sleutel naast de gebruikersgegevens, en de plugin noemt ze anders dan een gewoon wachtwoordveld, dus kopieer de sleutelnamen uit de uitvoer van vpn.data in plaats van uit een blogbericht dat een andere plugin gebruikte. Eén verkeerde sleutelnaam levert een profiel op dat laadt en daarna faalt bij authenticatie, wat precies leest als een verkeerd wachtwoord. Vergelijk uw bestand met een werkend profiel van dezelfde plugin voordat u opnieuw verbindt.

Zet waarden tussen aanhalingstekens die spaties, aanhalingstekens of een dollarteken bevatten. Een waarde zonder aanhalingstekens met een $ erin wordt letterlijk gelezen of uitgebreid, afhankelijk van waar die wordt geparseerd, en de resulterende authenticatiefout lijkt op een verkeerd wachtwoord.

Herstel daarna het eigendom en de modus van het bestand. Deze sleutelbestanden worden gelezen door een bevoorrechte dienst, en een bestand dat andere gebruikers kunnen lezen, wordt als onbetrouwbaar beschouwd, wat de gebruikelijke reden is waarom een bewerkt profiel genegeerd lijkt te worden. Eigenaar root, modus 600, geen uitzonderingen.

Herlaad, activeer daarna

Het bestand wordt gelezen wanneer de verbinding wordt geladen, dus bewerken is niet genoeg. Herlaad de profielen en breng de verbinding daarna expliciet omhoog.

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

Als het herladen de wijziging niet oppakt, doet een volledige herstart van de dienst dat, en daar zijn precies zulke meldingen over. Geef de voorkeur aan herladen wanneer andere verbindingen belangrijk zijn, want een herstart van de dienst verbreekt elke beheerde verbinding, en op een externe host kan dat uw sessie beëindigen voordat de gewenste tunnel omhoog is.

Gebruik de UUID wanneer namen dubbelzinnig zijn. Machines met meerdere klantprofielen verzamelen bijna-duplicaten, en het verkeerde activeren levert een fout op die op een inloggegevensprobleem lijkt.

Wanneer het opgeslagen geheim niet het probleem is

Een FortiSSL-profiel kan mislukken, zelfs met correct opgeslagen inloggegevens, omdat de client het certificaat van de gateway nooit vertrouwt. Die instelling staat niet in de hoofddialoog; ze zit achter de geavanceerde opties voor de VPN, waar de digest van het vertrouwde certificaat wordt ingevoerd. Als het logboek het certificaat vermeldt in plaats van het wachtwoord, zit u in deze tak en helpt geen enkele bewerking van [vpn-secrets].

Hier horen nog twee controles bij. Bevestig dat het profiel niet is geïmporteerd uit een bestand dat nog steeds naar een pad wijst dat de plugin niet kan lezen, en bevestig dat het profiel het actieve is en geen verouderd duplicaat. Beide leveren activeringsfouten op die als authenticatiefouten lezen.

Bepaal of opslaan aanvaardbaar is

Een opgeslagen PSK en wachtwoord zijn leesbaar voor alles wat als root op die machine draait. Op een machine die u beheert, is dat een redelijke ruil voor een dienst zonder scherm. Op een gedeelde host verdient het een gesprek, omdat het profiel nu inloggegevens bevat die voorheen door de sleutelhanger van de desktop werden beschermd. Vraag wie anders root op die host kan bereiken voordat u beslist, niet nadat de wijziging is doorgevoerd.

Als het beleid opgeslagen VPN-geheimen verbiedt, verzwak het profiel dan niet om een cron-taak te laten werken. Voer de verbinding uit vanuit een sessie met een agent, of gebruik een ander mechanisme voor de automatisering.

Noteer ten slotte welke profielen geheimen dragen, zodat niemand er een ongemerkt naar een laptop kopieert. Een opmerking boven de geheimensectie met de datum en de reden is genoeg, en die bespaart iemand later een ongemakkelijke beoordeling.