VPNSmith
Contabo-VPS
self-host-vpnINFO

WireGuard „Key is not the correct length or format“: Lösung

Ein WireGuard-Schlüssel besteht aus 32 Bytes, geschrieben als 44 Base64-Zeichen mit einem Gleichheitszeichen am Ende. Der Fehler bedeutet, dass das Eingefügte genau das nicht ist, und die Ursache ist fast immer unsichtbar: ein Zeilenumbruch am Ende, eine umgebrochene Zeile, ein Schlüssel samt Shell-Prompt oder ein Public Key an der Stelle eines Private Keys.

Von Eric Gerard · Gründer · VPNSmith - Spezialist für selbstgehostete VPNs & DSGVO-VPS5 Min. LesezeitFoto via Pexels

Du startest die Schnittstelle und wirst gestoppt, bevor irgendetwas eine Verbindung aufbaut:

Key is not the correct length or format

Der Schlüssel auf dem Bildschirm sieht gut aus. Genau das ist die ganze Schwierigkeit bei diesem Fehler: Was falsch ist, ist meistens ein Zeichen, das du nicht sehen kannst.

Was genau ein gültiger Schlüssel ist

Ein WireGuard-Schlüssel besteht aus 32 Bytes Rohdaten. In Base64 geschrieben sind 32 Bytes genau 44 Zeichen, und das letzte ist immer =, das Padding-Zeichen. Damit hast du einen Test, den du in einer Sekunde anwenden kannst, mit bloßem Auge oder per Befehl:

echo -n "$KEY" | wc -c

44 ohne Zeilenumbruch, 45, wenn der Zeilenumbruch noch dranhängt. Alles andere ist kein Schlüssel, egal wie es aussieht.

Dasselbe gilt für Private Keys, Public Keys und Preshared Keys, denn alle drei sind 32 Bytes lang. Das führt direkt zur Falle im letzten Abschnitt.

Ursache 1: ein unsichtbarer Zeilenumbruch am Ende

Die häufigste Einzelursache, und sie stammt aus einem Befehl, der völlig vernünftig aussieht:

PRIVATE_KEY=$(cat privatekey)

cat gibt die Datei einschließlich ihres abschließenden Zeilenumbruchs zurück. Die Command Substitution entfernt ihn hier zwar, aber derselbe Wert, der per Heredoc oder Editor-Makro in eine Konfiguration geschrieben wird, behält ihn oft. In wg0.conf landet dann ein Schlüssel mit einem überzähligen Zeichen dahinter, also ein 45-Byte-Wert, wo 44 verlangt waren.

Entferne ihn explizit, statt auf Glück zu hoffen:

tr -d '\n' < privatekey

Ursache 2: der Schlüssel über zwei Zeilen umgebrochen

Wenn du einen Schlüssel aus einem schmalen Terminalfenster, einer E-Mail oder einem Chat-Client kopierst, kann mitten darin ein Zeilenumbruch landen. In der Konfigurationsdatei endet der Wert dann nach etwa 30 Zeichen, und der Rest steht verwaist in einer eigenen Zeile.

Such danach mit einer Längenprüfung pro Zeile, statt zu lesen:

awk -F' = ' '/Key/ {print $1, length($2)}' /etc/wireguard/wg0.conf

Jede Schlüsselzeile sollte 44 ausgeben. Alles andere in dieser Liste ist dein Übeltäter, und das funktioniert auch bei einer Konfiguration mit einem Dutzend Peers, wo die Prüfung mit bloßem Auge versagt.

Ein weißes Papiermaßband, zu einer Schlaufe gerollt, auf schwarzem Hintergrund, mit den Zahlen 29 bis 45 und feiner Millimeterteilung dazwischen
Ein weißes Papiermaßband, zu einer Schlaufe gerollt, auf schwarzem Hintergrund, mit den Zahlen 29 bis 45 und feiner Millimeterteilung dazwischen

Ursache 3: der Schlüssel kam mit Begleitung

