Clés SSH sous WSL : configuration sécurisée (et comment ne pas les divulguer)

WSL + clés SSH : le modèle mental qui prévient les fuites

Considérez WSL comme une machine Linux avec un dossier partagé très permissif monté dedans (généralement /mnt/c et consorts). Votre répertoire home Linux dans WSL n’est pas Windows, mais ce n’est pas non plus un ordinateur physique séparé dont vous pouvez vous désintéresser. C’est un système de fichiers à l’intérieur d’une image de distribution, plus beaucoup de colle d’intégration.

Les clés SSH ne sont que des fichiers. C’est tout le problème. Si elles existent en tant que bytes sur disque, elles peuvent être copiées, indexées, sauvegardées, scannées par des malwares, « synchronisées » à votre insu, ou commises par accident. Votre travail n’est donc pas de « configurer SSH ». Votre travail est de contrôler quel système de fichiers contient les clés, qui peut les lire, comment elles sont déverrouillées et ce que vous enregistrez lors du dépannage.

Règles de conduite (opinionnées, parce que vous avez demandé du niveau production)

• Générez les clés à l’intérieur du système de fichiers Linux de WSL (le /home de votre distro), pas sur /mnt/c. Gardez la clé privée à l’écart des outils de synchronisation Windows par défaut.
• Utilisez des phrases de passe. Si vous y êtes allergique, utilisez des clés protégées par matériel ou un agent avec un TTL court — pas « sans phrase de passe ».
• Ne partagez pas une clé unique partout. Une clé par frontière d’identité : personnelle, entreprise, CI, procédure d’urgence prod, etc.
• Épinglez les clés d’hôte et traitez known_hosts comme une partie de la sécurité, pas comme du désordre. Votre futur vous remerciera la première fois que le DNS mentira.
• Rendez l’agent explicite. Les redémarrages de session WSL sont courants ; vous voulez un comportement prévisible, pas des invites aléatoires et des retours silencieux.
• Auditez avec des commandes, pas avec des impressions. « Ça devrait fonctionner » est la façon dont naissent les pannes.

Faits intéressants et contexte historique (court, utile)

1. SSH a remplacé rsh/rlogin dans les années 1990 parce que les shells distants en clair étaient une vraie aubaine pour les sniffers de paquets.
2. RSA a été l’algorithme public par défaut pendant des années, mais les choix par défaut modernes tendent vers Ed25519 pour sa vitesse et ses paramètres plus sûrs.
3. OpenSSH a ajouté le support des clés FIDO/U2F (comme sk-ssh-ed25519@openssh.com) pour réduire le risque d’exfiltration de clés.
4. ssh-agent existe parce que les phrases de passe sont bonnes, mais les taper 40 fois par jour est la façon dont les gens « résolvent » la sécurité en la désactivant.
5. Le fichier known_hosts est la couche anti-phishing de SSH : c’est ainsi que SSH détecte les changements MITM sans avoir besoin d’une PKI globale pour les hôtes.
6. WSL1 et WSL2 diffèrent fortement au niveau réseau : WSL2 exécute une VM légère avec NAT, ce qui peut affecter le forwarding d’agent et le dépannage du « pourquoi localhost se comporte bizarrement ».
7. Les permissions Windows ne se mappent pas proprement sur les permissions POSIX sur /mnt/c ; ce désalignement est la raison pour laquelle SSH se plaint de « permissions trop ouvertes ».
8. GitHub a cessé d’accepter certaines signatures faibles SHA-1 pour certains flux ; de la même manière, les écosystèmes SSH poussent progressivement les utilisateurs hors des anciens algorithmes.

Modèle de menace : comment les clés fuient dans la vraie vie

La plupart des fuites de clés SSH sont opérationnelles, pas cinématographiques. Voici les suspects habituels dans les environnements WSL :

1) Un fichier finit sur Windows sans que vous le remarquiez

Peut-être vous avez copié ~/.ssh dans un répertoire Windows pour « l’utiliser dans VS Code ». Peut-être un dépôt de dotfiles contient un lien symbolique qui se résout vers /mnt/c. Peut-être vous avez édité des fichiers sous /mnt/c parce que c’était pratique. Les indexeurs de recherche Windows, les clients de synchronisation cloud, le DLP d’entreprise et les outils de sécurité d’endpoint peuvent maintenant voir vos secrets.

2) Sauvegardes et exports

Les exports de distro WSL (wsl --export) produisent une tarball du système de fichiers de la distro. Cette tarball contient vos clés privées à moins que vous ne les excluiez. C’est une « sauvegarde » pratique, et aussi un chemin de fuite très portable.

