Comment télécharger une clé publique SSH sur un VPS existant

Une clé publique SSH est un identifiant cryptographique stocké dans ~/.ssh/authorized_keys sur un serveur distant qui accorde l’accès à tout client détenant la clé privée correspondante — sans transmettre de mot de passe sur le réseau. Le téléchargement de votre clé publique sur un VPS existant remplace ou complète l’authentification par mot de passe par la cryptographie asymétrique, éliminant la surface d’attaque exploitée par les campagnes de force brute et de credential-stuffing.

Ce guide couvre chaque étape du processus : la génération de clés, les méthodes de téléchargement manuel et automatisé, le renforcement des permissions, le réglage de sshd_config, la gestion de plusieurs clés et les modes d’échec courants qui piègent même les administrateurs expérimentés.

Pourquoi l’authentification par clé SSH surpasse les mots de passe

Avant de saisir une seule commande, il vaut la peine de comprendre les mécanismes cryptographiques. Lorsque vous vous authentifiez avec une paire de clés, le serveur émet un défi chiffré avec votre clé publique. Seul le détenteur de la clé privée correspondante peut déchiffrer et signer la réponse. Aucun secret n’est jamais transmis — contrairement à l’authentification par mot de passe, où l’identifiant lui-même circule sur le réseau (même s’il est encapsulé dans TLS).

La conclusion pratique : sur tout environnement VPS Hosting exposé à l’internet public, les clés SSH ne sont pas un renforcement optionnel — elles constituent la base.

Prérequis

• Un VPS existant accessible via SSH (l’authentification par mot de passe ou par clé existante fonctionne actuellement)
• Une machine locale fonctionnant sous Linux, macOS ou Windows avec OpenSSH ou PuTTY
• Des privilèges suffisants sur le VPS pour écrire dans le répertoire personnel de l’utilisateur cible
• Une aisance de base avec un terminal et un éditeur de texte tel que nano ou vim

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

Si vous disposez déjà d’une paire de clés dans ~/.ssh/id_ed25519 ou ~/.ssh/id_rsa, passez à l’étape suivante. Sinon, générez-en une maintenant.

Choisir le bon algorithme

Ed25519 est la norme moderne. Utilisez RSA 4096 uniquement pour vous connecter à des serveurs hérités qui ne prennent pas en charge Ed25519.

Générer une paire de clés Ed25519 :

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

Générer une paire de clés RSA 4096 (systèmes hérités) :

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

Lors de la génération de la clé, vous serez invité à indiquer un chemin de sauvegarde et une phrase de passe optionnelle. Accepter le chemin par défaut (~/.ssh/id_ed25519) convient à la plupart des utilisateurs. Définissez toujours une phrase de passe — elle chiffre la clé privée sur le disque en utilisant AES-256, de sorte qu’un ordinateur portable volé ne signifie pas automatiquement un serveur compromis.

Le processus produit deux fichiers :

~/.ssh/id_ed25519 — votre clé privée. Ne la partagez jamais, ne la copiez jamais sur un serveur, ne la commitez jamais dans un système de contrôle de version.
~/.ssh/id_ed25519.pub — votre clé publique. Celle-ci peut être distribuée librement.

