Clés SSH pour les serveurs cloud : Le guide complet de configuration et de sécurité

L’authentification par clé SSH (Secure Shell) est la référence en matière de sécurisation de l’accès aux serveurs cloud. Que vous gériez une seule instance d’hébergement VPS ou une flotte entière de serveurs dédiés, remplacer les connexions par mot de passe par des paires de clés cryptographiques réduit considérablement votre surface d’attaque et simplifie les flux de travail administratifs. Ce guide complet couvre tout ce que vous devez savoir — des mécanismes sous-jacents à la configuration étape par étape et aux meilleures pratiques de renforcement.

Que sont les clés SSH ?

Les clés SSH sont des paires de clés cryptographiques asymétriques utilisées pour authentifier un client auprès d’un serveur SSH. Contrairement à une combinaison nom d’utilisateur/mot de passe — susceptible aux attaques par force brute, au credential stuffing et au phishing — les clés SSH reposent sur des relations mathématiques entre deux composants distincts :

• Clé privée : Stockée exclusivement sur votre machine locale. Ce fichier ne doit jamais être partagé, transmis ou exposé. C’est la preuve de votre identité.
• Clé publique : Déployée sur le serveur distant. Elle peut être partagée librement sans compromettre la sécurité.

Lorsque vous initiez une connexion SSH, le serveur vérifie si votre clé publique existe dans son fichier ~/.ssh/authorized_keys. Si c’est le cas, le serveur émet un défi cryptographique que seul le détenteur de la clé privée correspondante peut résoudre. Une réponse réussie accorde l’accès — sans mot de passe requis.

Pourquoi utiliser des clés SSH pour les serveurs cloud ?

L’authentification par clé SSH offre des avantages concrets et mesurables par rapport aux connexions traditionnelles par mot de passe :

Avantages clés en détail

Sécurité renforcée

Les clés SSH utilisent un chiffrement RSA de 2048 à 4096 bits (ou la cryptographie à courbe elliptique Ed25519), les rendant computationnellement impossibles à craquer. Aucun secret partagé n’est transmis sur le réseau, éliminant entièrement les risques d’interception.

Commodité opérationnelle

Une fois configurées, les clés SSH permettent des connexions sans mot de passe. Pour les administrateurs gérant plusieurs serveurs — y compris les environnements exécutant des panneaux de contrôle VPS — cela élimine la saisie répétitive des identifiants et accélère considérablement les flux de travail.

Prêt pour l’automatisation

Les pipelines CI/CD, les scripts de déploiement, les outils de gestion de configuration (Ansible, Puppet, Chef) et les tâches de sauvegarde reposent tous sur une authentification SSH non interactive. L’authentification par clé est la seule solution pratique pour ces cas d’usage.

Contrôle d’accès granulaire

Chaque utilisateur ou service reçoit une paire de clés unique. Révoquer l’accès d’un utilisateur spécifique ne nécessite rien de plus que de supprimer sa clé publique du serveur — pas de réinitialisation de mot de passe, pas de verrouillage de compte.

Comment fonctionne l’authentification par clé SSH : étape par étape

Comprendre la poignée de main d’authentification vous aide à résoudre les problèmes et à apprécier pourquoi cette méthode est si sécurisée :

1. Demande de connexion : Votre client SSH envoie une demande de connexion au serveur, indiquant quelle clé publique il a l’intention d’utiliser.
2. Recherche de clé : Le serveur recherche dans ~/.ssh/authorized_keys une clé publique correspondante.
3. Émission du défi : Si une correspondance est trouvée, le serveur génère un défi aléatoire et le chiffre à l’aide de votre clé publique.
4. Réponse au défi : Votre client SSH déchiffre le défi à l’aide de votre clé privée et renvoie une signature cryptographique dérivée des données déchiffrées.
5. Vérification et accès : Le serveur vérifie la signature à l’aide de la clé publique. Si elle est valide, l’accès est accordé — sans qu’un seul mot de passe ne soit transmis.

Cet échange complet se produit en quelques millisecondes et résiste aux attaques de type man-in-the-middle lorsque la vérification de la clé hôte est correctement configurée.

Comment générer des clés SSH

Sur Linux ou macOS

Ouvrez votre terminal et exécutez la commande suivante :

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

Détail des paramètres :

