Clé pré-partagée WireGuard : son vrai rôle, pas un mot de passe

Chaque pair WireGuard possède déjà une paire de clés, donc la première question raisonnable sur PresharedKey est : qu'est-ce qu'une troisième clé est censée apporter ?

La réponse est étroite et précise, et elle mérite d'être formulée exactement, parce que les deux descriptions courantes sont fausses toutes les deux.

Ce qu'elle n'est pas

Ce n'est pas un mot de passe sur le tunnel. On l'ajoute en s'attendant à ce que la connexion exige un secret, comme SSH exige une passphrase. Ce n'est pas comme ça qu'elle fonctionne.

Elle ne remplace rien. Ajouter une clé pré-partagée ne permet pas d'utiliser des clés plus faibles, de sauter des règles de pare-feu, ni d'exposer le port plus sereinement.

Ce qu'elle est

Le handshake de WireGuard dérive les clés de session à partir des clés publiques et privées des deux pairs. Si une clé pré-partagée est configurée, elle est mélangée à cette dérivation comme entrée supplémentaire.

Toute la valeur est dans la conséquence : la clé pré-partagée est symétrique et n'est jamais envoyée sur le réseau. Un attaquant qui enregistre aujourd'hui chaque paquet de ton trafic, et qui acquiert plus tard la capacité de casser l'échange à courbe elliptique, ne peut toujours pas dériver les clés de session, parce qu'une des entrées n'a jamais traversé le réseau.

La documentation de WireGuard parle de résistance post-quantique, et la formule est juste tant que tu gardes le modèle de menace en tête. L'adversaire visé est celui qui stocke le trafic maintenant et le déchiffre plus tard. Si personne n'enregistre ton tunnel, elle ne protège contre rien, et elle ne coûte quand même presque rien à ajouter.

La générer et l'installer

wg genpsk

La commande affiche une clé de 32 octets encodée en base64. Pour la générer et la stocker en une seule étape :

wg genpsk > peer1.psk
chmod 600 peer1.psk

Elle se place dans la section [Peer], sur les deux machines, avec la même valeur :

[Peer]
PublicKey = <the other side's public key>
PresharedKey = <the same value on both ends>
AllowedIPs = 10.10.0.2/32

Une clé pré-partagée par paire de pairs, pas une par serveur. Réutiliser une seule valeur pour tous les clients revient à donner à chacun d'eux la clé qui protège tous les autres.

Si tu as construit tes fichiers avec notre générateur de config WireGuard, sache ce qu'il fait et ne fait pas ici : il génère les paires de clés dans ton navigateur et écrit l'[Interface] du serveur, les blocs [Peer] et un fichier client par appareil, mais il n'émet pas de ligne PresharedKey. Lance wg genpsk une fois par client et colle la même valeur dans le bloc [Peer] de ce client aux deux extrémités avant de lui remettre le fichier, et les configs sont complètes. Le générateur est gratuit jusqu'à 10 appareils ; au-delà, WireGuard Pro (notre propre produit, 9 EUR une fois, sans abonnement) relève la limite à 250 et ajoute un ZIP unique avec chaque .conf client et son QR code en PNG, pratique pour équiper tout un bureau ou toute une famille d'un coup.

L'ajouter à un tunnel en service sans s'enfermer dehors

C'est là que beaucoup se font piéger. Une clé pré-partagée qui ne correspond que d'un côté signifie que le handshake cesse d'aboutir, et WireGuard ne te dit pas pourquoi. wg show n'indique aucun handshake récent, exactement la même sortie qu'avec un mauvais port, un paquet rejeté par le pare-feu ou une clé publique erronée.

Si le tunnel est ta seule voie d'accès à un serveur distant, c'est le verrouillage assuré.

L'ordre sûr :

1. Génère la clé et place-la d'abord sur les deux machines, sans modifier aucune des deux configs.
2. Si tu as un accès hors bande (une console ou de l'IPMI), utilise-le et modifie les deux côtés.
3. Sinon, programme un retour arrière. Quelque chose comme echo "wg-quick down wg0 && wg-quick up wg0" | at now + 10 minutes avec la config d'origine sur le disque, pour qu'une erreur se corrige d'elle-même tant que tu as encore un moyen d'entrer.
4. Modifie le côté distant, puis le côté local, puis confirme avec wg show qu'un handshake a eu lieu dans les deux dernières minutes.

Le symptôme général, un tunnel qui fonctionnait et qui n'affiche plus de handshake, est traité dans le dépannage du handshake. Ajoute « un côté a une clé pré-partagée et l'autre non » à cette liste.

La place des clés pré-partagées par rapport au reste

Elles ne changent rien à la visibilité du tunnel. Un réseau qui bloque WireGuard d'après la forme de son trafic le bloque tout autant. C'est un autre problème, avec d'autres réponses : voir contourner le DPI avec un VPN.

Elles ne changent rien à qui peut atteindre le port. Masquer le point d'accès est une technique distincte, traitée dans port knocking et furtivité.

Elles doivent être traitées comme du matériel cryptographique. Pas dans un message de chat, pas dans un document partagé, pas commitées dans un dépôt. Une clé pré-partagée dans un historique git est pire que pas de clé pré-partagée du tout, parce qu'elle donne une confiance qui ne repose sur rien.

Si tu construis le côté serveur de zéro, le guide complet se trouve dans auto-héberger WireGuard sur un VPS, et l'ajout de clients par la suite est traité dans ajouter un pair WireGuard. S'il te manque encore la machine, ce guide est écrit sur un VPS Cloud Contabo (lien affilié).

Si tu préfères un hébergeur américain avec une garantie satisfait ou remboursé de 30 jours, Ultahost VPS Basic coûte 5,52 $ par mois sur un engagement de 24 mois (1 Go de RAM, IPv4 dédiée, relevé le 21 octobre 2026), assez pour un serveur WireGuard desservant quelques appareils.