generate ssh key for windows

Arrêtez de copier-coller vos mots de passe dans des terminaux qui vous rejettent à la moindre erreur de frappe. C'est lent. C'est risqué. Si vous travaillez sur des serveurs distants ou que vous gérez vos dépôts sur GitHub, vous devez absolument Generate SSH Key for Windows pour automatiser vos accès de manière sécurisée. On pense souvent que c'est une manipulation réservée aux barbus sous Linux, mais Windows a fait des progrès gigantesques ces dernières années pour intégrer ces outils nativement. On va voir ensemble comment configurer ça proprement, sans installer des logiciels inutiles qui pèsent trois tonnes.

Pourquoi OpenSSH a enterré les vieilles méthodes

Pendant longtemps, la norme sur Windows s'appelait PuTTY. C'était l'époque où Microsoft ignorait royalement le monde de l'open source. Il fallait passer par un utilitaire nommé PuTTYgen, jongler avec des formats de fichiers .ppk bizarres et configurer des agents tiers comme Pageant. C'était pénible.

Aujourd'hui, Windows 10 et Windows 11 intègrent nativement le client OpenSSH. C'est une révolution pour notre confort quotidien. On utilise les mêmes commandes que sur macOS ou Ubuntu. Pas de dépaysement. L'avantage est évident : la cohérence. Quand vous apprenez une commande dans votre Powershell, elle est valable partout.

Le choix de l'algorithme de chiffrement

On ne crée pas une clé au hasard. Le standard historique, c'est le RSA. C'est solide, mais c'est vieux. Un bit de clé RSA n'offre pas la même résistance qu'un bit de clé plus moderne. Actuellement, je vous conseille vivement d'utiliser l'algorithme Ed25519.

Pourquoi ce nom barbare ? C'est une courbe elliptique. C'est beaucoup plus court. C'est plus rapide à générer et à valider. Surtout, c'est considéré comme plus sûr face aux attaques modernes par rapport au RSA 2048 bits qui commence à dater. Si vous travaillez pour une administration publique en France, l' ANSSI publie régulièrement des recommandations sur les tailles de clés et les algorithmes à privilégier. En général, Ed25519 coche toutes les cases de la sécurité contemporaine.

Les étapes pour Generate SSH Key for Windows en quelques secondes

Ouvrez votre terminal. Pas besoin de l'exécuter en tant qu'administrateur pour cette tâche précise. On va utiliser l'utilitaire ssh-keygen. C'est le couteau suisse de l'authentification sécurisée.

Tapez la commande suivante : ssh-keygen -t ed25519 -C "votre_email@exemple.com". Le drapeau -t définit le type d'algorithme. Le -C ajoute un commentaire, souvent votre adresse mail, pour identifier la clé quand vous la lirez dans six mois sur une interface web.

La question fatidique de la passphrase

Le programme va vous demander où enregistrer le fichier. Appuyez sur Entrée pour accepter l'emplacement par défaut. Ensuite, il demande une "passphrase". Ne faites pas l'erreur de laisser ce champ vide.

Si quelqu'un vole votre ordinateur ou accède à vos fichiers, une clé sans mot de passe lui donne un accès total à vos serveurs. C'est une porte ouverte. Une bonne passphrase n'a pas besoin d'être un mélange illisible de symboles. Une phrase simple mais longue, comme "LeChatNoirMangeDuFromage92", est très efficace. Elle protège votre clé privée sur votre disque dur.

Où se cachent vos fichiers

Une fois l'opération terminée, vous aurez deux fichiers dans le dossier .ssh de votre répertoire utilisateur. Le fichier id_ed25519 est votre clé privée. C'est votre secret. Ne le donnez jamais à personne. Ne l'envoyez pas par mail. Le second, id_ed25519.pub, est votre clé publique. C'est celle-ci que vous allez diffuser. Elle est comme votre serrure, tandis que la clé privée est, eh bien, la clé physique.

Configurer l'agent SSH pour ne plus taper son mot de passe

