Neplatné tajné údaje jsou problém kontejneru, ne pravidlo pro heslo
Odmítnutý údaj se možná nikdy nedostal k bráně. Nejprve porovnejte vstupní kontejner, fázi ověřování a samotný účet.
Hlášení „neplatné tajné údaje“ obvykle vede k jednomu závěru: VPN nemá ráda interpunkci. Ten závěr bývá chybný, protože zpráva často pochází z místního zpracování dřív, než se nějaká brána podívala na účet. Dva návrhy předávají stejné heslo, grafické pole a soubor s přihlašovacími údaji, a selhávají na různých místech. Porovnejte kontejnery, než zjednodušíte heslo, které bylo celou dobu v pořádku.
Chyba přichází dřív než brána
Místní validace, uzamčené úložiště tajných údajů, chybějící agent a poškozený soubor s přihlašovacími údaji — to vše vytváří selhání, která uživatel prožívá jako jedno odmítnutí. Ani jedno z nich nezahrnuje ověřovací server. Vlastní odmítnutí brány je samostatná událost a obvykle přichází s jinou zprávou a v jinou dobu. Nastává poté, co existuje tunel a údaje byly přeneseny.
První otázka tedy není, které znaky jsou povolené, ale kde se pokus zastavil. Klient, který nikdy neotevřel spojení, nebyl nikým odmítnut. Zapište fázi, kterou jste pozorovali, protože každý další krok závisí na této klasifikaci.
Rozlišení také mění, kdo to opraví. Problém kontejneru patří zařízení a jeho vlastníkovi, zatímco odmítnutí účtu patří tomu, kdo provozuje ověřovací backend.
Porovnávejte kontejnery, ne znaky
Grafické pole pro heslo, záznam v klíčence, dvouřádkový soubor s přihlašovacími údaji a tajný údaj pro automatizaci — každý nese stejnou hodnotu v jiné obálce. Obálka má svá pravidla a obvykle se lámou právě ta. Hodnota je málokdy problém; přenos hodnoty je. Držte obě myšlenky oddělené a diagnóza se zkrátí.
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
Klientské volby komunity OpenVPN 2.6 popisují tento dvouřádkový soubor pro auth-user-pass, včetně chování, když řádek s heslem chybí: klient se tehdy zeptá sám. Tento jediný detail vysvětluje celou třídu hlášení typu „ptá se na heslo, které jsem už zadal“. Také vám říká, že prázdný druhý řádek je významný stav, nikoli neškodná volba formátování.
Uvozovky jsou opět samostatná vrstva: uvozovky uvnitř běžného souboru s údaji se ukládají jako data, zatímco shell je odstraní dřív, než program cokoli uvidí. Stejný znak je na jednom místě neškodný a na jiném strukturní. Tabulka vám neřekne, který kontejner váš klient použil, proto si přečtěte vlastní konfiguraci klienta, než vyberete řádek.
Zalomení řádků jsou také strukturní. Soubor s poli oddělenými řádky nemůže nést hodnotu obsahující nový řádek, a to je omezení formátu, ne soud o síle hesla. Použijte mechanismus doručení podporovaný nasazením, místo abyste tajný údaj zkracovali, aby se vešel do improvizovaného souboru.
Vytvořte soubor s údaji bez poškození shellem
Nejbezpečnější místní cesta drží tajný údaj mimo historii shellu a mimo seznam argumentů procesu. Přečtěte obě pole interaktivně a potom zapište dva řádky, které klient očekává. Vše ostatní může zůstat v konfiguračním souboru, který se snadno kontroluje.
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/credsPrvní dva příkazy přečtou uživatelské jméno a potom heslo bez zobrazení, třetí zapíše oba řádky, čtvrtý omezí soubor a poslední spustí klienta s tímto souborem. Všimněte si, že read -r zachovává zpětná lomítka, a to je přesně ten druh detailu, který změní fungující heslo v nefunkční, když se vynechá.
Vyhněte se vytváření souboru pomocí proměnné bez uvozovek nebo here-dokumentu plného expanzí shellu. Obojí může změnit znaky dřív, než se dostanou do souboru, a výsledné selhání vypadá jako odmítnutí VPN, protože heslo na disku je skutečně jiné než heslo, které znáte. Pokud to tušíte, porovnejte délku souboru v bajtech s očekávanou hodnotou, aniž byste tajný údaj vypsali. Rozdíl jednoho nebo dvou bajtů je podpis nehody s uvozovkami.
Přečtěte fázi z první chyby
Uchovejte první konkrétní zprávu z jednoho pokusu a pak ji klasifikujte. Chyba místní validace, chybějící soukromý klíč, nedostupný agent pro tajné údaje a selhání ověření na bráně jsou čtyři různé výsledky se čtyřmi různými vlastníky. Jen jeden z nich se týká účtu.
Pokud brána skutečně odmítá správně předaný údaj, prověřte účet, ověřovací backend a případnou požadovanou výzvu se správcem. Obecné selhání ověření neuvádí zakázaný znak.
Obnovte schválenou hodnotu správným mechanismem, místo abyste ji redukovali na písmena a číslice. Zásady hesel patří provozovateli a obchvat, který je tiše obchází, není oprava. Také skrývá skutečnou vadu před dalším člověkem, který narazí na stejnou chybu se slabším heslem a bez lepšího nápadu.