Ugyldig hemmelighet er et containerproblem, ikke en passordregel
Samme passord leveres gjennom et grafisk felt og en legitimasjonsfil, og feiler på ulike steder. Sammenlign beholderne før du forenkler et passord som var riktig hele tiden.
Å se «ugyldig hemmelighet» gir vanligvis én konklusjon: VPN-en liker ikke tegnsetting. Den konklusjonen er vanligvis feil, fordi meldingen ofte kommer fra lokal håndtering før noen gateway har sett på kontoen. To design leverer samme passord, et grafisk felt og en legitimasjonsfil, og de feiler på forskjellige steder. Sammenlign beholderne før du forenkler et passord som var riktig hele tiden.
Feilen kommer før gatewayen
Lokal validering, et låst hemmelighetslager, en manglende agent og en feilformet legitimasjonsfil gir alle feil som brukeren opplever som én avvisning. Ingen av dem involverer autentiseringsserveren. Gatewayens egen avvisning er en egen hendelse, og den kommer vanligvis med en annen melding og en annen timing. Den skjer etter at en tunnel finnes og legitimasjonen er sendt.
Så det første spørsmålet er ikke hvilke tegn som er lovlige, men hvor forsøket stoppet. En klient som aldri åpnet en tilkobling, er ikke avvist av noen. Skriv ned stadiet du observerte, fordi hvert senere steg avhenger av den klassifiseringen.
Skillen endrer også hvem som fikser det. Et beholderproblem tilhører enheten og eieren, mens en kontoavvisning tilhører den som driver autentiseringsbackend.
Sammenlign beholderne, ikke tegnene
Et passordfelt i et grafisk grensesnitt, en nøkkelringoppføring, en legitimasjonsfil med to linjer og en automasjonshemmelighet bærer hver samme verdi i en annen konvolutt. Konvolutten har sine egne regler, og det er de reglene som vanligvis bryter. Verdien er sjelden problemet; transporten av verdien er det. Hold de to ideene fra hverandre, så blir diagnosen kortere.
| Hvor verdien stopper | Det du ser | Det du sjekker | Hvem som eier rettelsen |
|---|---|---|---|
| Grafisk felt eller administrert profil | En valideringsmelding før noen tilkobling åpnes | Den valgte autentiseringsmodusen og om feltet inneholder hemmeligheten eller brukernavnet | Enhetseieren eller profilforfatteren |
| Nøkkelring eller hemmelighetsagent | En forespørsel som stadig kommer tilbake, eller en agentfeil | Om agenten er låst opp og har en oppføring for denne profilen | Brukeren som eier nøkkelringen |
| Legitimasjonsfil med to linjer | En forespørsel om et passord som allerede er oppgitt | Linjeantall, linjerekkefølge og om det finnes en avsluttende ny linje | Den som genererte filen |
| Skallargument eller miljø | Fungerer interaktivt, men feiler i automatisering | Om skallet utvidet, trimmet eller logget verdien | Den som skrev automatiseringen |
Community OpenVPN 2.6-klientalternativer beskriver den tolinjers filen for auth-user-pass, inkludert oppførselen når passordlinjen mangler: klienten spør i stedet. Den ene detaljen forklarer en klasse av rapporter om at den spør etter et passord som allerede er oppgitt. Den forteller deg også at en tom andre linje er en meningsfull tilstand og ikke et ufarlig formateringsvalg.
Sitering er nok et eget lag: anførselstegn inne i en vanlig legitimasjonsfil lagres som data, mens et skall fjerner dem før programmet ser noe. Samme tegn er ufarlig på ett sted og strukturelt på et annet. En tabell kan ikke fortelle deg hvilken beholder klienten brukte, så les klientens egen konfigurasjon før du velger en rad.
Linjeskift er også strukturelle. En fil med linjedelte felt kan ikke bære en verdi som inneholder en ny linje, og det er en begrensning i formatet, ikke en vurdering av passordstyrke. Bruk distribusjonens støttede leveringsmekanisme i stedet for å trimme hemmeligheten for å passe en improvisert fil.
Bygg legitimasjonsfilen uten skallskade
Den tryggeste lokale veien holder hemmeligheten ute av skallhistorikken og ute av argumentlisten til prosessen. Les begge feltene interaktivt, og skriv deretter de to linjene klienten forventer. Alt annet kan bli i en konfigurasjonsfil som er lett å gjennomgå.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsDe to første kommandoene leser brukernavnet og deretter passordet uten å ekkoe det, den tredje skriver begge linjene, den fjerde begrenser filen, og den siste starter klienten med den filen. Legg merke til at read -r bevarer omvendte skråstreker, som er nettopp den typen detalj som gjør et fungerende passord til et feilende når den utelates.
Unngå å bygge filen med en variabel uten anførselstegn eller et innlimingsdokument fullt av skallutvidelser. Begge kan forvandle tegn før de når filen, og den resulterende feilen ser ut som en VPN-avvisning fordi passordet på disk faktisk er forskjellig fra passordet du kjenner. Sammenlign filens bytelengde med forventet verdi hvis du mistenker dette, uten å skrive ut hemmeligheten selv. Et avvik på én eller to byte er signaturen til en siteringsulykke.
Les stadiet fra den første feilen
Ta vare på den første konkrete meldingen fra ett forsøk, og klassifiser den. En lokal valideringsfeil, en manglende privat nøkkel, en utilgjengelig hemmelighetsagent og en autentiseringsfeil fra gatewayen er fire forskjellige resultater med fire forskjellige eiere. Bare én av dem handler om kontoen.
Hvis gatewayen virkelig avviser en korrekt levert legitimasjon, sjekk kontoen, autentiseringsbackend og eventuell påkrevd utfordring med administratoren. En generisk autentiseringsfeil nevner ikke et forbudt tegn.
Gjenopprett den godkjente verdien gjennom riktig mekanisme i stedet for å redusere den til bokstaver og sifre. Passordpolicyen tilhører operatøren, og en omvei som stille omgår den er ikke en rettelse. Den skjuler også den virkelige feilen for neste person, som vil møte samme feil med et svakere passord og ingen bedre idé.