Comment ajouter des clés SSH à un VPS nouveau ou existant

Les clés SSH sont des paires de clés cryptographiques — une clé publique stockée sur le serveur et une clé privée conservée sur votre machine locale — qui authentifient votre identité sans transmettre de mot de passe sur le réseau. Lors de la connexion, le serveur émet un défi cryptographique que seule votre clé privée peut résoudre, accordant l’accès si la réponse est valide. Ce mécanisme rend l’authentification par clé SSH fondamentalement plus résistante aux attaques par force brute, au credential stuffing et à l’interception par attaque de l’homme du milieu que tout système basé sur un mot de passe.

Ce guide couvre le processus complet de génération, de déploiement et de renforcement de l’authentification par clé SSH sur des instances VPS nouvelles et existantes — y compris les cas particuliers, les pièges liés aux permissions et la gestion de plusieurs clés que la plupart des tutoriels ignorent complètement.

Pourquoi les clés SSH sont architecturalement supérieures aux mots de passe

L’authentification par mot de passe envoie un secret (ou son hachage) sur le réseau et repose sur le serveur qui stocke un identifiant vérifiable. L’authentification par clé publique SSH n’expose jamais la clé privée — ni lors de la génération, ni lors de la connexion, ni jamais. La clé privée ne quitte jamais votre machine locale.

Au-delà de la sécurité brute, les clés SSH débloquent des capacités opérationnelles que les mots de passe ne peuvent pas offrir :

• Automatisation sans surveillance — Les pipelines CI/CD, les playbooks Ansible et les tâches rsync pilotées par cron nécessitent une authentification non interactive. Les mots de passe rendent cela totalement impossible.
• Contrôle d’accès granulaire — Chaque entrée authorized_keys peut comporter des restrictions command=, from= et no-pty, limitant précisément ce qu’une clé donnée est autorisée à faire.
• Auditabilité — Les clés individuelles peuvent être révoquées sans changer un mot de passe partagé et sans perturber tous les autres utilisateurs ou scripts.
• Résistance au phishing — Il n’y a pas de mot de passe à voler via une fausse page de connexion.

Prérequis

Avant de continuer, confirmez les points suivants :

• Vous disposez d’un VPS en cours d’exécution ou êtes en train d’en provisionner un.
• Votre machine locale fonctionne sous Linux, macOS ou Windows avec OpenSSH installé (Windows 10/11 est livré avec OpenSSH par défaut ; vérifiez avec ssh -V).
• Vous disposez d’un accès root ou sudo sur le serveur cible.
• Vous comprenez que la perte de votre clé privée sans méthode de connexion alternative (accès console, clé de récupération) peut vous bloquer définitivement.

Choisir le bon algorithme de clé

La commande ssh-keygen -t rsa -b 4096 originale est solide mais n’est pas la seule option. Comprendre les compromis vous aide à faire le bon choix pour votre environnement.

Ed25519 est l’algorithme recommandé pour tout serveur exécutant OpenSSH 6.5 ou ultérieur (publié en 2014). Utilisez RSA 4096 uniquement lors de la connexion à des systèmes legacy qui ne prennent pas en charge les clés à courbe elliptique.

Partie 1 : Ajouter des clés SSH à un nouveau VPS

De nombreux panneaux de contrôle d’hébergement vous permettent d’injecter une clé publique au moment du provisionnement, avant même que l’instance ne démarre. C’est l’approche la plus propre — la clé est intégrée dans l’image et l’authentification par mot de passe peut ne jamais avoir besoin d’être activée.

Étape 1 : Générer votre paire de clés SSH

Ouvrez un terminal sur votre machine locale. Générez une paire de clés Ed25519 :

ssh-keygen -t ed25519 -C "your_email@example.com"