Affichez la clé publique pour pouvoir la copier :
cat ~/.ssh/id_ed25519.pub
La sortie ressemblera à ceci :
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
Copiez l’intégralité de la chaîne sur une seule ligne, y compris le préfixe d’algorithme et le commentaire à la fin.
Étape 2 : Se connecter à votre VPS
Connectez-vous au VPS en utilisant votre méthode d’authentification actuelle :
ssh root@your_vps_ip
Remplacez your_vps_ip par l’adresse IPv4 ou IPv6 réelle de votre serveur. Si vous gérez un compte utilisateur non-root, substituez root par le nom d’utilisateur approprié. Sur les Dedicated Servers où vous pouvez avoir plusieurs comptes utilisateurs, préférez toujours déployer les clés pour un utilisateur non-root et utiliser sudo pour l’élévation de privilèges.
Étape 3 : Préparer le répertoire .ssh
Une fois connecté, vérifiez ou créez le répertoire .ssh pour l’utilisateur cible :
mkdir -p ~/.ssh
chmod 700 ~/.ssh
La permission 700 (rwx------) est obligatoire. OpenSSH refusera silencieusement d’utiliser authorized_keys si le répertoire .ssh est accessible en écriture par le groupe ou par tous. C’est l’une des raisons les plus courantes pour lesquelles l’authentification par clé échoue après une configuration par ailleurs correcte.
Étape 4 : Ajouter la clé publique à authorized_keys
Méthode A : Collage manuel (universel)
Ouvrez ou créez le fichier authorized_keys :
nano ~/.ssh/authorized_keys
Collez votre clé publique sur une nouvelle ligne. Chaque ligne de ce fichier représente une clé autorisée. Enregistrez avec Ctrl+X, puis Y, puis Enter.
Définissez les permissions correctes :
chmod 600 ~/.ssh/authorized_keys
La permission 600 (rw-------) garantit que seul le propriétaire du fichier peut le lire ou l’écrire. OpenSSH applique cela strictement.
Méthode B : ssh-copy-id (recommandée pour la rapidité)
Si votre machine locale dispose de ssh-copy-id (standard sur Linux et macOS), cette commande unique gère automatiquement la création du répertoire, l’ajout de la clé et la définition des permissions :
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip
Vous serez invité à saisir le mot de passe SSH actuel une seule fois. Après cela, la connexion par clé est active. L’indicateur -i spécifie explicitement quelle clé publique télécharger, évitant ainsi les téléchargements accidentels de la mauvaise clé.
Méthode C : Commande unique via cat et pipe (scriptable)
Utile dans les pipelines d’automatisation ou lorsque ssh-copy-id n’est pas disponible :
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"
Cette approche est sûre en termes d’idempotence dans le sens où elle ajoute plutôt qu’elle n’écrase, préservant ainsi toutes les clés autorisées existantes.
Étape 5 : Vérifier la propriété correcte des fichiers
Un écueil souvent négligé : si vous avez créé le répertoire .ssh ou le fichier authorized_keys en tant que root lors de la configuration du compte d’un autre utilisateur, la propriété sera incorrecte et SSH rejettera silencieusement la clé.
Vérifiez la propriété :
ls -la ~/.ssh/
La sortie doit afficher le nom d’utilisateur cible comme propriétaire et groupe pour le répertoire et le fichier :
drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys
Si la propriété est incorrecte, corrigez-la (exécutez en tant que root) :
chown -R alice:alice /home/alice/.ssh
Étape 6 : Tester la connexion SSH par clé
Quittez la session actuelle :
exit
Reconnectez-vous en spécifiant explicitement la clé pour confirmer la configuration :
ssh -i ~/.ssh/id_ed25519 root@your_vps_ip
Si la connexion réussit sans invite de mot de passe (ou ne demande que la phrase de passe de votre clé locale), la configuration est correcte. Si elle demande toujours le mot de passe du serveur, passez à la section de dépannage ci-dessous.
Étape 7 : Renforcer la configuration du démon SSH
Une fois la connexion par clé confirmée comme fonctionnelle, désactivez l’authentification par mot de passe pour éliminer entièrement le vecteur d’attaque par force brute sur les mots de passe.
Ouvrez le fichier de configuration du démon SSH :
nano /etc/ssh/sshd_config
Localisez et définissez les directives suivantes. Si une ligne est commentée avec #, supprimez le # et définissez la valeur :
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes
Une note sur PermitRootLogin prohibit-password : ce paramètre autorise la connexion root exclusivement par clé, bloquant l’accès root par mot de passe tout en permettant les sessions root authentifiées par clé. Pour un renforcement maximal, définissez-le sur no et utilisez un utilisateur non-root avec sudo.
Sur certaines distributions, un fichier de configuration secondaire peut remplacer vos paramètres. Vérifiez les remplacements :
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
Si un fichier dans ce répertoire définit PasswordAuthentication yes, modifiez-le ou supprimez-le.
Validez la syntaxe de la configuration avant de redémarrer :
sshd -t
Une sortie propre (sans erreurs) signifie qu’il est sûr de recharger. Appliquez les modifications :
systemctl restart sshd
Avertissement critique : Ne fermez pas votre session SSH existante avant d’ouvrir un second terminal et de confirmer que vous pouvez toujours vous connecter avec votre clé. Redémarrer sshd avec un fichier mal configuré ou avant que votre clé ne fonctionne vous bloquera l’accès. La plupart des VPS Control Panels fournissent une console d’urgence (accès KVM/VNC) pour la récupération, mais il est bien préférable d’éviter entièrement cette situation.
Étape 8 : Gérer plusieurs clés et serveurs avec ~/.ssh/config
Lors de la gestion de plusieurs serveurs — courant dans les environnements de staging/production ou lors de l’administration de plusieurs Dedicated Servers — le fichier de configuration du client SSH élimine la nécessité de mémoriser les adresses IP, les noms d’utilisateur et les chemins de clés.
Créez ou modifiez ~/.ssh/config sur votre machine locale :
nano ~/.ssh/config
Exemple de configuration pour plusieurs hôtes :
Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa
Définissez les permissions correctes sur le fichier de configuration :
chmod 600 ~/.ssh/config
Vous pouvez maintenant vous connecter avec des alias simples :
ssh production-vps
ssh staging-vps
La directive PubkeyAcceptedKeyTypes +ssh-rsa sur l’entrée héritée est importante : les clients OpenSSH plus récents (8.8+) désactivent RSA-SHA1 par défaut. Sans cette substitution, les connexions aux serveurs plus anciens échoueront avec une erreur cryptique « no matching host key type ».
Dépannage : Pourquoi l’authentification par clé SSH échoue
Même avec une configuration correcte, plusieurs facteurs environnementaux peuvent provoquer le repli silencieux de l’authentification par clé vers des invites de mot de passe :
Permissions incorrectes sur .ssh ou authorized_keys :
Exécutez ls -la ~/.ssh/ sur le serveur. Le répertoire doit être 700 et le fichier doit être 600. Des permissions plus permissives amènent OpenSSH à ignorer le fichier.
Incompatibilité de contexte SELinux ou AppArmor :
Sur les systèmes RHEL/CentOS/AlmaLinux avec SELinux en mode enforcing, le fichier authorized_keys peut avoir un contexte de sécurité incorrect. Restaurez-le avec :
restorecon -Rv ~/.ssh
Mauvais répertoire personnel de l’utilisateur :
Si le répertoire personnel de l’utilisateur n’est pas accessible en écriture uniquement par le propriétaire, SSH refusera l’authentification par clé. Vérifiez avec :
ls -ld ~
Le répertoire personnel lui-même ne doit pas être accessible en écriture par le groupe ou par tous.
Directive AuthorizedKeysFile pointant ailleurs :
Certaines distributions configurent AuthorizedKeysFile pour utiliser un chemin non standard (par exemple, /etc/ssh/authorized_keys/%u). Vérifiez le paramètre actif :
sshd -T | grep authorizedkeysfile
Plusieurs clés et conflits ssh-agent :
Si ssh-agent s’exécute avec plusieurs clés chargées, le serveur peut rejeter la connexion après trop de tentatives de clés infructueuses avant d’essayer la bonne. Utilisez -i pour spécifier la clé explicitement, ou configurez IdentitiesOnly yes dans ~/.ssh/config.
Pare-feu ou fail2ban bloquant votre IP :
Si vous avez précédemment effectué plusieurs tentatives de connexion infructueuses, fail2ban ou les règles ufw/iptables peuvent avoir temporairement banni votre IP. Vérifiez avec :
fail2ban-client status sshd
Rotation et révocation des clés SSH
La rotation des clés est une pratique d’hygiène de sécurité souvent négligée. Pour révoquer une clé spécifique, ouvrez ~/.ssh/authorized_keys sur le serveur et supprimez la ligne correspondante. Chaque ligne est une clé — la supprimer révoque immédiatement l’accès pour le détenteur de cette clé privée sans affecter les autres clés autorisées.
À des fins d’audit, utilisez des commentaires distincts sur chaque clé (la partie après le matériel de clé, par exemple alice@workstation-2024) afin de pouvoir identifier quelle clé appartient à quelle personne ou quel appareil. Lorsqu’un employé part ou qu’un appareil est mis hors service, localisez sa clé par commentaire et supprimez-la.
Pour faire tourner votre propre clé, générez une nouvelle paire, ajoutez la nouvelle clé publique à authorized_keys, vérifiez que la connexion fonctionne avec la nouvelle clé, puis supprimez l’ancienne entrée de clé.
Liste de contrôle pratique