Taper sa passphrase à chaque connexion, c'est l'enfer. On finit par ne plus mettre de mot de passe du tout par paresse. C'est là qu'intervient l'agent d'authentification OpenSSH. C'est un service Windows qui garde votre clé déchiffrée en mémoire pendant votre session.

Vérifiez d'abord si le service est activé. Dans Powershell, utilisez la commande Get-Service ssh-agent. S'il est arrêté, lancez-le avec Start-Service ssh-agent. Pour qu'il se lance tout seul au démarrage de votre PC, vous devrez changer son type de démarrage en "Automatique".

Une fois l'agent actif, ajoutez votre clé avec la commande ssh-add. Vous tapez votre passphrase une seule fois. Après ça, Windows gérera les connexions en arrière-plan. C'est un gain de productivité massif. Vous n'avez plus l'impression de franchir une douane à chaque interaction avec votre serveur.

Envoyer sa clé sur un serveur distant

Avoir une clé sur son PC, c'est bien. S'en servir, c'est mieux. Pour un serveur Linux classique, la méthode la plus propre consiste à ajouter le contenu de votre fichier .pub dans le fichier ~/.ssh/authorized_keys de la machine distante.

Sous Windows, on n'a pas toujours la commande ssh-copy-id disponible nativement. Vous pouvez simplement ouvrir le fichier public avec le Bloc-notes, copier le texte, et le coller manuellement sur le serveur via une connexion SSH temporaire par mot de passe.

Utilisation avec GitHub ou GitLab

Pour les développeurs, le processus est encore plus simple. Allez dans les paramètres de votre profil, section "SSH and GPG keys". Cliquez sur "New SSH key", donnez-lui un nom explicite comme "Laptop Windows Perso" et collez le contenu de votre id_ed25519.pub.

Dès cet instant, vos git push et git pull fonctionneront instantanément. Plus besoin de renseigner vos identifiants à chaque fois. C'est propre. C'est pro. Les services comme GitHub recommandent d'ailleurs fortement cette méthode pour éviter les interceptions de mots de passe en clair.

Erreurs classiques et comment les corriger

On se trompe souvent au début. L'erreur la plus fréquente concerne les permissions de fichiers. SSH est très pointilleux. Si votre clé privée est accessible par n'importe quel autre utilisateur de votre machine, le client SSH refusera de l'utiliser. Il vous dira que les permissions sont "too open".

Sous Windows, cela arrive parfois si vous avez déplacé le dossier manuellement. Faites un clic droit sur le fichier de votre clé privée, allez dans Propriétés, puis Sécurité, et vérifiez que seul votre compte utilisateur a un accès complet. Supprimez "Tout le monde" ou "Utilisateurs authentifiés" de la liste.

Le problème du format de clé

Certains vieux serveurs ne supportent pas encore Ed25519. C'est rare en 2026, mais ça arrive sur des infrastructures héritées qui n'ont pas été mises à jour depuis dix ans. Si vous recevez une erreur de type "key type not supported", vous devrez recommencer le processus en générant une clé RSA de 4096 bits. La commande devient ssh-keygen -t rsa -b 4096. C'est plus lourd, mais c'est universel.

Conflits entre différents terminaux

Si vous utilisez à la fois Powershell, l'invite de commande classique et WSL (Windows Subsystem for Linux), vous pourriez avoir des surprises. WSL est un environnement Linux complet à l'intérieur de Windows. Il possède son propre dossier .ssh indépendant de celui de Windows.

Pour éviter de Generate SSH Key for Windows deux fois, vous pouvez créer un lien symbolique entre les deux dossiers. Mais franchement, c'est souvent plus simple de copier les fichiers d'un côté à l'autre ou de simplement générer deux paires de clés distinctes. Une pour Windows, une pour WSL. Comme ça, vous savez exactement d'où vient la connexion quand vous regardez vos logs de sécurité.

Gérer plusieurs clés pour différents comptes

