Créer et utiliser une clé SSH

Une clé SSH remplace le mot de passe root par un fichier que vous seul possédez. C’est la façon normale de se connecter à un serveur : plus rapide à l’usage, et beaucoup plus difficile à casser. Cette page s’adresse à toute personne qui dispose d’un VPS CloudFive et d’un accès root, quel que soit son système d’exploitation.

Prérequis : savoir déjà vous connecter à votre VPS, c’est-à-dire connaître son adresse IP et son mot de passe root. Si ce n’est pas le cas, commencez par la première connexion SSH.

Pourquoi une clé plutôt qu’un mot de passe

Une paire de clés, c’est deux fichiers :

• la clé privée (id_ed25519), qui reste sur votre ordinateur et ne doit jamais en sortir ;
• la clé publique (id_ed25519.pub), que vous copiez sur le serveur et qui peut se promener sans risque.

Le serveur vérifie que vous détenez la clé privée correspondante, sans que rien de secret ne circule sur le réseau. Plus de mot de passe à retenir ni à partager, et plus rien à deviner pour les tentatives de connexion automatiques qui visent en permanence le port 22 d’un serveur exposé sur internet. Vous pouvez aussi autoriser plusieurs clés, et en retirer une sans toucher aux autres.

Une clé par personne, pas une clé par serveur

Gardez une seule clé pour vous et installez-la sur tous vos serveurs. Si quelqu’un d’autre doit accéder au VPS, autorisez sa clé à lui : ne partagez jamais votre clé privée.

Générer une paire de clés avec ssh-keygen

À faire sur votre ordinateur, pas sur le serveur. Ouvrez un terminal : le Terminal Windows ou PowerShell sous Windows (le client OpenSSH y est inclus depuis Windows 10), Terminal sous macOS, votre émulateur habituel sous Linux.

1. Lancez la génération en remplaçant le commentaire par votre adresse e-mail (il sert uniquement à identifier la clé plus tard) :

   ssh-keygen -t ed25519 -C "prenom@exemple.fr"

2. Validez l’emplacement proposé avec Entrée : ~/.ssh/ sous Linux et macOS, C:\Users\VotreNom\.ssh\ sous Windows.

3. Saisissez une phrase de passe, deux fois. Elle chiffre la clé privée sur votre disque : si votre ordinateur est volé, la clé seule ne suffira pas.

4. Vérifiez que les deux fichiers existent :

   ls ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

Note

Si une clé id_ed25519 existe déjà, ne l’écrasez pas : elle sert peut-être pour un autre serveur. Réutilisez-la, ou créez la nouvelle sous un autre nom avec ssh-keygen -t ed25519 -f ~/.ssh/cloudfive.

Pour ne pas retaper la phrase de passe à chaque connexion, chargez la clé dans l’agent SSH avec ssh-add ~/.ssh/id_ed25519 (sous macOS, ajoutez --apple-use-keychain pour que le trousseau la retienne).

Installer sa clé publique sur le serveur

Le serveur lit les clés autorisées dans le fichier ~/.ssh/authorized_keys de l’utilisateur auquel vous vous connectez.

macOS / Linux

Une seule commande suffit. Elle vous demande une dernière fois le mot de passe root, puis installe la clé avec les bons droits :

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Windows

ssh-copy-id n’existe pas sous Windows. Cette commande fait la même chose depuis PowerShell :

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh root@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

En cas de doute, utilisez plutôt la méthode manuelle décrite juste en dessous : elle est plus longue mais vous voyez ce que vous faites.

La méthode manuelle, valable partout :

1. Affichez votre clé publique et copiez la ligne entière, de ssh-ed25519 jusqu’à votre adresse e-mail :

   cat ~/.ssh/id_ed25519.pub

2. Connectez-vous au serveur avec votre mot de passe root.

3. Créez le dossier et ouvrez le fichier des clés autorisées :

   mkdir -p ~/.ssh && chmod 700 ~/.ssh
   nano ~/.ssh/authorized_keys

4. Collez la ligne, en une seule ligne, sans retour à la ligne au milieu. Enregistrez avec Ctrl+O, puis quittez avec Ctrl+X.

5. Corrigez les droits du fichier :

   chmod 600 ~/.ssh/authorized_keys

6. Sans fermer cette session, ouvrez une nouvelle fenêtre de terminal et connectez-vous. Si la connexion aboutit sans demander le mot de passe root, c’est réussi.

Simplifier ses connexions avec ~/.ssh/config

Taper ssh root@203.0.113.10 à chaque fois est inutile. Déclarez le serveur une fois pour toutes dans ~/.ssh/config (sous Windows : C:\Users\VotreNom\.ssh\config) :

~/.ssh/config

Host mon-vps
    HostName 203.0.113.10
    User root
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

La connexion devient ssh mon-vps, et le raccourci vaut aussi pour les copies de fichiers : scp sauvegarde.tar.gz mon-vps:/root/. Ajoutez autant de blocs Host que de serveurs. IdentitiesOnly yes évite que le client ne propose toutes vos clés à la suite, cause la plus fréquente de l’erreur « Too many authentication failures ».