Générez des clés Ed25519 par défaut ; utilisez RSA 4096 uniquement pour la compatibilité avec les serveurs hérités
Protégez toujours votre clé privée avec une phrase de passe robuste
Utilisez ssh-copy-id pour un déploiement de clé rapide et sans erreur lorsque c’est possible
Vérifiez que les permissions du répertoire .ssh sont 700 et que authorized_keys est 600

FAQ

Puis-je ajouter plusieurs clés publiques SSH au même compte utilisateur VPS ?

Oui. Chaque ligne dans ~/.ssh/authorized_keys est une clé autorisée indépendante. Ajoutez une clé par ligne. C’est l’approche standard pour accorder l’accès à plusieurs administrateurs ou depuis plusieurs appareils — chaque personne ou appareil détient une clé privée unique, et la révocation se fait par ligne.

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’utiliser l’accès console hors bande de votre hébergeur (KVM/VNC), disponible via la plupart des panneaux de contrôle VPS Hosting. Depuis la console, réactivez PasswordAuthentication yes dans /etc/ssh/sshd_config, redémarrez sshd, et téléchargez une nouvelle clé. C’est pourquoi tester la connexion par clé avant de désactiver les mots de passe est non négociable.

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

Ed25519 nécessite OpenSSH 6.5 ou une version ultérieure (publiée en 2014). Toute distribution Linux moderne — Ubuntu 18.04+, Debian 9+, CentOS 7+, AlmaLinux 8+ — le prend en charge nativement. Seuls les systèmes véritablement anciens nécessitent un repli sur RSA.

Dois-je utiliser la même paire de clés SSH pour chaque serveur que je gère ?

C’est pratique opérationnellement mais crée un point de compromission unique. Une meilleure pratique consiste à utiliser une paire de clés par rôle ou environnement (par exemple, une clé pour les serveurs personnels, une pour l’infrastructure client). Cela limite le rayon d’impact si une clé privée venait à être exposée.

Le téléchargement d’une clé SSH affecte-t-il mes SSL Certificates ou la configuration de mon serveur web ?

Non. Les clés SSH régissent l’accès terminal au système d’exploitation et sont entièrement distinctes des certificats TLS/SSL utilisés par les serveurs web (Apache, Nginx) pour HTTPS. Ils utilisent des ports différents (22 vs. 443), des formats de clés différents et des chaînes de confiance différentes. Modifier l’un n’a aucun effet sur l’autre.