3) Logs de debug et pastebins (la catastrophe silencieuse)

La sortie de debug SSH est en grande partie sûre, mais votre historique de shell, des commandes copiées et des scripts de dépannage « rapides » peuvent afficher des chemins sensibles, des emplacements de sockets d’agent et parfois du matériel de clé si vous n’êtes pas prudent. Les gens collent tout ~/.ssh/config dans des tickets. Puis le système de ticket devient votre gestionnaire de secrets. Brillant.

4) Mauvaise clé utilisée au mauvais endroit

Il est facile d’utiliser accidentellement votre « clé universelle » contre le mauvais hôte, surtout si vous comptez sur des identités chargées dans l’agent et que vous ne contrôlez pas IdentitiesOnly. C’est comme ça que des clés se retrouvent autorisées sur des systèmes auxquels elles n’étaient pas destinées.

5) Contournement des clés d’hôte « parce que c’est ennuyeux »

Désactiver la vérification stricte des clés d’hôte pour « réparer le CI » ou « faciliter le bootstrap » est un classique tirage de balle dans le pied. Vous ne divulguez peut‑être pas la clé privée, mais vous facilitez énormément la capture d’identifiants et les MITM.

Configuration sécurisée : générer, stocker et utiliser des clés dans WSL

Décidez où vit la clé privée (choisissez une option)

• Meilleur choix par défaut : les clés privées restent dans le système de fichiers Linux de WSL sous /home/<user>/.ssh. Windows ne peut y accéder que si vous les copiez délibérément.
• Mieux pour une forte assurance : clés protégées par matériel (FIDO2/YubiKey) de sorte qu’il n’y ait pas de clé privée exportable sur le disque.
• Parfois acceptable : clés stockées sur Windows avec un agent natif Windows, puis utilisées depuis WSL via un pont. Cela peut convenir en environnements d’entreprise où Windows est fortement géré et Linux ne l’est pas. Mais cela augmente la complexité inter-frontière.

Si vous n’êtes pas sûr : conservez-les dans WSL d’abord, ajoutez une phrase de passe et utilisez un agent avec cache limité dans le temps. Ne compliquez pas trop le premier jour.

Générez des clés (Ed25519 sauf raison contraire)

Les clés Ed25519 sont rapides, compactes et largement supportées par OpenSSH moderne. Utilisez une phrase de passe robuste. Votre phrase de passe n’est pas un mot de passe ; c’est un moyen de dissuasion si le fichier est volé.

Réglez les permissions correctement (ou SSH refusera de vous aider)

OpenSSH est strict sur les permissions des clés privées. C’est une bonne chose. Sous WSL, c’est aussi un piège fréquent quand vous placez des clés sur /mnt/c où les permissions sont bizarres.

Utilisez une configuration par hôte pour arrêter d’improviser

La plupart des « problèmes SSH » sont en réalité « trop de comportements implicites ». Mettez des blocs d’hôte explicites dans ~/.ssh/config et contrôlez IdentityFile, IdentitiesOnly, User et les algorithmes de clé. Le but est de rendre le chemin correct le plus simple à suivre.

Citation (idée paraphrasée)

Idée paraphrasée : l’espoir n’est pas une stratégie — souvent attribué à Gordon R. Dickson ; utilisé en culture d’ingénierie comme rappel d’opérations.

La sécurité des clés SSH dans WSL enseigne la même leçon : ne comptez pas sur le fait que vos clés « n’atterriront pas sur Windows ». Rendez-le difficile.

Agent SSH dans WSL : arrêtez de retaper les phrases de passe, n’allumez pas d’incendie

Un agent est un compromis : commodité pour une fenêtre d’exposition limitée. Sans agent, les gens choisissent des phrases de passe faibles ou pas de phrase du tout. Avec un agent imprudent, les gens laissent des clés déchiffrées disponibles indéfiniment. Choisissez le milieu : agent + TTL + identités explicites.

Ce que vous voulez d’une configuration d’agent

• Un socket d’agent stable par session de connexion.
• Les clés sont chargées délibérément, pas implicitement depuis des chemins aléatoires.
• Les clés expirent de l’agent (liées dans le temps) sauf si vous les rechargez intentionnellement.
• SSH n’utilise que l’identité prévue pour chaque hôte.

Une petite blague, parce qu’on parle d’agents : un agent SSH, c’est comme laisser votre clé de maison au videur. Super, jusqu’à ce que le videur fasse un double service et n’aille jamais chez lui.

Forwarding d’agent : ne le faites pas partout