• -t rsa — Spécifie l’algorithme RSA
• -b 4096 — Génère une clé de 4096 bits (plus robuste que la valeur par défaut de 2048 bits)
• -C "your_email@example.com" — Intègre un commentaire d’identification dans la clé

Alternative moderne — Ed25519 (recommandée) :

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

Les clés Ed25519 sont plus courtes, plus rapides et considérées comme plus sécurisées que RSA-4096 pour la plupart des cas d’usage modernes.

Lors de la génération de la clé, il vous sera demandé de :

1. Choisir un emplacement de sauvegarde — Appuyez sur Enter pour accepter l’emplacement par défaut (~/.ssh/id_rsa ou ~/.ssh/id_ed25519)
2. Définir une phrase secrète — Fortement recommandé. Cela chiffre votre clé privée sur le disque, offrant une deuxième couche de protection si votre machine est compromise

Après la génération, vous aurez deux fichiers :

• ~/.ssh/id_rsa — Votre clé privée (ne jamais partager)
• ~/.ssh/id_rsa.pub — Votre clé publique (sûre à distribuer)

Sur Windows

Windows 10 et Windows 11 incluent OpenSSH nativement. Ouvrez PowerShell ou l’invite de commandes et exécutez :

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

Le processus est identique à Linux/macOS. Vos clés seront sauvegardées dans C:UsersYourUsername.ssh.

Alternative : PuTTYgen

Si vous utilisez PuTTY comme client SSH :

1. Ouvrez PuTTYgen
2. Sélectionnez RSA et définissez le nombre de bits à 4096
3. Cliquez sur Generate et déplacez votre souris pour créer de l’entropie
4. Sauvegardez la clé privée (format .ppk) et copiez le texte de la clé publique

Ajouter votre clé publique SSH au serveur cloud

Une fois votre paire de clés générée, la clé publique doit être installée sur le serveur cible.

Méthode 1 : Utilisation de ssh-copy-id (Linux/macOS — recommandée)

ssh-copy-id user@your-server-ip

Cette commande ajoute automatiquement votre clé publique à ~/.ssh/authorized_keys sur le serveur distant. Il vous sera demandé votre mot de passe une seule fois — après cela, l’accès par mot de passe n’est plus nécessaire.

Pour spécifier un fichier de clé particulier :

ssh-copy-id -i ~/.ssh/id_rsa.pub user@your-server-ip

Méthode 2 : Installation manuelle (toutes plateformes)

Utilisez cette méthode lorsque ssh-copy-id n’est pas disponible ou lorsque vous avez besoin d’un contrôle précis.

Étape 1 : Affichez votre clé publique :

cat ~/.ssh/id_rsa.pub

Copiez l’intégralité de la sortie — elle ressemblera à ceci :

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ... your_email@example.com

Étape 2 : Connectez-vous à votre serveur en utilisant l’authentification par mot de passe :

ssh user@your-server-ip

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

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

Étape 4 : Ajoutez votre clé publique au fichier authorized_keys :

nano ~/.ssh/authorized_keys

Collez la clé publique, sauvegardez et quittez (Ctrl+X, puis Y, puis Enter).

Étape 5 : Définissez les permissions de fichier correctes :

chmod 600 ~/.ssh/authorized_keys

> Critique : Des permissions incorrectes amèneront SSH à rejeter silencieusement votre clé. Le répertoire .ssh doit être 700 et authorized_keys doit être 600.

Étape 6 : Testez la connexion avant de fermer votre session actuelle :

ssh -i ~/.ssh/id_rsa user@your-server-ip

Désactiver l’authentification par mot de passe (fortement recommandé)

Une fois l’authentification par clé SSH confirmée comme fonctionnelle, désactiver les connexions par mot de passe élimine le vecteur d’attaque le plus courant contre les serveurs SSH. C’est une étape de renforcement essentielle pour tout environnement de production.

Étape 1 : Ouvrez le fichier de configuration du démon SSH :

sudo nano /etc/ssh/sshd_config

Étape 2 : Localisez et modifiez les directives suivantes :

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PermitRootLogin prohibit-password

Étape 3 : Sauvegardez le fichier et redémarrez le service SSH :

sudo systemctl restart sshd

> Avertissement : Avant de redémarrer sshd, vérifiez que votre connexion par clé SSH fonctionne dans une session de terminal séparée. Se bloquer l’accès à un serveur distant est un risque opérationnel sérieux.

Après ce changement, seuls les clients présentant une clé SSH valide et autorisée pourront se connecter.