Si vous avez besoin de RSA pour des raisons de compatibilité :

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Lorsqu’on vous demande un emplacement de fichier, appuyez sur Entrée pour accepter la valeur par défaut (~/.ssh/id_ed25519 ou ~/.ssh/id_rsa). Lorsqu’on vous demande une phrase secrète, définissez-en une — elle chiffre la clé privée sur le disque, de sorte que même si votre ordinateur portable est volé, la clé est inutilisable sans la phrase secrète. Votre agent SSH (ssh-agent) mettra en cache la clé déchiffrée en mémoire afin que vous ne saisissiez la phrase secrète qu’une seule fois par session.

Vérifiez les fichiers générés :

ls -la ~/.ssh/

Vous verrez :

• id_ed25519 — votre clé privée (les permissions doivent être 600 ; ne partagez jamais ce fichier)
• id_ed25519.pub — votre clé publique (peut être copiée en toute sécurité n’importe où)

Affichez la clé publique pour la copier :

cat ~/.ssh/id_ed25519.pub

La sortie ressemble à :

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Copiez cette chaîne entière — vous la collerez dans votre panneau d’hébergement.

Étape 2 : Ajouter la clé publique lors du provisionnement du VPS

Connectez-vous à votre panneau de contrôle d’hébergement. Lors du processus de création du VPS :

1. Sélectionnez votre système d’exploitation (Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9, etc.).
2. Localisez la section Clé SSH ou Authentification.
3. Collez le contenu complet de id_ed25519.pub dans le champ prévu.
4. Complétez la configuration restante (plan, région, nom d’hôte).

Une fois le VPS démarré, le système de provisionnement écrit automatiquement votre clé publique dans /root/.ssh/authorized_keys. Aucune connexion par mot de passe n’est requise.

Étape 3 : Se connecter au VPS nouvellement provisionné

ssh root@your_vps_ip

Si vous avez utilisé un nom de fichier de clé non standard, spécifiez-le explicitement :

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Une connexion réussie sans invite de mot de passe confirme que la clé a été injectée correctement. Si vous avez défini une phrase secrète, votre agent SSH ou une invite de phrase secrète s’en chargera localement.

Partie 2 : Ajouter des clés SSH à un VPS existant

Si votre VPS fonctionne déjà avec l’authentification par mot de passe, vous devez déployer manuellement la clé publique. Il s’agit d’un processus en deux phases : copier la clé, puis optionnellement renforcer le démon SSH.

Étape 1 : Générer une paire de clés (si vous n’en avez pas)

Suivez le même processus que l’étape 1 de la partie 1 ci-dessus. Si vous avez déjà une paire de clés, récupérez votre clé publique :

cat ~/.ssh/id_ed25519.pub

Étape 2 : Copier la clé publique sur le serveur

Méthode A — ssh-copy-id (Recommandée)

L’utilitaire ssh-copy-id gère automatiquement la création de répertoires, l’ajout de fichiers et la définition des permissions :

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

Saisissez votre mot de passe lorsqu’on vous le demande. L’outil ajoute la clé à ~/.ssh/authorized_keys sur le serveur distant et définit les permissions correctes. C’est la méthode la plus sûre car elle évite l’écrasement accidentel des clés existantes.

Méthode B — Déploiement manuel

Utilisez cette méthode lorsque ssh-copy-id n’est pas disponible (par exemple, dans certains environnements Windows ou réseaux restreints) :

cat ~/.ssh/id_ed25519.pub | ssh root@your_vps_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Ce pipeline unique est plus sûr que d’ouvrir un éditeur de texte sur le serveur distant car il ajoute plutôt qu’il n’écrase.

Méthode C — Manuel via éditeur de texte (solution de secours)

Connectez-vous au serveur avec votre mot de passe :

ssh root@your_vps_ip

Créez le répertoire .ssh s’il n’existe pas :

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Ouvrez authorized_keys dans un éditeur de texte :

nano ~/.ssh/authorized_keys

Collez votre clé publique sur une nouvelle ligne. Enregistrez avec Ctrl+X, puis Y, puis Enter. Définissez les permissions :