Forwarder votre agent (-A) peut être utile pour sauter via des bastions, mais cela augmente le risque. Si un hôte distant peut accéder à votre socket d’agent forwardé, il peut potentiellement utiliser vos clés (pas les voler, mais s’en servir) tant que le forwarding est actif. Utilisez‑le seulement pour des hôtes en qui vous avez la même confiance qu’en votre laptop. Autrement dit : prudemment.

La frontière Windows : où la commodité dévore vos secrets

Système de fichiers WSL vs /mnt/c

Dans WSL2, le système de fichiers de votre distro est stocké dans un disque virtuel. Il se comporte comme Linux l’attend. Sous /mnt/c, vous êtes sur un système de fichiers Windows avec des couches de traduction. Cette traduction est excellente pour éditer des fichiers ; c’est une responsabilité pour la sémantique des permissions Linux et l’hygiène des secrets.

Pourquoi /mnt/c est un mauvais endroit pour les clés privées

• Les permissions Windows ne sont pas des permissions POSIX ; SSH peut refuser d’utiliser les clés à cause d’un accès « trop ouvert ».
• Les clients de synchronisation cloud peuvent les ingérer et les répliquer.
• Les indexeurs d’endpoint et les antivirus peuvent les scanner. Pas toujours malveillant, mais cela augmente la surface d’attaque.
• Le DLP d’entreprise peut les signaler ou les mettre en quarantaine, cassant votre workflow de la façon la plus déroutante possible.

Quand le stockage Windows est justifié

Si votre environnement d’entreprise impose que les clés soient stockées dans un agent géré par Windows (ou des identifiants protégés par matériel) et que WSL est « best effort », alors oui : gardez les clés dans Windows et faites de WSL un consommateur. Mais considérez cela comme un projet d’intégration. Documentez‑le. Testez après les mises à jour. Ne faites pas « au pif » des symlinks.

Tâches pratiques (commandes + sorties + décisions)

Ci‑dessous des tâches pratiques que vous pouvez exécuter aujourd’hui. Chaque section inclut : la commande, une sortie représentative, ce que signifie la sortie et la décision à prendre.

Task 1: Confirm you’re actually in WSL and which version matters

cr0x@server:~$ uname -a
Linux devbox 5.15.133.1-microsoft-standard-WSL2 #1 SMP Wed Oct 11 00:00:00 UTC 2023 x86_64 GNU/Linux

Signification : « microsoft-standard-WSL2 » vous indique qu’il s’agit du comportement noyau WSL2 (VM/NAT). Cela affecte les hypothèses réseau et certaines intégrations.

Décision : Si vous déboguez le forwarding d’agent ou « pourquoi Windows ne peut pas atteindre ce socket », notez les frontières WSL2 et planifiez en conséquence.

Task 2: See where your home directory lives (Linux filesystem or Windows mount)

cr0x@server:~$ df -h ~
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc       251G   32G  207G  14% /

Signification : Le home est sur le système de fichiers racine Linux, pas sur /mnt/c.

Décision : Bien. Gardez ~/.ssh ici.

Task 3: Detect if ~/.ssh is on Windows (bad) without guessing

cr0x@server:~$ readlink -f ~/.ssh
/home/cr0x/.ssh

Signification : Le chemin réel est sous /home. Si vous aviez vu /mnt/c/..., votre répertoire SSH serait sur Windows.

Décision : S’il se résout sous /mnt/c, déplacez les clés dans WSL et corrigez les permissions.

Task 4: List keys and permissions; spot obvious leaks

cr0x@server:~$ ls -la ~/.ssh
total 28
drwx------  2 cr0x cr0x 4096 Feb  5 10:12 .
drwxr-xr-x 19 cr0x cr0x 4096 Feb  5 09:40 ..
-rw-------  1 cr0x cr0x  464 Feb  5 10:12 config
-rw-------  1 cr0x cr0x  419 Feb  5 10:11 id_ed25519
-rw-r--r--  1 cr0x cr0x   99 Feb  5 10:11 id_ed25519.pub
-rw-------  1 cr0x cr0x 1520 Feb  5 10:12 known_hosts

Signification : Le répertoire est 700, les clés privées sont 600. C’est ce que SSH demande.

Décision : Si les clés privées sont lisibles par le groupe/le monde, corrigez immédiatement avec chmod (tâche suivante).

Task 5: Fix permissions in one pass (safe defaults)

cr0x@server:~$ chmod 700 ~/.ssh
cr0x@server:~$ chmod 600 ~/.ssh/id_ed25519 ~/.ssh/config ~/.ssh/known_hosts
cr0x@server:~$ chmod 644 ~/.ssh/id_ed25519.pub

Signification : Aucune sortie signifie succès.