Gestion avancée des clés SSH

Gestion de plusieurs utilisateurs

Pour accorder l’accès à plusieurs utilisateurs sur un serveur, ajoutez simplement la clé publique de chaque utilisateur sur une nouvelle ligne dans le fichier authorized_keys :

nano ~/.ssh/authorized_keys
# Add one public key per line

Révocation d’accès

Pour révoquer l’accès d’un utilisateur spécifique, ouvrez authorized_keys, localisez sa clé (identifiable par le commentaire à la fin) et supprimez cette ligne :

nano ~/.ssh/authorized_keys

Aucun redémarrage du service n’est requis — le changement prend effet immédiatement.

Utilisation d’un fichier de configuration SSH pour plusieurs serveurs

Si vous gérez plusieurs serveurs, un fichier de configuration SSH (~/.ssh/config) simplifie les connexions :

Host alexhost-vps
    HostName your-server-ip
    User root
    IdentityFile ~/.ssh/id_rsa_alexhost
    Port 22

Host alexhost-dedicated
    HostName your-dedicated-ip
    User admin
    IdentityFile ~/.ssh/id_rsa_dedicated

Avec cette configuration, se connecter est aussi simple que :

ssh alexhost-vps

Utilisation de ssh-agent pour la gestion des phrases secrètes

Si votre clé privée est protégée par une phrase secrète, ssh-agent la met en cache en mémoire afin que vous ne la saisissiez qu’une seule fois par session :

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

Meilleures pratiques de sécurité pour les clés SSH

Clés SSH et services AlexHost

L’authentification par clé SSH est prise en charge sur tous les produits serveur AlexHost. Que vous déployiez une application légère sur un hébergement web mutualisé, que vous évoluiez avec un VPS avec cPanel entièrement géré, ou que vous exécutiez des charges de travail intensives en calcul sur un hébergement GPU, l’accès par clé SSH fournit la base de sécurité dont votre infrastructure a besoin.

Pour une sécurité complète du serveur, envisagez d’associer le renforcement SSH à un certificat SSL pour chiffrer tout le trafic web — assurant une protection de bout en bout tant pour l’administration de votre serveur que pour vos utilisateurs.

Questions fréquemment posées

Puis-je utiliser plusieurs clés SSH sur le même serveur ?

Oui. Chaque clé publique occupe une ligne dans authorized_keys. Il n’y a pas de limite pratique au nombre de clés autorisées.

Que se passe-t-il si je perds ma clé privée ?

Vous perdez l’accès via cette paire de clés. Si l’authentification par mot de passe est désactivée et que vous n’avez pas d’autre méthode d’accès, vous devrez peut-être utiliser l’accès console hors bande de votre hébergeur (tel que le panneau de contrôle VPS d’AlexHost) pour récupérer l’accès et ajouter une nouvelle clé.

Ed25519 est-il meilleur que RSA ?

Pour la plupart des cas d’usage modernes, oui. Ed25519 offre une sécurité équivalente ou supérieure avec des clés plus courtes et des opérations plus rapides. RSA-4096 reste acceptable mais est considéré comme obsolète par de nombreux professionnels de la sécurité.

Dois-je utiliser la même clé SSH pour tous les serveurs ?

Non. L’utilisation de paires de clés uniques par serveur limite le rayon d’explosion — si une clé privée est compromise, seul ce serveur est en danger.

Conclusion

L’authentification par clé SSH n’est pas simplement une bonne pratique — c’est l’exigence de sécurité de base pour tout déploiement sérieux de serveur cloud. En remplaçant les connexions par mot de passe vulnérables par des paires de clés cryptographiques, vous éliminez des catégories entières d’attaques, notamment la force brute, le credential stuffing et l’interception de mots de passe.

Le processus de configuration nécessite un investissement unique modeste : générer une paire de clés, déployer la clé publique sur votre serveur, désactiver l’authentification par mot de passe et mettre en œuvre les pratiques de gestion décrites dans ce guide. Le retour sur cet investissement est une infrastructure serveur considérablement plus sécurisée, plus gérable et plus adaptée à l’automatisation.

Commencez à sécuriser vos serveurs dès aujourd’hui avec la gamme de solutions d’hébergement d’AlexHost — de l’hébergement VPS d’entrée de gamme aux serveurs dédiés haute performance — tous conçus pour prendre en charge les normes de sécurité modernes dès le premier jour.