chmod 600 ~/.ssh/authorized_keys

Fermez la session :

exit

Étape 3 : Vérifier la connexion par clé

Testez la connexion avant d’apporter d’autres modifications au démon SSH. Ouvrez une nouvelle fenêtre de terminal (ne fermez pas votre session existante) :

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Si vous vous connectez sans invite de mot de passe, la clé fonctionne. Ne procédez aux étapes de renforcement ci-dessous qu’après avoir confirmé cela.

Piège critique : Si vous désactivez l’authentification par mot de passe avant de vérifier l’accès par clé, et que le déploiement de la clé a échoué pour une raison quelconque, vous vous bloquerez. Testez toujours en premier.

Étape 4 : Renforcer la configuration du démon SSH

Une fois l’accès par clé confirmé, ouvrez le fichier de configuration du démon SSH :

nano /etc/ssh/sshd_config

Appliquez les paramètres suivants :

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes

Notes importantes sur ces directives :

• PermitRootLogin prohibit-password autorise la connexion root via clé mais bloque la connexion root par mot de passe — un meilleur compromis que PermitRootLogin no lorsque vous configurez encore un utilisateur sudo non-root.
• ChallengeResponseAuthentication no désactive l’authentification interactive au clavier, qui peut contourner PasswordAuthentication no sur certaines configurations PAM.
• Sur Ubuntu 22.04+, le fichier /etc/ssh/sshd_config.d/50-cloud-init.conf peut remplacer vos paramètres. Vérifiez-le et modifiez-le si nécessaire.

Validez la syntaxe de la configuration avant de redémarrer :

sshd -t

Si aucune erreur n’est signalée, redémarrez le service SSH :

systemctl restart sshd

Sur les systèmes utilisant ssh.service au lieu de sshd.service :

systemctl restart ssh

Gestion de plusieurs clés SSH et utilisateurs

Les environnements réels impliquent rarement une seule clé et un seul utilisateur. Voici comment gérer des scénarios plus complexes.

Ajouter des clés pour plusieurs utilisateurs

Chaque compte utilisateur possède son propre fichier ~/.ssh/authorized_keys. Pour ajouter une clé pour un utilisateur non-root nommé deploy :

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
echo "ssh-ed25519 AAAAC3... deploy@ci-server" >> /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

L’étape chown est fréquemment oubliée et provoque des échecs d’authentification — SELinux et OpenSSH vérifient tous deux que le fichier authorized_keys appartient à l’utilisateur qui s’authentifie.

Restreindre ce qu’une clé peut faire

Vous pouvez préfixer n’importe quelle ligne dans authorized_keys avec des options pour limiter ses capacités. Ceci est particulièrement utile pour les clés de déploiement ou l’automatisation des sauvegardes :

command="/usr/bin/rsync --server --daemon .",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3... backup@monitoring

Cette clé ne peut exécuter que rsync en mode démon — rien d’autre.

Utiliser ~/.ssh/config pour des connexions plus propres

Au lieu de saisir de longues commandes ssh, définissez des alias d’hôtes sur votre machine locale :

Host myserver
    HostName 203.0.113.45
    User root
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Après avoir enregistré ceci dans ~/.ssh/config, connectez-vous simplement avec :

ssh myserver

Utiliser ssh-agent pour mettre en cache les phrases secrètes

Si votre clé privée a une phrase secrète (ce qui devrait être le cas), ajoutez-la à l’agent pour ne pas être invité à la saisir à répétition :

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Sur macOS, ajoutez --apple-use-keychain pour persister après les redémarrages :

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Pièges courants et dépannage

Problème : Toujours invité à saisir un mot de passe après avoir ajouté la clé

Exécutez la connexion avec une sortie détaillée pour diagnostiquer :

ssh -vvv root@your_vps_ip

Recherchez des lignes comme Offering public key et Server accepts key. Si la clé est proposée mais rejetée, le problème est presque toujours lié aux permissions des fichiers sur le serveur.