Décision : Si cela échoue sur /mnt/c, c’est votre signal pour cesser de stocker des clés privées sur des montages Windows.

Task 6: Generate a new Ed25519 key with a strong KDF

cr0x@server:~$ ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_work -C "work-wsl"
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/cr0x/.ssh/id_ed25519_work
Your public key has been saved in /home/cr0x/.ssh/id_ed25519_work.pub
The key fingerprint is:
SHA256:8vQZrY4eKJf1YqE6k6G4l3g6i4lqf7RkR5u9M6w8a2k work-wsl
The key's randomart image is:
+--[ED25519 256]--+
|  . . . . .      |
| . . o . o       |
|  . + . +        |
|   o . =         |
|    . . S        |
|     o o         |
|    . = +        |
|     + = .       |
|      o..        |
+----[SHA256]-----+

Signification : -a 64 augmente les rounds KDF pour la protection de la phrase de passe. Cela ralentit le bruteforce si le fichier est volé.

Décision : Utilisez une phrase de passe. Si vous ne pouvez pas, utilisez des clés protégées par matériel au lieu d’une « phrase vide ».

Task 7: Verify the private key is encrypted (not plaintext)

cr0x@server:~$ head -n 2 ~/.ssh/id_ed25519_work
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW

Signification : Vous verrez toujours un en‑tête même quand c’est chiffré, mais vous ne pouvez pas confirmer le chiffrement juste à partir de la première ligne.

Décision : Utilisez ssh-keygen -y pour forcer une invite de phrase de passe (tâche suivante). S’il n’y a pas d’invite, vous avez probablement créé une clé non chiffrée.

Task 8: Confirm passphrase prompt behavior

cr0x@server:~$ ssh-keygen -y -f ~/.ssh/id_ed25519_work >/dev/null
Enter passphrase:

Signification : L’invite indique que la clé est protégée par une phrase de passe (ou du moins nécessite un déchiffrement).

Décision : S’il n’y a pas d’invite et que la commande réussit, votre clé est probablement non chiffrée — envisagez de la réémettre avec une phrase de passe.

Task 9: Create a strict SSH config entry so the right key is used

cr0x@server:~$ cat > ~/.ssh/config <<'EOF'
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes
  PreferredAuthentications publickey
EOF
cr0x@server:~$ chmod 600 ~/.ssh/config

Signification : IdentitiesOnly yes empêche SSH d’essayer toutes les clés dans votre agent et d’occasionner des blocages ou des flux d’authentification étranges.

Décision : Utilisez des hôtes nommés (github-work) pour éviter de mélanger les clés entre identités.

Task 10: Validate what SSH will actually use (no guesswork)

cr0x@server:~$ ssh -G github-work | egrep '^(hostname|user|identityfile|identitiesonly|preferredauthentications) '
hostname github.com
user git
identityfile ~/.ssh/id_ed25519_work
identitiesonly yes
preferredauthentications publickey

Signification : ssh -G affiche la configuration résolue après includes, blocs match, etc.

Décision : Si vous voyez un identityfile ou un user inattendu, corrigez votre config avant de dépanner autre chose.

Task 11: Start an agent and load a key with a TTL

cr0x@server:~$ eval "$(ssh-agent -s)"
Agent pid 1173
cr0x@server:~$ ssh-add -t 1h ~/.ssh/id_ed25519_work
Enter passphrase for /home/cr0x/.ssh/id_ed25519_work:
Identity added: /home/cr0x/.ssh/id_ed25519_work (work-wsl)

Signification : La clé est mise en cache en mémoire pendant une heure.

Décision : Les TTL sont une assurance peu coûteuse. Si vous avez besoin de plus long, faites‑en un choix conscient, pas un défaut.

Task 12: Confirm which keys are loaded in the agent

cr0x@server:~$ ssh-add -l
256 SHA256:8vQZrY4eKJf1YqE6k6G4l3g6i4lqf7RkR5u9M6w8a2k work-wsl (ED25519)

Signification : Votre agent contient actuellement exactement une identité chargée.

Décision : Si vous voyez une pile de clés oubliées, supprimez-les : ssh-add -D, puis rechargez uniquement ce dont vous avez besoin.

Task 13: Run a verbose SSH test and read it like an SRE

cr0x@server:~$ ssh -vvv github-work
OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/cr0x/.ssh/config
debug1: /home/cr0x/.ssh/config line 1: Applying options for github-work
debug1: Connecting to github.com [140.82.112.3] port 22.
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([140.82.112.3]:22).

Signification : Vous pouvez voir exactement quelle config s’est appliquée, quel hôte/port et si l’authentification par clé publique a fonctionné.

