Clés SSH : création et ajout
Comment générer une paire de clés, ajouter la clé publique dans le panneau de contrôle du serveur, pourquoi l'enregistrement redémarre le serveur, et pourquoi les clés ne fonctionnent pas sur Windows Server.
Mis à jour le 23 août 2026
Une clé SSH est une paire de fichiers : la clé privée reste chez vous, la clé publique réside sur la machine. Contrairement à un mot de passe, elle ne peut pas être forcée par force brute.
Créer une paire de clés
La commande est identique dans Windows Terminal, PowerShell, macOS et Linux :
ssh-keygen -t ed25519 -C "artem@laptop"
Lorsque le fichier vous est demandé, appuyez sur Entrée (la valeur par défaut est ~/.ssh/id_ed25519). Vous devriez définir une phrase de passe sur la clé : si votre ordinateur portable est volé, une clé sans phrase de passe donne un accès immédiat à la machine.
Deux fichiers apparaîtront :
| Fichier | Ce qu'il est |
|---|---|
id_ed25519 | Clé privée. Ne la partagez jamais, ne la téléversez nulle part |
id_ed25519.pub | Clé publique. C'est ce que vous collez dans le panneau |
Pour afficher la clé publique :
cat ~/.ssh/id_ed25519.pub
La ligne ressemble à ceci : ssh-ed25519 AAAAC3Nza... artem@laptop.
Ajouter la clé dans le panneau
Ouvrez le panneau de la machine à l'adresse /hosting/vds/m/<id>, l'onglet « Accès », la sous-section « Clés SSH », collez les clés dans le champ et cliquez sur « Enregistrer les clés ».
L'enregistrement des clés redémarre une machine en cours d'exécution. Les clés sont appliquées par la configuration initiale au démarrage, elles ne prendraient donc pas effet sans un redémarrage. Tout ce qui ne survit pas à un redémarrage sera interrompu : connexions ouvertes, données non enregistrées, services sans démarrage automatique. Sur une machine de production, choisissez le bon moment et modifiez la liste en une seule fois, pas clé par clé.
La liste des clés est entièrement remplacée. Envoyez l'ensemble complet : si vous aviez déjà une clé depuis votre ordinateur de travail et que vous n'enregistrez que la nouvelle, l'ancienne cessera de fonctionner. Un champ vide supprime toutes les clés.
Format : une clé par ligne :
ssh-ed25519 AAAAC3Nza... artem@laptop
ssh-ed25519 AAAAC3Nza... artem@work
Collez la ligne entière, y compris le type au début et le commentaire à la fin, sans saut de ligne.
Vous pouvez spécifier la clé directement lors de la commande à l'adresse /hosting/vds/new — elle sera alors ajoutée à la machine lors de son provisionnement, sans redémarrage supplémentaire.
Windows Server n'a pas de clés SSH
Le champ de clé s'applique aux machines Linux. Nous provisionnons Windows Server 2022 et 2025 sans serveur SSH : vous vous connectez via RDP en tant qu'Administrator avec le mot de passe du panneau. Une clé enregistrée pour une telle machine ne débloquera rien — c'est pourquoi l'assistant de commande n'affiche pas de champ pour celle-ci.
La façon de se connecter et ce qu'il faut faire dans les premières minutes sont décrits dans l'article Première connexion à Windows Server via RDP, et la protection des accès dans l'article Sécurité RDP : port, mots de passe, restrictions.
Tester la connexion
Depuis une nouvelle fenêtre de terminal, sans fermer la session en cours :
ssh root@203.0.113.10
Si aucun mot de passe ne vous a été demandé, la clé fonctionne. Si c'est le cas, consultez le tableau des erreurs ci-dessous.
Pour éviter de saisir l'adresse à chaque fois, configurez un fichier ~/.ssh/config.
Désactiver la connexion par mot de passe
Uniquement après un test réussi :
nano /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin prohibit-password
systemctl restart ssh
Si quelque chose se passe mal, vous aurez toujours accès à la machine via la console texte dans le panneau — elle fonctionne indépendamment de SSH.
Erreurs courantes
| Symptôme | Cause |
|---|---|
| Un mot de passe est toujours demandé | La clé privée a été collée dans le panneau au lieu du .pub, ou la clé porte un mauvais nom et le client ne la détecte pas |
UNPROTECTED PRIVATE KEY FILE | Les permissions sont trop larges : chmod 600 ~/.ssh/id_ed25519 |
| La clé a fonctionné puis a cessé de fonctionner | La liste dans le panneau a été écrasée sans cette clé |
| Après une réinstallation, la clé ne fonctionne plus | La machine a été reconstruite et les clés n'y ont pas été intégrées. Ouvrez « Clés SSH » et enregistrez à nouveau la liste |
Permission denied (publickey) après la désactivation du mot de passe | La clé n'a jamais atteint la machine — connectez-vous via la console du panneau et vérifiez /root/.ssh/authorized_keys |
Diagnostic avec sortie détaillée :
ssh -v root@203.0.113.10
La sortie indique quelles clés le client a proposées et ce que le serveur a répondu.
Les utilisateurs de PuTTY ont besoin de la clé dans son propre format — voir connexion depuis PuTTY.