Vérifiez les permissions sur le serveur :

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Permissions requises :

• ~/.ssh/ — 700 (drwx——)
• ~/.ssh/authorized_keys — 600 (-rw——-)
• Répertoire personnel ~/ — ne doit pas être accessible en écriture par tous (755 ou 750)

Problème : SELinux bloquant l’authentification sur RHEL/Rocky/AlmaLinux

restorecon -Rv ~/.ssh

Problème : Le fichier authorized_keys a des fins de ligne Windows (CRLF)

Si vous avez modifié le fichier sous Windows et l’avez transféré, les fins de ligne peuvent être corrompues. Corrigez avec :

sed -i 's/r//' ~/.ssh/authorized_keys

Problème : Mauvaise clé proposée

Si vous avez plusieurs clés, spécifiez explicitement la bonne :

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Ou configurez-la dans ~/.ssh/config comme indiqué ci-dessus.

Les clés SSH dans le contexte de votre infrastructure d’hébergement

L’authentification par clé SSH n’est pas seulement une préoccupation pour un seul serveur — elle s’étend à toute votre infrastructure. Si vous gérez un parc de serveurs dédiés, une approche centralisée utilisant des outils comme Ansible, Puppet ou un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager) pour distribuer et faire tourner les clés autorisées est essentielle.

Pour les équipes exécutant des applications web sur un VPS avec cPanel, l’interface Accès SSH de cPanel dans la section Sécurité fournit une interface graphique pour générer et gérer les paires de clés — utile pour les développeurs qui ne sont pas à l’aise avec la ligne de commande mais ont tout de même besoin d’un accès sécurisé.

Si vous exécutez des charges de travail intensives en GPU sur une infrastructure d’hébergement GPU, l’authentification par clé SSH est particulièrement critique car ces instances exécutent souvent des tâches longues et sans surveillance. Un identifiant compromis sur un serveur GPU peut entraîner des coûts de calcul non autorisés significatifs en plus de l’exposition des données.

Associer le renforcement SSH à un certificat SSL valide sur tous les services web exposés fonctionnant sur le même serveur ferme simultanément les deux vecteurs d’attaque les plus courants — l’accès shell non authentifié et le trafic HTTP non chiffré.

Pour les projets utilisant un hébergement web mutualisé qui nécessitent également un accès SSH, vérifiez si votre fournisseur prend en charge l’injection de clé SSH via le panneau d’hébergement, car les environnements mutualisés restreignent souvent SSH à des utilisateurs spécifiques avec un accès shell limité.

Rotation des clés et gestion des clés à long terme

Les clés SSH n’expirent pas automatiquement. Sans politique de rotation, une clé compromise il y a des années peut encore accorder l’accès. Établissez ces pratiques :

• Faites tourner les clés annuellement ou immédiatement en cas de suspicion de compromission.
• Auditez les fichiers authorized_keys sur tous les serveurs régulièrement. Supprimez les clés appartenant à d’anciens employés ou à des services désaffectés.
• Utilisez des clés séparées par appareil — ne copiez pas la même clé privée sur plusieurs ordinateurs portables ou serveurs. Si un appareil est perdu, vous ne révoquez que cette clé.
• Utilisez des clés séparées par rôle — votre clé d’accès personnel, votre clé de déploiement CI/CD et votre clé d’automatisation des sauvegardes doivent toutes être distinctes.
• Documentez la propriété des clés — maintenez un registre associant chaque empreinte de clé publique à son propriétaire, son objectif et sa date d’expiration.

Pour afficher l’empreinte d’une clé à des fins d’audit :

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Liste de contrôle des décisions techniques

Utilisez cette matrice avant de finaliser votre configuration de clé SSH :