Décision : S’il essaie la mauvaise clé, corrigez la config (IdentityFile, IdentitiesOnly) et l’état de l’agent ; n’insistez pas aveuglément.

Task 14: Check for host key pinning and unexpected changes

cr0x@server:~$ ssh-keygen -F github.com -f ~/.ssh/known_hosts | head
# Host github.com found: line 3
github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...

Signification : Vous avez une entrée de clé d’hôte épinglée pour cet hôte.

Décision : Si une clé d’hôte change de façon inattendue, traitez cela comme un incident de sécurité jusqu’à preuve du contraire. Ne supprimez pas réflexivement known_hosts.

Task 15: Detect accidental key material under /mnt/c (the leak scan)

cr0x@server:~$ grep -R --line-number --binary-files=without-match "BEGIN OPENSSH PRIVATE KEY" /mnt/c/Users/cr0x 2>/dev/null | head
/mnt/c/Users/cr0x/Downloads/wsl-export.tar:1:-----BEGIN OPENSSH PRIVATE KEY-----

Signification : Vous avez trouvé un en‑tête de clé privée dans un fichier côté Windows (ici : un tar d’export). C’est un véritable chemin de fuite.

Décision : Considérez‑la compromise tant que vous n’avez pas vérifié la contention. Faites la rotation des clés et supprimez l’artéfact. Corrigez aussi votre workflow de sauvegarde/export.

Task 16: Identify whether your Git repo contains secrets before you push

cr0x@server:~$ git status --porcelain
?? .ssh/id_ed25519_work
?? .ssh/id_ed25519_work.pub

Signification : Vous êtes sur le point de committer vos clés SSH. Pas « peut‑être ». Vous êtes en train de le faire.

Décision : Ajoutez .ssh/ à .gitignore, retirez les fichiers de l’index de travail et faites la rotation si quoi que ce soit a été poussé n’importe où.

Task 17: Confirm Windows interop is not silently copying SSH config (sanity check)

cr0x@server:~$ ls -la /mnt/c/Users/cr0x/.ssh 2>/dev/null
total 12
drwxr-xr-x 1 cr0x cr0x 4096 Feb  5 09:55 .
drwxr-xr-x 1 cr0x cr0x 4096 Feb  5 09:20 ..
-rw-r--r-- 1 cr0x cr0x  412 Feb  5 09:55 config

Signification : Il existe une configuration SSH côté Windows. Certains outils (y compris OpenSSH Windows et les outils Git) peuvent l’utiliser.

Décision : Décidez délibérément : soit gardez les configs Windows et WSL séparées, soit standardisez sur une seule et documentez la frontière. « Deux configs qui dérivent » devient une usine à tickets.

Playbook de diagnostic rapide

Voici le workflow « c’est cassé et j’ai cinq minutes ». Il priorise le signal. Vous pourrez approfondir plus tard.

Première étape : SSH utilise‑t‑il la configuration que vous pensez ?

• Exécutez ssh -G <host-alias> et confirmez hostname, user et identityfile.
• Si identityfile est incorrect, corrigez ~/.ssh/config avant de toucher aux agents, permissions ou serveurs.

Deuxième étape : la clé est‑elle accessible et correctement permissionnée ?

• Vérifiez ls -la ~/.ssh et assurez‑vous que les clés privées sont 600, le répertoire 700.
• Si les clés sont sur /mnt/c, supposez des problèmes de permissions et déplacez‑les dans WSL.

Troisième étape : l’état de l’agent est‑il sain ?

• Exécutez ssh-add -l. S’il renvoie une erreur, votre agent n’est pas en cours ou SSH_AUTH_SOCK est incorrect.
• S’il liste dix clés, taillez‑les. Gardez l’agent minimal et explicite.

Quatrième étape : le serveur vous refuse‑t‑il ou n’offrez‑vous pas ce qu’il veut ?

• Utilisez ssh -vvv une fois, lisez les lignes à propos de « Offering public key » et « Authentication succeeded/failed ».
• Si le serveur dit « too many authentication failures », vous offrez trop de clés. Verrouillez avec IdentitiesOnly.

Cinquième étape : les avertissements de clés d’hôte ne sont pas du « bruit »

• Si vous voyez un avertissement de changement de clé d’hôte, arrêtez. Vérifiez hors bande si l’hôte a été reconstruit ou compromis.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “Bad permissions” or “Unprotected private key file”

Cause racine : La clé privée vit sur /mnt/c ou a un mode/ownership trop permissif.

Correction : Déplacez la clé dans le système de fichiers Linux de WSL et appliquez des permissions strictes.

