nmcli vra aanhoudend om die VPN-wagwoord: stoor die geheim plaaslik

Dieselfde profiel, twee sessies: dit verbind vanaf die werkskerm en hang oor SSH by 'n opdrag wat niks kan antwoord nie. Niks is stukkend nie en geen instelling is verlore nie. NetworkManager vra 'n geheimeagent vir die aanmeldbewys, en 'n geheimeagent is 'n werkskermkomponent wat nie in die sessie bestaan wat jy gebruik nie.

Voer die volgorde hieronder uit en die tonnel kom sonder 'n koppelvlak op, met die voorbehoud dat die stoor van 'n geheim verander wie daardie profiel kan gebruik.

Bevestig die diagnose voordat jy iets wysig

Die verskil tussen interaktiewe en nie-interaktiewe aktivering is die hele diagnose. As nmcli --ask connection up slaag terwyl 'n gewone aktivering vasval, is die profiel korrek en die geheim se bron ontbreek. Daardie enkele vergelyking spaar jou daarvan om 'n werkende opset te herskryf.

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

Lees die vlae in plaas daarvan om te raai. Waardes wat "vra 'n agent" beteken, is waarna jy soek, en die presiese sleutelname verskil tussen VPN-inproppe omdat hulle in die inprop se eie datavoordeboek woon. 'n FortiSSL-profiel en 'n IPsec-profiel gebruik nie noodwendig dieselfde name nie, so werk uit die uitvoer van jou eie profiel.

Bevestig ook dat die inprop-pakket vir daardie protokol geïnstalleer is. 'n Ontbrekende inprop wys as 'n onbekende verbindingstipe of 'n aktiveringsfout wat niks oor wagwoorde sê nie, en om in daardie toestand die geheim te jaag mors dieselfde uur twee keer. Een pakketnavraag is goedkoper as 'n middag se sleutellêers wysig.

Skuif die geheim in die sleutellêer in

Die verbindingslêer woon onder /etc/NetworkManager/system-connections/. Geheime word nie by verstek daar gehou nie, en dit is die punt van die vlae wat jy pas gelees het. Om 'n vlag na nul te stel, sê vir NetworkManager die waarde word saam met die profiel gestoor in plaas daarvan om by aktivering aangevra te word.

[vpn]
password-flags=0

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

Vir 'n profiel met twee geheime herhaal die patroon hom: een vlag per geheim in die [vpn]-afdeling, en die waardes in [vpn-secrets]. 'n IPsec-profiel dra tipies 'n vooraf-gedeelde sleutel saam met die gebruikersaanmeldbewys, en die inprop noem hulle anders as 'n gewone wagwoordveld, so kopieer die sleutelname uit die vpn.data-uitvoer eerder as uit 'n blogpos wat 'n ander inprop gebruik het. Een verkeerde sleutelnaam lewer 'n profiel wat laai en dan by verifikasie misluk, wat presies soos 'n verkeerde wagwoord lees. Vergelyk jou lêer met 'n werkende profiel van dieselfde inprop voordat jy weer verbind.

Plaas aanhalingstekens om waardes wat spasies, aanhalingstekens of 'n dollar-teken bevat. 'n Waarde sonder aanhalingstekens met 'n $ daarin word letterlik gelees of uitgebrei na gelang van waar dit ontleed word, en die gevolglike verifikasiefout lyk soos 'n verkeerde wagwoord.

Maak dan die lêer se eienaarskap en modus reg. Hierdie sleutellêers word deur 'n bevoorregte diens gelees, en 'n lêer wat ander gebruikers kan lees, word as onbetroubaar beskou, wat die gewone rede is waarom 'n gewysigde profiel geïgnoreer word. Eienaar root, modus 600, geen uitsonderings nie.

Herlaai, aktiveer dan

Die lêer word gelees wanneer die verbinding gelaai word, so dit is nie genoeg om dit te wysig nie. Herlaai die profiele en bring die verbinding dan eksplisiet op.

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

As die herlaai nie die verandering optel nie, doen 'n volledige herbegin van die diens dit, en daar is verslae van presies dit. Verkies die herlaai wanneer ander skakels saak maak, want om die diens te herbegin laat elke bestuurde verbinding spring, en op 'n afgeleë gasheer kan dit jou sessie beëindig voordat die tonnel wat jy wou hê, op is.

Gebruik die UUID wanneer name dubbelsinnig is. Masjiene met verskeie klantprofiele versamel byna-duplikate, en die aktivering van die verkeerde een lewer 'n fout wat soos 'n aanmeldbewysprobleem lyk.

Wanneer die gestoorde geheim nie die probleem is nie

'n FortiSSL-profiel kan misluk selfs met 'n korrekte gestoorde aanmeldbewys, omdat die kliënt nooit die poort se sertifikaat vertrou nie. Daardie instelling is nie op die hoofdialoog nie; dit sit agter die gevorderde opsies vir die VPN, waar die vertroude sertifikaat-verdigting ingevoer word. As die log die sertifikaat noem eerder as die wagwoord, is jy in hierdie tak en geen wysiging van [vpn-secrets] sal help nie.

Nog twee kontroles hoort hier. Bevestig dat die profiel nie ingevoer is uit 'n lêer wat nog na 'n pad wys wat die inprop nie kan lees nie, en bevestig dat die profiel die aktiewe een is eerder as 'n verouderde duplikaat. Albei lewer aktiveringsfoute wat soos verifikasiefoute lees.

Besluit of stoor aanvaarbaar is

'n Gestoorde PSK en wagwoord is leesbaar deur enigiets wat as root op daardie masjien loop. Op 'n blok wat jy beheer, is dit 'n redelike ruil vir 'n koplose diens. Op 'n gedeelde gasheer verdien dit 'n gesprek, want die profiel bevat nou 'n aanmeldbewys wat voorheen deur die werkskerm se sleutelring beskerm is. Vra wie anders root op daardie gasheer kan bereik voordat jy besluit, nie nadat die verandering in plek is nie.

As beleid gestoorde VPN-geheime verbied, moenie die profiel verswak om 'n cron-taak te laat werk nie. Voer die verbinding uit vanaf 'n sessie met 'n agent, of gebruik 'n ander meganisme vir die outomatisering.

Laastens, teken aan watter profiele geheime dra sodat niemand een na 'n skootrekenaar kopieer sonder om dit raak te sien nie. 'n Opmerking bo die geheime-afdeling met die datum en die rede is genoeg, en dit sal iemand later 'n ongemaklike hersiening spaar.