WireGuard meldt dat de lengte van de privésleutel onjuist is: wat nu?

Het bericht zegt dat de privésleutel de verkeerde lengte heeft, en die formulering wijst eerst op de codering en pas daarna op de cryptografie. WireGuard-sleutels coderen 32 bytes als base64, wat 44 tekens oplevert inclusief een sluitende opvulling, dus een waarde van een andere grootte is geen sleutel hoe willekeurig hij er ook uitziet. De tekenreeks opvullen tot de parser hem accepteert, levert een correct gevormde waarde op die geen enkele peer ooit zal herkennen.

Achter deze fout schuilen twee verschillende taken: de tekst van een geldige sleutel repareren, en een identiteit vervangen die u niet meer bezit. Ze hebben verschillende gevolgen, en een van beide maakt het andere uiteinde ongeldig.

Wat de parser verwacht

Een WireGuard-sleutel is 32 bytes sleutelmateriaal in base64 met standaardopvulling, wat een vaste tekenreeks van 44 tekens geeft. De hulpprogramma’s weigeren alles wat niet precies naar 32 bytes decodeert, omdat de onderliggende kromme een scalair van 32 bytes neemt en niets anders. Openbare en privéwaarden gebruiken dezelfde codering, dus de parser kan alleen aan het formaat niet zien welke van de twee u hebt geplakt. Die dubbelzinnigheid veroorzaakt de helft van de verwarring rond deze fout.

wg genkey | tee private.key | wg pubkey > public.key
base64 -d private.key | wc -c
wc -c private.key
wg show wg0 public-key

Als uw waarde naar 32 bytes decodeert, is de lengte in orde en komt de klacht van een andere plek in het bestand. Als hij naar iets korter decodeert, hebt u afgekapt materiaal en geen opmaakprobleem.

Opmaakschade of verkeerd materiaal?

Opmaakschade hoopt zich op aan de randen: aanhalingstekens die een shell toevoegde, een label zoals private_key dat met de waarde werd gekopieerd, een regeleinde van een chatclient, of een sluitende spatie die het plakken overleefde. Elk van die wijzigingen verandert de tekenreeks zonder de bytes te veranderen, dus verwijderen herstelt de oorspronkelijke identiteit. Vergelijk het bestand teken voor teken met het inrichtingsregister in plaats van leestekens te strippen tot de parser zwijgt.

Verkeerd materiaal is een andere situatie. Een wachtwoord, een certificaatsleutel of een openbare waarde kunnen allemaal plausibel lijken en naar de verkeerde grootte decoderen. Geen enkele opschoning maakt er de scalair van die de peer verwacht. Dat geval vraagt een nieuwe identiteit in plaats van een bewerking.

Een openbare sleutel in het privével

De meest voorkomende verwarring is een openbare waarde die in het privével is geplakt, of omgekeerd. Beide zijn geldige base64 van 32 bytes, dus de lengtecontrole slaagt en de handshake mislukt later zonder bruikbare melding. Een privésleutel is de scalair die de openbare oplevert, dus u kunt het beslechten door de openbare waarde af te leiden en die te vergelijken met wat de peer autoriseert. Als de afgeleide waarde niet met het register overeenkomt, hebt u de verkeerde identiteit en geen typefout.

De privésleutel van de client vervangen zonder de geautoriseerde openbare sleutel aan de andere kant bij te werken, maakt dezelfde mismatch opnieuw, met de extra verwarring dat het bestand van de client nu met zichzelf consistent lijkt. Wijzig beide uiteinden in één handeling, anders onderzoekt de volgende persoon de verkeerde helft.

Repareer het profiel en bewijs daarna de handshake

Zodra de sleutel naar de juiste grootte decodeert en bij het geautoriseerde paar past, blijven het profiel en het pad over. De onderstaande opdrachten genereren zo nodig een vers paar, controleren de gedecodeerde grootte van een bestaande sleutel en lezen de openbare waarde die de interface werkelijk gebruikt. Plak nooit een privéwaarde in een ticket of op een decoderingssite.

wg genkey | tee new.key | wg pubkey > new.pub
base64 -d private.key | wc -c
ip route get 10.60.9.5
wg show wg0 latest-handshakes

De groottecontrole beantwoordt of het materiaal sleutelvormig is, en de routevraag beantwoordt of een pakket de interface ooit zou bereiken. Een handshake-regel die leeg blijft nadat beide controles slagen, verplaatst de diagnose naar het eindpunt van de peer en de toegestane adressen. Lees de openbare sleutel van de interface nog één keer tegen het inrichtingsregister, omdat een verouderd opgeslagen profiel correct kan lijken terwijl het actieve afwijkt].

Noteer welke waarde u hebt vervangen en waar de geautoriseerde kopie staat. Wie deze peer hierna aanraakt, moet weten welk uiteinde is gewijzigd.