cr0x@server:~$ mv /mnt/c/Users/cr0x/.ssh/id_ed25519 ~/.ssh/id_ed25519_windows_moved
cr0x@server:~$ chmod 700 ~/.ssh
cr0x@server:~$ chmod 600 ~/.ssh/id_ed25519_windows_moved

2) Symptom: “Permission denied (publickey)” after it used to work

Cause racine : Vous avez fait une rotation de clés, modifié le contenu de l’agent, ou votre config SSH pointe maintenant vers un autre IdentityFile.

Correction : Validez avec ssh -G, puis assurez‑vous que la bonne clé est chargée.

cr0x@server:~$ ssh -G myhost | egrep '^(identityfile|identitiesonly|user|hostname) '
identityfile ~/.ssh/id_ed25519_work
identitiesonly yes
user deploy
hostname myhost

3) Symptom: “Too many authentication failures”

Cause racine : L’agent contient de nombreuses identités et SSH les propose en séquence jusqu’à ce que le serveur se déconnecte.

Correction : Utilisez IdentitiesOnly yes et spécifiez un seul IdentityFile par alias d’hôte. Épurez aussi l’agent.

cr0x@server:~$ ssh-add -D
All identities removed.
cr0x@server:~$ ssh-add -t 30m ~/.ssh/id_ed25519_work
Enter passphrase for /home/cr0x/.ssh/id_ed25519_work:
Identity added: /home/cr0x/.ssh/id_ed25519_work (work-wsl)

4) Symptom: Host key verification failed after rebuild

Cause racine : La clé d’hôte a changé (rebuild légitime, ou pas). Votre entrée dans known_hosts est obsolète.

Correction : Vérifiez hors bande l’empreinte de la nouvelle clé d’hôte. Puis supprimez l’ancienne entrée par hôte et réajoutez en vous connectant.

cr0x@server:~$ ssh-keygen -R myhost -f ~/.ssh/known_hosts
# Host myhost found: line 12
/home/cr0x/.ssh/known_hosts updated.
Original contents retained as /home/cr0x/.ssh/known_hosts.old

5) Symptom: Your key shows up in a Windows search index / cloud sync

Cause racine : Vous avez copié ~/.ssh dans Windows, ou exporté WSL et stocké la tarball dans un emplacement synchronisé.

Correction : Assumez l’exposition. Faites la rotation des clés, supprimez les artéfacts, ajustez l’export/sauvegarde pour exclure les secrets.

6) Symptom: SSH works in WSL terminal but fails in VS Code / Git GUI

Cause racine : L’outil utilise OpenSSH Windows, pas OpenSSH de WSL, et donc lit une config et des clés différentes.

Correction : Décidez quel côté gère SSH pour ce workflow. Configurez l’outil explicitement pour utiliser le binaire et le magasin de clés corrects. Ne maintenez pas deux univers parallèles à moins d’aimer l’angoisse existentielle.

7) Symptom: Agent works in one shell tab but not another

Cause racine : Les variables d’environnement du socket d’agent ne sont pas exportées de façon cohérente, ou vous avez démarré une nouvelle session sans sourcer la configuration de l’agent.

Correction : Utilisez une stratégie de démarrage d’agent cohérente et stockez SSH_AUTH_SOCK dans un endroit prévisible par session (ou fiez‑vous au gestionnaire de services de votre distro si disponible).

Trois mini-récits d’entreprise venus des tranchées

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils ont déployé WSL comme environnement de dev standard pour une équipe qui gère l’infrastructure de production. C’était une décision sensée : outils cohérents, moins de « ça marche sur ma machine », et onboarding plus facile. Les clés ont été générées dans WSL, tout le monde utilisait des phrases de passe, et la case conformité était cochée avec un bruit satisfaisant.

L’hypothèse erronée était subtile : « si c’est dans WSL, ce n’est pas sur Windows ». C’était en grande partie vrai — jusqu’à ce qu’un développeur exporte sa distro pour migrer sur un nouveau laptop. La tarball d’export a atterri dans un dossier synchronisé par l’entreprise parce que les instructions de « Migration de Laptop » disaient d’y mettre les gros fichiers.

Rien n’a explosé tout de suite. C’est le pire type d’échec. Une semaine plus tard, les outils de sécurité ont signalé un pattern d’empreinte de clé privée dans le stockage synchronisé. La clé n’avait pas été manifestement utilisée (autant que l’on puisse le prouver), mais l’organisation a dû la traiter comme compromise. Revue d’accès, rotation des clés, nettoyage des authorized_keys sur les bastions. Les gens ont été agacés par la « paperasse ».