• Algorithme : Utilisez Ed25519 sauf si vous vous connectez à des systèmes antérieurs à OpenSSH 6.5 ; utilisez RSA 4096 comme solution de secours.
• Phrase secrète : Définissez-en toujours une sur les clés privées utilisées par des humains ; les clés de service utilisées par l’automatisation peuvent s’en passer si elles sont stockées dans un gestionnaire de secrets.
• Méthode de déploiement : Utilisez ssh-copy-id pour les configurations interactives ; utilisez la gestion de configuration (Ansible, Puppet) pour les déploiements en parc.
• Vérification des permissions : Confirmez 700 sur ~/.ssh/, 600 sur authorized_keys, et la propriété correcte avant de désactiver l’authentification par mot de passe.
• Testez avant de verrouiller : Vérifiez toujours la connexion par clé dans une session de terminal séparée avant de définir PasswordAuthentication no.
• Validation de la configuration du démon : Exécutez sshd -t avant de redémarrer le service SSH pour détecter les erreurs de syntaxe.
• Désactiver l’authentification par mot de passe : Définissez PasswordAuthentication no et ChallengeResponseAuthentication no ensemble — l’un seul est insuffisant sur les systèmes avec PAM activé.
• Politique de connexion root : Préférez PermitRootLogin prohibit-password à PermitRootLogin yes ; migrez vers un utilisateur sudo non-root et définissez PermitRootLogin no comme état final renforcé.
• Rotation des clés : Planifiez une rotation annuelle ; révoquez immédiatement en cas de perte d’appareil ou de changement de personnel.
• Audit : Exécutez périodiquement grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys pour examiner toutes les clés autorisées sur le système.

FAQ

Puis-je ajouter plusieurs clés SSH au même serveur ?

Oui. Chaque ligne dans ~/.ssh/authorized_keys représente une clé publique autorisée. Vous pouvez ajouter autant de clés que nécessaire — une par ligne. Cela permet à plusieurs administrateurs ou plusieurs appareils de s’authentifier indépendamment, et vous pouvez révoquer n’importe quelle clé en supprimant sa ligne sans affecter les autres.

Que se passe-t-il si je perds ma clé privée après avoir désactivé l’authentification par mot de passe ?

Vous serez bloqué hors de SSH. La récupération nécessite d’accéder au serveur via une méthode hors bande : la console web de votre fournisseur d’hébergement, VNC ou un environnement de démarrage de secours/récupération. De là, vous pouvez réactiver l’authentification par mot de passe ou ajouter une nouvelle clé publique. C’est pourquoi il est essentiel de conserver les identifiants d’accès à la console en sécurité et séparément.

Ed25519 est-il pris en charge sur tous les serveurs ?

Ed25519 nécessite OpenSSH 6.5 ou ultérieur, publié en janvier 2014. Tout serveur exécutant une distribution Linux moderne (Ubuntu 18.04+, Debian 9+, CentOS 7+, Rocky Linux 8+) le prend en charge. Le seul scénario nécessitant RSA est la connexion à des systèmes genuinement legacy ou à des appareils embarqués avec des versions OpenSSH obsolètes.

L’ajout d’une clé SSH désactive-t-il automatiquement la connexion par mot de passe ?

Non. L’ajout d’une clé à authorized_keys active la connexion par clé mais ne désactive pas l’authentification par mot de passe. Vous devez explicitement définir PasswordAuthentication no dans /etc/ssh/sshd_config et redémarrer le démon SSH pour imposer un accès par clé uniquement.

Puis-je utiliser la même paire de clés SSH pour plusieurs serveurs ?

Techniquement oui, mais ce n’est pas recommandé pour les environnements de production. Utiliser une seule clé sur de nombreux serveurs signifie que compromettre une clé privée accorde l’accès à tous. La meilleure pratique est d’utiliser des clés par appareil (une clé par poste de travail ou ordinateur portable) afin que la perte d’un appareil nécessite de révoquer uniquement cette clé sur votre parc de serveurs, plutôt que de remplacer les clés partout simultanément.