Ein Schlüssel, der in einem Schritt erzeugt und angezeigt wird, kann Dinge aus seiner Umgebung mitnehmen. Zwei Varianten davon:

  • Ein Shell-Prompt oder ein Befehlsecho, das beim Kopieren aus dem Scrollback-Puffer mit der Ausgabe erfasst wurde.
  • Ein führendes Leerzeichen, das Base64 nicht toleriert und das dir kein Editor anzeigt.

Bei einem frischen Schlüssel ist Neuerzeugen schneller als Spurensuche:

wg genkey > privatekey
chmod 600 privatekey
wg pubkey < privatekey > publickey

Die Umleitung in eine Datei, statt den Schlüssel vom Bildschirm abzulesen, beseitigt diese ganze Problemkategorie. Das chmod ist wichtig, weil ein für alle lesbarer Private Key ein eigenes Problem ist.

Wenn die Konfiguration selbst noch geschrieben wird, kannst du das Terminal für die Schlüssel ganz überspringen. Unser kostenloser WireGuard-Konfigurationsgenerator erzeugt die Schlüsselpaare in deinem Browser (Curve25519, nichts wird an einen Server gesendet) und schreibt sie direkt in das [Interface] des Servers, seine [Peer]-Blöcke und eine Client-Datei pro Gerät. Kein Schlüssel wandert dabei durch eine Zwischenablage, eine umgebrochene Terminalzeile oder einen Shell-Prompt, und jeder Schlüssel, den er schreibt, hat genau 44 Zeichen: Die awk-Prüfung oben gibt in jeder Zeile seiner Ausgabe 44 aus. Der Generator ist bis 10 Geräte kostenlos; darüber hinaus hebt WireGuard Pro (unser eigenes Produkt, einmalig 9 EUR, kein Abo) das Limit auf 250 an und liefert ein ZIP mit jeder Client-.conf und ihrem QR-Code als PNG, praktisch, um ein ganzes Büro oder eine ganze Familie in einem Rutsch einzurichten.

Ursache 4: die richtige Art Schlüssel im falschen Feld

Diese Ursache erzeugt den Fehler nicht, und genau deshalb gehört sie hierher. Auch ein Public Key besteht aus 44 Base64-Zeichen, sodass einer im Feld PrivateKey problemlos geparst wird und für immer still scheitert. Keine Meldung, keine Ablehnung, nur ein Handshake, der nie stattfindet.

Die Prüfung besteht darin, abzuleiten statt zu vergleichen:

wg pubkey < privatekey

Wenn die Ausgabe dem Wert in deinem Feld PrivateKey entspricht, hast du dort einen Public Key eingetragen. Ein Private Key, der durch wg pubkey läuft, ergibt etwas anderes als sich selbst; ein Public Key, der durch den Befehl läuft, ergibt Datenmüll oder einen Fehler, niemals den Ausgangswert.

Ein einzeiliger Check aller Schlüssel einer Konfiguration

Statt sie einzeln zu testen:

grep -oP '(?<= = )[A-Za-z0-9+/]{40,50}=' /etc/wireguard/wg0.conf | while read k; do
  printf '%s %s\n' "$(printf %s "$k" | wc -c)" "$k"
done

Jede Zeile sollte mit 44 beginnen. Eine Zahl, die nicht 44 ist, steht für einen kaputten Schlüssel, und du hast ihn gefunden, ohne ein einziges Base64-Zeichen zu lesen.

Damit du die Schlüsselbefehle griffbereit hast (wg genkey, wg pubkey < private.key, um zu prüfen, ob ein Private Key zum eingefügten Public Key passt, wg genpsk, wg show wg0 latest-handshakes), bringt unser kostenloses WireGuard Cheat Sheet sie auf eine druckbare A4-Seite, zusammen mit den Konfigurationsdirektiven und den Tabellen zu MTU und Ports. Zahl, was du willst, 0 USD akzeptiert. Cheat Sheet herunterladen.

Wo es als Nächstes hakt