La correction n’a pas été héroïque. Ils ont mis à jour le playbook interne : les exports WSL sont sensibles ; les exports doivent être chiffrés au repos ; et ~/.ssh est exclu des exports sauf si c’est explicitement requis. Ils ont aussi introduit des clés protégées par matériel pour les accès production, de sorte que les exports ne contiennent pas de bijoux de la couronne.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe voulait du développement « zéro prompt ». Les phrases de passe ralentissaient l’automatisation, disaient‑ils, et leurs opérations de repo étaient constantes. Ils ont donc standardisé sur des clés privées non chiffrées dans WSL, plus une image de base largement partagée pour accélérer les nouveaux arrivants. C’était beau en démo : clone, build, deploy, pas d’interruptions.

Puis la contre‑attaque : les images de base ont été copiées. Les gens zippaient leur distro WSL pour « partager rapidement ». La machine d’un sous‑traitant a été compromise par un malware de commodité qui ne ciblait même pas SSH — simplement en scrappant des fichiers qui ressemblaient à des clés. Soudain, les clés non chiffrées étaient exactement ce dont l’attaquant avait besoin. Pas de brute force. Aucune sophistication. Juste « trouve le fichier, utilise le fichier ».

Ils ont passé des semaines à démêler quelles clés donnaient accès à quoi. Le pire n’était pas le confinement immédiat. C’était l’archéologie : anciennes clés, hôtes oubliés, entrées authorized_keys obsolètes sur des serveurs de longue durée. L’« optimisation » avait transformé une dette opérationnelle en multiplicateur d’incidents de sécurité.

Après, ils sont passés aux clés avec phrase de passe plus TTL d’agent, et ont standardisé des clés par service avec accès restreint. La productivité est restée élevée ; les invites étaient gérables ; et la surface de risque a fortement diminué. Il s’avère qu’on peut être rapide et sûr. Il suffit de ne pas être « rapide parce qu’on a ignoré le problème ».

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe plateforme avait l’habitude, qui semblait pointilleuse : chaque ingénieur maintenait un ~/.ssh/config strict avec des alias d’hôte nommés, des fichiers d’identité explicites et IdentitiesOnly yes. Ils épinglaient aussi les clés d’hôte et refusaient de désactiver la vérification stricte des clés sauf dans des flux d’amorçage très contrôlés.

Pendant une fenêtre de réponse à incident, ils ont dû accéder à une flotte via un bastion. Le DNS était partiellement brisé, et certains ingénieurs étaient dirigés vers de mauvaises adresses IP. C’est là que beaucoup d’équipes deviennent négligentes : « connectez‑vous vite, on réglera après ».

Mais SSH a refusé un sous‑ensemble de connexions à cause de mismatches sur les clés d’hôte. Ennuyeux ? Sur le moment, oui. Valable ? Absolument. Cela a empêché des gens de taper des identifiants et d’exécuter des commandes sur les mauvaises machines alors que le stress était élevé et l’attention faible.

L’équipe a vérifié les bonnes clés d’hôte via leur canal d’inventaire de confiance, a mis à jour les enregistrements si nécessaire, puis s’est reconnectée. Ce comportement terne et discipliné leur a évité d’aggraver l’incident. La fiabilité est souvent l’art de refuser de faire ce qui est commode et faux.

Listes de vérification / plan étape par étape

Checklist A : Nouvelle machine WSL, SSH sécurisé en 20 minutes

1. Créez ~/.ssh dans le système de fichiers Linux de WSL et verrouillez les permissions.
2. Générez une clé Ed25519 avec une phrase de passe et des rounds KDF décents.
3. Créez ~/.ssh/config avec des alias d’hôte explicites et IdentitiesOnly yes.
4. Démarrez un agent et chargez la clé avec un TTL (ssh-add -t).
5. Connectez‑vous une fois avec ssh -vvv pour confirmer la sélection de clé et l’épinglage d’hôte.
6. Scannez les montages Windows pour des copies accidentelles de clés privées.

Checklist B : Prévenir les fuites via sauvegardes et exports

1. Décidez si les exports WSL sont autorisés à contenir des secrets.
2. Si vous devez exporter, chiffrez immédiatement la tarball et stockez‑la uniquement dans des emplacements approuvés.
3. Privilégiez des clés protégées par matériel pour la production afin que les exports n’emportent pas les joyaux de la couronne.
4. Effectuez périodiquement un grep pour les en‑têtes de clés privées sur les chemins Windows.

Checklist C : Rotation de clés sans drame

