Générateur de Clés SSH

RSA 2048 bits répond aux normes de sécurité actuelles et est approuvé par le NIST jusqu'en au moins 2030. RSA 4096 bits offre une marge de sécurité plus grande pour les clés qui seront utilisées pendant de nombreuses années, mais il est nettement plus lent pour les opérations de handshake (environ 4x plus lent que le 2048 bits). Pour la plupart des cas d'utilisation — accès au serveur, GitHub/GitLab, pipelines CI/CD — 2048 bits est suffisant. Pour les clés utilisées dans des environnements à haute sécurité ou dont on prévoit une utilisation pendant plus de 10 ans, utilisez 4096 bits. Pour la meilleure combinaison de vitesse et de sécurité, utilisez Ed25519 à la place.

Une phrase de passe chiffre votre fichier de clé privée afin que, même si quelqu'un obtient le fichier, il ne puisse pas l'utiliser sans la phrase de passe. Lorsque vous utilisez la clé, votre client SSH vous demande la phrase de passe pour la déchiffrer (ssh-agent peut mettre en cache la clé déchiffrée pour que vous ne soyez pas sollicité à plusieurs reprises). Pour les clés destinées aux utilisateurs (votre ordinateur portable vers vos serveurs), utilisez une phrase de passe — elle offre une protection critique si votre machine est perdue ou volée. Pour les clés de déploiement automatisées CI/CD qui s'exécutent sans interaction humaine, les clés protégées par une phrase de passe sont peu pratiques et le fichier de clé doit être sécurisé par d'autres moyens (permissions de fichiers, systèmes de gestion de secrets).

Copiez le contenu de la clé publique (commençant par "ssh-rsa" ou "ssh-ed25519") et ajoutez-le au fichier ~/.ssh/authorized_keys sur votre serveur. Une seule clé publique par ligne. Si le répertoire n'existe pas : mkdir -p ~/.ssh && chmod 700 ~/.ssh. Définissez les bonnes permissions : chmod 600 ~/.ssh/authorized_keys. La méthode la plus rapide depuis votre machine locale : ssh-copy-id user@hostname (en utilisant votre mot de passe pour cette configuration unique). Après cela, SSH utilisera votre clé automatiquement. Votre clé privée reste uniquement sur votre machine locale et n'est jamais téléchargée ailleurs.

Le commentaire est une étiquette intégrée dans la clé publique après les données de la clé (ex: ssh-ed25519 AAAA... user@laptop). Il n'a aucun effet sur l'authentification — il est purement descriptif. Utilisez-le pour identifier l'origine de la clé lorsque vous vérifiez authorized_keys sur un serveur : qui a créé cette clé, depuis quelle machine et dans quel but. Formats courants : user@hostname (par défaut), votre adresse e-mail ou une étiquette descriptive comme "ci-deploy-prod-2026". Lorsque vous avez plusieurs clés dans authorized_keys, un commentaire significatif est le seul moyen de savoir quelle clé révoquer si quelque chose tourne mal.

L'empreinte (fingerprint) est un hash SHA-256 de la clé publique, affiché au format Base64 (ex: SHA256:abc123...). C'est un moyen compact d'identifier et de vérifier une clé spécifique. Lorsque vous vous connectez pour la première fois à un serveur avec SSH, le serveur affiche l'empreinte de sa clé hôte — vous la vérifiez pour confirmer que vous vous connectez au bon serveur. Lorsque vous téléchargez une clé publique sur GitHub, GitLab ou d'autres services, ils affichent l'empreinte. Si l'empreinte correspond à ce que cet outil affiche, la clé a été téléchargée correctement. Vous pouvez également exécuter ssh-keygen -l -f ~/.ssh/id_ed25519 sur votre machine pour vérifier les empreintes localement.

Oui. Toute la génération de clés utilise l'API Web Crypto, qui est une API native du navigateur fournissant des opérations cryptographiquement sécurisées étayées par la source d'entropie du système d'exploitation. La génération de nombres aléatoires utilise crypto.getRandomValues(), et non le Math.random() qui n'est pas sécurisé. Les clés générées sont équivalentes en termes de sécurité à celles produites par ssh-keygen en ligne de commande. Rien n'est envoyé à aucun serveur — la paire de clés existe uniquement dans votre session de navigateur.

Ne remplacez jamais vos clés autorisées existantes — ajoutez votre nouvelle clé publique comme une entrée supplémentaire. Ensuite, ouvrez une seconde session SSH (sans fermer la session actuelle) pour tester la nouvelle clé. Ce n'est qu'après avoir confirmé que la nouvelle clé fonctionne que vous devez supprimer les anciennes clés ou modifier votre politique de mots de passe. Si vous vous retrouvez bloqué, vous aurez besoin d'un accès console au serveur (les fournisseurs cloud appellent cela une "console d'urgence" ou un "mode de secours") pour modifier manuellement authorized_keys.