Mit korrektem Format kommst du am Parser vorbei und landest bei der nächsten Problemklasse: einem Tunnel, der hochfährt und nichts tut. Ein Schlüssel, der zwar wohlgeformt, aber nicht der Schlüssel ist, den die Gegenseite erwartet, erzeugt einen ganz anderen Fehler, beschrieben unter dem Fehler „Required key not available“.

Zwei benachbarte Fälle solltest du von diesem trennen. Der Preshared Key ist ein dritter Schlüssel mit derselben 44-Zeichen-Form, aber symmetrischen Regeln, und landet deshalb leicht an der falschen Stelle: siehe den Leitfaden zum Preshared Key. Und derselbe Schlüssel auf zwei Geräten wird problemlos geparst und bricht auf scheinbar zufällige Weise, was eine eigene Geschichte ist, nachzulesen in zwei Geräte, ein Schlüssel (auf Englisch).

Wenn du Konfigurationen oft genug von Hand schreibst, um immer wieder hierauf zu stoßen, nehmen dir die Vorlagen in WireGuard-Konfigurationsvorlagen den Großteil des Abtippens ab. Wenn du den Server selbst von Grund auf aufbaust, starte auf einem KVM-VPS mit eigener öffentlicher IPv4, auf dem wg-quick auf einem Kernel läuft, den du kontrollierst: Ein Contabo Cloud VPS (Affiliate-Link) kostet 5.50 € im Monat bei 24 Monaten Laufzeit (abgelesen am 17. Oktober 2026), und Ultahost VPS Basic (Affiliate-Link) kostet 5.52 $ im Monat bei 24 Monaten Laufzeit, mit 1 GB RAM und 30 Tagen Geld-zurück-Garantie (abgelesen am 21. Oktober 2026).

★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200-Mbit/s-Port

Hoste dein VPN auf deinem eigenen VPS → ContaboVoller Root-Zugriff · öffentliche IPv4 · wähle deine Region→

Häufig gestellte Fragen

Wie lang muss ein WireGuard-Schlüssel sein?
Ein Schlüssel besteht aus 32 Bytes Rohdaten, die in Base64 genau 44 Zeichen ergeben. Das letzte davon ist ein Gleichheitszeichen, das als Padding dient. Alles, was kürzer oder länger ist oder kein abschließendes Gleichheitszeichen hat, wird abgelehnt, bevor der Tunnel überhaupt aufgebaut wird.
Warum sieht mein Schlüssel richtig aus und wird trotzdem abgelehnt?
Weil der Fehler meist aus Leerraum besteht, den du nicht siehst. Ein per Command Substitution erfasster Schlüssel behält seinen Zeilenumbruch am Ende, ein aus einem umbrechenden Terminal kopierter Schlüssel bekommt einen Zeilenumbruch in der Mitte, und beide sehen auf dem Bildschirm genauso aus wie ein korrekter Schlüssel.
Kann ich einen Public Key dort eintragen, wo ein Private Key hingehört?
Die Datei wird geparst, denn beide bestehen aus 44 Base64-Zeichen und sind strukturell nicht zu unterscheiden. Es kommt nur nie ein Handshake zustande, und das macht diese Variante des Fehlers zur schlimmsten: überhaupt keine Fehlermeldung, nur ein Tunnel, der stumm bleibt.
Sagt mir der Fehler, welcher Schlüssel falsch ist?
Nicht zuverlässig. wg meldet in manchen Versionen die Zeile, an der es hängen geblieben ist, in anderen nur den allgemeinen Fehler. Bei einer Konfiguration mit mehreren Peers ist es daher praktischer, jeden Schlüssel mit einer einzeiligen Schleife zu messen, statt sie mit bloßem Auge zu prüfen.
Wie prüfe ich einen Schlüssel, ohne ihn mit bloßem Auge zu kontrollieren?
Leite ihn an wc -c weiter und erwarte 45 für einen Schlüssel mit Zeilenumbruch oder 44 ohne. Noch besser: Gib ihn an wg pubkey. Ein gültiger Private Key erzeugt einen Public Key, ein ungültiger erzeugt denselben Längenfehler, und so wird die Prüfung zu einer klaren Ja-oder-Nein-Antwort.