1. Générez une nouvelle clé avec un nouveau nom de fichier (ne pas écraser immédiatement).
2. Ajoutez la nouvelle clé publique au service distant ou dans authorized_keys.
3. Mettre à jour ~/.ssh/config pour pointer vers la nouvelle clé pour un alias d’hôte.
4. Testez avec ssh -vvv et vérifiez que la bonne clé est proposée.
5. Supprimez l’ancienne clé du distant, puis effacez l’ancienne clé privée localement.
6. Videz les identités de l’agent et rechargez uniquement la nouvelle clé.

Deuxième petite blague, parce que vous méritez une pause : Faire tourner les clés, c’est comme passer le fil dentaire — personne n’aime, mais l’alternative coûte bien plus cher.

FAQ

1) Dois‑je générer des clés SSH dans Windows ou dans WSL ?

Si vous travaillez principalement dans WSL, générez et stockez les clés dans le système de fichiers Linux de WSL (/home). Ne les gardez dans Windows que si vous avez une stratégie d’agent géré Windows délibérée.

2) Est‑il sûr de placer ma clé privée sous /mnt/c ?

C’est un mauvais choix par défaut. Vous héritez du comportement d’indexation et de synchronisation Windows et d’un mapping de permissions problématique. Placez les clés privées dans le système de fichiers natif WSL à la place.

3) Quel est le meilleur type de clé en 2026 ?

Pour un usage général : Ed25519. Pour une forte assurance : clés protégées par matériel (FIDO2) où la clé privée n’est pas exportable. N’utilisez RSA que si vous devez supporter des systèmes legacy.

4) Ai‑je vraiment besoin d’une phrase de passe si j’utilise ssh-agent ?

Oui. L’agent vous évite de retaper. La phrase de passe vous protège si le fichier clé est copié. Ce sont des protections pour deux problèmes différents.

5) Pourquoi SSH dit que les permissions de ma clé sont trop ouvertes ?

OpenSSH refuse d’utiliser des clés privées lisibles par d’autres. Sur les montages Windows, les permissions apparaissent souvent trop permissives. Déplacez la clé dans le système de fichiers WSL et appliquez chmod 600.

6) Pourquoi ça marche dans le terminal mais pas dans mon client Git ?

Votre client Git peut utiliser OpenSSH Windows et le magasin/config Windows, pas ceux de WSL. Décidez lequel vous voulez et configurez l’outil en conséquence.

7) Le forwarding d’agent est‑il sûr ?

Assez sûr s’il est utilisé rarement sur des hôtes de confiance, risqué s’il est utilisé largement. Le forwarding permet aux hôtes distants d’utiliser votre agent pendant la connexion. Ne forwardez pas dans des environnements que vous ne maîtrisez pas complètement.

8) Comment savoir quelle clé SSH propose ?

Utilisez ssh -vvv et cherchez les lignes « Offering public key » et le chemin du fichier d’identité. Utilisez aussi ssh -G pour voir la config résolue.

9) Que faire si j’ai accidentellement commis une clé privée ?

Considérez‑la compromise. Faites une rotation immédiatement, supprimez‑la des emplacements autorisés et purgez‑la de l’historique si possible. Ensuite, auditez pour d’éventuelles copies (logs CI, forks, mirrors).

10) Puis‑je partager une clé unique sur tous les hôtes pour simplifier ?

Vous pouvez, mais ce n’est pas recommandé. Une clé unique partout transforme une fuite en compromission totale. Utilisez plusieurs clés par identité et par portée.

Conclusion : prochaines étapes que vous pouvez vraiment faire aujourd’hui

Les clés SSH dans WSL ne sont pas intrinsèquement risquées. La partie risquée est de traiter WSL comme une frontière de sécurité magique et de considérer les fichiers de clé comme de simples configurations. Ce sont des identifiants. Traitez‑les comme tels.

1. Déplacez les clés privées hors de /mnt/c et dans votre répertoire home WSL.
2. Assurez‑vous que chaque clé privée est protégée par une phrase de passe et correctement permissionnée (700 pour ~/.ssh, 600 pour les clés privées).
3. Utilisez des alias d’hôte dans ~/.ssh/config avec IdentitiesOnly yes pour que la bonne clé soit utilisée à chaque fois.
4. Lancez un agent avec des TTL et gardez les identités chargées au minimum.
5. Scannez les dossiers côté Windows pour des copies accidentelles de clés, en particulier les tarballs d’export et les dossiers « Downloads ».

Faites ces cinq actions et vous éviterez les chemins de fuite les plus courants. Vous déboguerez aussi plus vite, car le comportement SSH sera déterministe au lieu d’être une maison hantée de valeurs par défaut.