Désactiver l’authentification par mot de passe

Tant que le mot de passe reste accepté, la clé n’ajoute aucune protection : les tentatives automatiques visent toujours le mot de passe.

Attention

Ne faites cela qu’après avoir vérifié qu’une connexion par clé fonctionne, et gardez la session en cours ouverte pendant toute la manipulation. C’est votre filet de sécurité si la configuration est mauvaise.

1. Ouvrez la configuration du serveur SSH :

   nano /etc/ssh/sshd_config

2. Réglez ces trois directives (décommentez-les si elles commencent par #) :

   /etc/ssh/sshd_config

   PubkeyAuthentication yes
   PasswordAuthentication no
   PermitRootLogin prohibit-password

3. Vérifiez qu’aucun fichier annexe ne réautorise le mot de passe — sur plusieurs distributions, les fichiers de /etc/ssh/sshd_config.d/ sont lus en priorité :

   sshd -T | grep -iE "passwordauthentication|permitrootlogin|pubkeyauthentication"

   La sortie doit afficher passwordauthentication no. Si elle affiche yes, cherchez la directive dans /etc/ssh/sshd_config.d/ et corrigez-la là.

4. Contrôlez la syntaxe avant de redémarrer le service. Aucune sortie signifie aucune erreur :

   sshd -t

5. Redémarrez le serveur SSH. Le nom du service dépend de la distribution :

   systemctl restart ssh     # Debian, Ubuntu
   systemctl restart sshd    # AlmaLinux, Rocky Linux

6. Ouvrez une nouvelle fenêtre de terminal et reconnectez-vous. Si la connexion aboutit, fermez enfin l’ancienne session.

Votre session déjà ouverte n’est jamais coupée par un redémarrage du service SSH : seules les nouvelles connexions sont concernées.

Que faire en cas de perte de la clé privée

Vous n’êtes pas enfermé dehors : votre VPS reste accessible par sa console, qui ne passe pas par le réseau du serveur et ignore donc complètement la configuration SSH.

1. Ouvrez la console de votre VPS et connectez-vous en root avec le mot de passe. Si vous ne l’avez plus, réinitialisez-le d’abord.

2. Générez une nouvelle paire de clés sur votre ordinateur, puis recopiez la nouvelle clé publique dans ~/.ssh/authorized_keys depuis la console.

3. Au besoin, remettez temporairement PasswordAuthentication yes dans /etc/ssh/sshd_config, redémarrez le service SSH, installez la clé par le réseau, puis repassez la directive à no.

4. Supprimez la ligne de l’ancienne clé dans authorized_keys. Une clé perdue est une clé qui traîne quelque part.

Danger

La réinstallation du système n’est pas la solution à une clé perdue : elle efface le disque et toutes vos données. Ne passez par la réinstallation qu’après avoir épuisé la console et le support.

Pour ne pas revivre la situation : sauvegardez la clé privée dans votre gestionnaire de mots de passe, ou créez une seconde clé gardée ailleurs et autorisez-la elle aussi dans authorized_keys.

Si ça ne marche pas

« Permission denied (publickey) ». Le serveur n’a pas reconnu votre clé. Relancez la connexion avec ssh -v mon-vps : les lignes Offering public key indiquent quelle clé a été proposée. Vérifiez ensuite, depuis la console ou une session encore ouverte, que cat ~/.ssh/authorized_keys contient bien votre clé publique sur une seule ligne, et que vous vous connectez au bon utilisateur — une clé installée chez root ne vaut pas pour un autre compte.

La clé est ignorée et le mot de passe est redemandé. C’est presque toujours une question de droits. Depuis le serveur, lancez chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys et chmod go-w ~ : SSH refuse d’utiliser un dossier ou un répertoire personnel accessible en écriture à d’autres.

« Too many authentication failures ». Votre client propose trop de clés d’affilée. Forcez la bonne : ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 root@203.0.113.10, puis ajoutez IdentitiesOnly yes à votre ~/.ssh/config.

« UNPROTECTED PRIVATE KEY FILE ». La clé privée est lisible par d’autres comptes. Corrigez avec chmod 600 ~/.ssh/id_ed25519.

Vous utilisez PuTTY. PuTTY n’accepte pas le format d’OpenSSH : ouvrez PuTTYgen, importez votre clé privée existante, puis enregistrez-la au format .ppk et désignez ce fichier dans les réglages d’authentification de PuTTY.

La connexion n’aboutit même pas (délai dépassé, connexion refusée). Le problème n’est pas la clé : le port est fermé ou le service ne tourne pas. Reprenez le dépannage d’un VPS inaccessible et vérifiez votre pare-feu. Un avertissement sur l’empreinte du serveur, lui, est normal après une réinstallation.

Pour aller plus loin

• Première connexion SSH — les bases de la connexion et les premières vérifications.
• Réinitialiser le mot de passe root — pour reprendre la main avant d’installer une clé.
• Utiliser la console VNC — l’accès de secours qui fonctionne sans SSH.
• Configurer le pare-feu — fermer tout le reste maintenant que l’accès est propre.
• Ouvrir un ticket de support — si l’accès reste bloqué après tout ça.