WireGuard meldet eine falsche Länge des privaten Schlüssels: Was nun?

Ein Schlüssel aus 32 Byte hat in base64 44 Zeichen. Entscheiden Sie, ob der Text beschädigt ist oder die falsche Identität vorliegt, bevor Sie etwas neu erzeugen.

Die Meldung besagt, dass der private Schlüssel die falsche Länge hat, und diese Formulierung deutet zuerst auf die Kodierung und erst danach auf die Kryptografie hin. WireGuard-Schlüssel kodieren 32 Byte als base64, was 44 Zeichen einschließlich eines abschließenden Füllzeichens ergibt; ein Wert anderer Größe ist also kein Schlüssel, so zufällig er auch aussehen mag. Füllt man die Zeichenkette auf, bis der Parser sie akzeptiert, entsteht ein wohlgeformter Wert, den kein Peer jemals wiedererkennt.

Hinter diesem Fehler stecken zwei verschiedene Aufgaben: den Text eines gültigen Schlüssels zu reparieren und eine Identität zu ersetzen, die Sie nicht mehr besitzen. Beide haben unterschiedliche Folgen, und eine davon macht das andere Ende ungültig.

Was der Parser erwartet

Ein WireGuard-Schlüssel besteht aus 32 Byte Schlüsselmaterial in base64 mit Standardauffüllung, was eine feste Zeichenkette von 44 Zeichen ergibt. Die Werkzeuge lehnen alles ab, was sich nicht auf genau 32 Byte dekodieren lässt, denn die zugrunde liegende Kurve nimmt einen 32-Byte-Skalar und sonst nichts. Öffentliche und private Werte verwenden dieselbe Kodierung, weshalb der Parser allein am Format nicht erkennen kann, welchen der beiden Sie eingefügt haben. Diese Mehrdeutigkeit verursacht die Hälfte der Verwirrung um diesen Fehler.

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

Wenn sich Ihr Wert auf 32 Byte dekodieren lässt, stimmt die Länge, und die Beschwerde kommt von einer anderen Stelle in der Datei. Ergibt die Dekodierung etwas Kürzeres, haben Sie abgeschnittenes Material und kein Formatierungsproblem.

Formatierungsschaden oder falsches Material?

Formatierungsschäden treten gehäuft an den Rändern auf: Anführungszeichen, die eine Shell hinzugefügt hat, eine Bezeichnung wie private_key, die zusammen mit dem Wert kopiert wurde, ein Zeilenumbruch aus einem Chat-Client oder ein abschließendes Leerzeichen, das das Einfügen überlebt hat. Jede dieser Änderungen verändert die Zeichenkette, ohne die Bytes zu verändern, sodass das Entfernen die ursprüngliche Identität wiederherstellt. Vergleichen Sie die Datei Zeichen für Zeichen mit dem Bereitstellungsprotokoll, statt Satzzeichen zu entfernen, bis der Parser still wird.

Falsches Material ist eine andere Situation. Ein Passwort, ein Zertifikatsschlüssel oder ein öffentlicher Wert können alle plausibel aussehen und sich auf die falsche Größe dekodieren. Keine noch so gründliche Bereinigung macht aus einem von ihnen den Skalar, den der Peer erwartet. Dieser Fall braucht eine neue Identität statt einer Bearbeitung.

Ein öffentlicher Schlüssel im privaten Feld

Die häufigste Verwechslung ist ein öffentlicher Wert, der in das private Feld eingefügt wurde, oder umgekehrt. Beide sind gültiges base64 mit 32 Byte, also besteht die Längenprüfung, und der Handshake scheitert später ohne brauchbare Meldung. Ein privater Schlüssel ist der Skalar, der den öffentlichen erzeugt; Sie können die Frage also klären, indem Sie den öffentlichen Wert ableiten und mit dem vergleichen, was der Peer autorisiert. Passt der abgeleitete Wert nicht zum Eintrag, haben Sie die falsche Identität und keinen Tippfehler.

Wenn Sie den privaten Schlüssel des Clients ersetzen, ohne den autorisierten öffentlichen Schlüssel am anderen Ende zu aktualisieren, entsteht dieselbe Nichtübereinstimmung erneut, mit der zusätzlichen Verwirrung, dass die Datei des Clients nun in sich stimmig aussieht. Ändern Sie beide Enden in einem Vorgang, sonst sucht die nächste Person in der falschen Hälfte.

Profil reparieren, dann den Handshake belegen

Sobald sich der Schlüssel auf die richtige Größe dekodieren lässt und zum autorisierten Paar passt, bleiben das Profil und der Pfad zu erledigen. Die folgenden Befehle erzeugen bei Bedarf ein frisches Paar, prüfen die dekodierte Größe eines vorhandenen Schlüssels und lesen den öffentlichen Wert, den die Schnittstelle tatsächlich verwendet. Fügen Sie einen privaten Wert niemals in ein Ticket oder eine Decoder-Website ein.

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

Die Größenprüfung beantwortet, ob das Material schlüsselförmig ist, und die Routenabfrage beantwortet, ob ein Paket die Schnittstelle überhaupt erreichen würde. Bleibt eine Handshake-Zeile leer, obwohl beide Prüfungen bestehen, verschiebt sich die Diagnose auf den Endpunkt des Peers und die erlaubten Adressen. Lesen Sie den öffentlichen Schlüssel der Schnittstelle ein letztes Mal gegen das Bereitstellungsprotokoll, denn ein veraltetes gespeichertes Profil kann korrekt aussehen, während das aktive abweicht].

Notieren Sie, welchen Wert Sie ersetzt haben und wo die autorisierte Kopie liegt. Wer diesen Peer als Nächstes anfasst, muss wissen, welches Ende sich geändert hat.

Ähnliche Artikel