On finit tous par avoir plusieurs identités numériques. Un compte pour le boulot, un compte pour les projets perso, peut-être un accès spécifique pour un client externe. Utiliser la même clé partout n'est pas une bonne pratique de sécurité. Si une clé est compromise, tous vos accès tombent.

La solution réside dans le fichier config situé dans votre dossier .ssh. C'est un petit fichier texte qui dit au client SSH : "Si je me connecte à github.com, utilise cette clé. Si je me connecte à mon serveur pro, utilise celle-là".

Voici un exemple de ce qu'on peut y mettre : Host github-perso HostName github.com User git IdentityFile ~/.ssh/id_ed25519_perso

Host serveur-pro HostName 1.2.3.4 User admin IdentityFile ~/.ssh/id_ed25519_pro

Grâce à ça, vous n'avez plus à vous soucier de quelle clé est envoyée à qui. Le système choisit la bonne automatiquement en fonction de l'alias que vous utilisez.

Sécuriser son environnement de travail

On néglige souvent la sécurité physique. Si vous laissez votre session Windows ouverte dans un café ou un espace de coworking, n'importe qui peut utiliser votre agent SSH actif pour se connecter à vos serveurs sans mot de passe.

Verrouillez toujours votre session (Touche Windows + L). C'est le premier rempart. Pensez aussi à chiffrer votre disque dur avec BitLocker. C'est inclus dans les versions Pro de Windows et ça protège vos clés SSH contre le vol physique de votre ordinateur ou de son disque dur.

Les clés matérielles, l'avenir ?

Si vous travaillez sur des données ultra-sensibles, vous devriez regarder du côté des clés FIDO2, comme les YubiKey. Windows supporte désormais la génération de clés SSH résidant directement sur ces petits jetons USB. La clé privée ne quitte jamais le matériel. Même si votre PC est infecté par un malware, l'attaquant ne peut pas voler votre clé privée. Il faudrait qu'il possède physiquement la clé USB et qu'il connaisse votre code PIN. C'est le sommet de la sécurité actuelle.

Check-list pour une configuration réussie

Suivez ces étapes dans l'ordre pour être sûr de ne rien oublier. C'est la méthode la plus propre pour intégrer les standards modernes de sécurité sur votre poste de travail.

1. Ouvrez Powershell et lancez la commande de génération avec l'algorithme Ed25519.
2. Saisissez une passphrase solide. Ne succombez pas à la tentation du vide, même si c'est pour un test rapide.
3. Activez le service ssh-agent dans les services Windows et réglez-le sur "Automatique".
4. Ajoutez votre clé avec ssh-add pour éviter de retaper le mot de passe sans arrêt.
5. Copiez le contenu de votre clé publique sur les serveurs ou services tiers (GitHub, GitLab, serveurs cloud).
6. Vérifiez les permissions du dossier .ssh pour vous assurer que vous êtes le seul à pouvoir lire vos secrets.
7. Testez la connexion avec ssh -T git@github.com pour confirmer que tout fonctionne.

Le passage aux clés SSH transforme votre manière de travailler. On oublie la friction des mots de passe. On gagne en sérénité. Windows est enfin devenu un environnement de premier choix pour gérer ces protocoles, profitez-en pour mettre de l'ordre dans vos accès dès aujourd'hui. L'effort initial de dix minutes vous fera gagner des heures de frustration cumulées sur l'année. C'est un investissement rentable, peu importe votre niveau technique actuel. Si vous gérez des serveurs pour votre entreprise ou simplement un petit blog personnel, c'est la base de l'hygiène informatique. N'attendez pas d'être victime d'un vol d'identifiants pour passer à cette méthode robuste. Au fond, c'est une question de professionnalisme. Plus on simplifie ses flux de travail, plus on peut se concentrer sur ce qui compte vraiment : le code ou l'administration système efficace. Une fois que vous aurez goûté au confort des clés SSH, vous vous demanderez comment vous avez pu faire autrement pendant tout ce temps.