Comment créer des clés SSH avec OpenSSH sur macOS ou Linux

L’authentification SSH par clé est la méthode standard du secteur pour sécuriser l’accès distant aux serveurs. Au lieu de transmettre un mot de passe sur le réseau, votre client prouve son identité en résolvant un défi cryptographique auquel seul le détenteur de la clé privée peut répondre — le serveur ne voit jamais la clé privée elle-même.

Une paire de clés SSH se compose de deux fichiers mathématiquement liés : une clé privée (stockée exclusivement sur votre machine locale, jamais partagée) et une clé publique (déployée sur chaque serveur auquel vous devez accéder). Lorsque vous initiez une connexion, OpenSSH utilise un protocole d’échange défi-réponse pour vérifier que votre clé privée correspond à la clé publique sur le serveur, accordant l’accès sans invite de mot de passe.

Pourquoi les clés SSH sont strictement supérieures à l’authentification par mot de passe

Les mots de passe sont vulnérables aux attaques par force brute, au credential stuffing, au phishing et à l’interception sur des réseaux mal configurés. Les clés SSH éliminent simultanément chacun de ces vecteurs d’attaque.

• Force cryptographique : Une clé RSA de 4096 bits ou une clé Ed25519 est computationnellement infaisable à forcer par force brute avec le matériel actuel.
• Aucun secret transmis sur le réseau : La clé privée ne quitte jamais votre machine. Le protocole d’authentification prouve la possession sans divulgation.
• Prêt pour l’automatisation : Les pipelines CI/CD, les playbooks Ansible, les tâches rsync et les sauvegardes basées sur cron nécessitent tous une authentification non interactive. Les clés SSH rendent cela possible sans intégrer de mots de passe en clair dans les scripts.
• Auditabilité : Chaque paire de clés peut être identifiée de manière unique par son empreinte, ce qui permet de révoquer facilement une seule clé compromise sans faire tourner les identifiants partout.
• Compatibilité avec les ACL authorized_keys : Vous pouvez restreindre une clé publique spécifique pour n’exécuter qu’une seule commande, la lier à une IP source, ou empêcher la redirection de port — des contrôles que l’authentification par mot de passe ne peut pas répliquer.

Si vous gérez un VPS ou un serveur dédié, désactiver entièrement l’authentification par mot de passe et imposer la connexion par clé uniquement est l’une des mesures de renforcement de la sécurité ayant le plus grand impact que vous puissiez prendre.

Choisir le bon algorithme de clé

La documentation OpenSSH originale et la plupart des tutoriels hérités utilisent RSA par défaut. Le domaine a évolué. Voici une comparaison précise de chaque algorithme pris en charge par ssh-keygen aujourd’hui :

Ed25519 est le choix par défaut correct en 2024. Il produit des clés plus courtes, signe plus rapidement, et sa taille de clé fixe élimine le risque de générer accidentellement une clé de taille insuffisante. RSA à 4096 bits reste acceptable pour les environnements qui doivent interopérer avec des systèmes plus anciens antérieurs à la prise en charge d’Ed25519 (OpenSSH < 6.5, publié en 2014).

Prérequis

• Un poste de travail macOS ou Linux avec OpenSSH installé. Les deux systèmes d’exploitation livrent OpenSSH par défaut. Vérifiez avec :

ssh -V

• Accès réseau à un serveur distant sur lequel vous disposez d’un compte (root ou non privilégié).
• Familiarité de base avec un terminal.

Sur les distributions Linux qui livrent une installation minimale (Alpine, certaines installations réseau Debian), installez les outils client avec :

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Étape 1 : Ouvrir un terminal

macOS : Appuyez sur Cmd + Space, tapez Terminal, et appuyez sur Entrée. Vous pouvez également naviguer vers Applications > Utilitaires > Terminal. Les utilisateurs avancés peuvent utiliser iTerm2 ou le terminal intégré dans VS Code.

Linux : Appuyez sur Ctrl + Alt + T sur la plupart des environnements de bureau, ou lancez l’émulateur de terminal de votre distribution depuis le menu des applications.

Étape 2 : Générer la paire de clés SSH

Générer une clé Ed25519 (recommandé)

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

Le drapeau -C ajoute un commentaire lisible par l’homme à la clé publique. Utilisez votre adresse e-mail, un nom d’hôte, ou une étiquette descriptive comme "deploy-key-prod" — il n’a aucune fonction cryptographique mais est inestimable lors de l’audit des fichiers authorized_keys qui accumulent des dizaines d’entrées.

Générer une clé RSA (compatibilité héritée)

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

Utilisez -b 4096 explicitement. La valeur par défaut historique de 2048 bits est encore techniquement acceptable mais offre moins de marge face aux avancées futures des algorithmes de factorisation. N’utilisez jamais -b 1024 ou -b 2048 pour de nouvelles clés si 4096 est disponible.

Générer une clé nommée pour un hôte spécifique

Lors de la gestion de plusieurs serveurs ou rôles, utilisez des fichiers de clés distincts plutôt que de réutiliser une seule clé partout. Une clé compromise n’affecte alors que les systèmes sur lesquels elle a été déployée :

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Étape 3 : Choisir un emplacement de stockage

Après avoir exécuté ssh-keygen, vous verrez :

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Appuyez sur Entrée pour accepter la valeur par défaut (~/.ssh/id_ed25519 pour Ed25519, ~/.ssh/id_rsa pour RSA), ou tapez un chemin personnalisé. L’emplacement par défaut convient pour une seule clé à usage général. Pour les clés spécifiques à un rôle, spécifiez toujours un nom de fichier descriptif comme indiqué à l’étape précédente.

Note critique sur les permissions de fichiers : Le répertoire ~/.ssh/ doit être en mode 700 et les fichiers de clés privées doivent être en mode 600. OpenSSH refusera d’utiliser des clés avec des permissions trop permissives et affichera un avertissement. Si vous copiez des clés entre machines, vérifiez immédiatement les permissions :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Étape 4 : Définir une phrase secrète

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Une phrase secrète chiffre le fichier de clé privée sur le disque en utilisant AES-256-CBC (dans OpenSSH moderne). Si un attaquant obtient votre fichier de clé privée — via un ordinateur portable volé, une sauvegarde compromise, ou un snapshot cloud mal configuré — une phrase secrète robuste est la dernière ligne de défense l’empêchant de l’utiliser.

Quand ignorer la phrase secrète : Les comptes de service automatisés (pipelines de déploiement, agents de sauvegarde) qui s’exécutent sans surveillance ont légitimement besoin de clés sans phrase secrète. Dans ce cas, restreignez les permissions de la clé côté serveur en utilisant les options authorized_keys (voir la section avancée ci-dessous) et stockez la clé privée dans un gestionnaire de secrets plutôt que sur un système de fichiers partagé.

Après confirmation de la phrase secrète, OpenSSH affiche l’empreinte de la clé et une image randomart :

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Notez l’empreinte. Vous l’utiliserez pour vérifier l’identité de la clé lors de l’audit des serveurs.

Étape 5 : Copier la clé publique sur le serveur distant

Méthode 1 : ssh-copy-id (La plus rapide)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

Le drapeau -i spécifie explicitement quelle clé publique copier, empêchant ssh-copy-id de télécharger toutes les clés de votre agent. Vous serez invité à entrer le mot de passe du serveur une seule fois. L’outil gère automatiquement la création de répertoires, l’ajout de fichiers et la définition des permissions.

Méthode 2 : Déploiement manuel (quand ssh-copy-id n’est pas disponible)

C’est l’approche correcte lorsque le système distant est Windows, un périphérique réseau, ou un conteneur sans ssh-copy-id dans le chemin.

Tout d’abord, affichez votre clé publique :

cat ~/.ssh/id_ed25519.pub

Copiez l’intégralité de la sortie — c’est une seule ligne commençant par ssh-ed25519 (ou ssh-rsa). Connectez-vous ensuite au serveur et ajoutez-la :

ssh user@your-server.com

Une fois connecté :

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Erreur courante : Utiliser > au lieu de >> écrase l’intégralité du fichier authorized_keys, verrouillant toutes les autres clés. Utilisez toujours >> pour ajouter.

Méthode 3 : Redirection via SSH en une seule commande

Si vous avez déjà un accès par mot de passe et souhaitez déployer sans vous connecter de manière interactive :

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Étape 6 : Tester la connexion

ssh -i ~/.ssh/id_ed25519 user@your-server.com

Une connexion réussie sans invite de mot de passe (ou avec seulement une invite de phrase secrète pour votre clé locale) confirme que la configuration est correcte. Si la connexion échoue, exécutez avec une sortie détaillée pour diagnostiquer :

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

Le drapeau -vvv affiche le journal complet de négociation, montrant exactement quelle clé a été proposée, si le serveur l’a acceptée, et où la poignée de main a échoué.

Étape 7 : Configurer ~/.ssh/config pour des profils d’hôtes persistants

Taper la commande complète ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45 à chaque fois est source d’erreurs et lent. Le fichier de configuration du client SSH élimine ce problème :

nano ~/.ssh/config

Ajoutez un bloc d’hôte :

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Connectez-vous maintenant simplement avec :

ssh prod-web

Ce modèle s’adapte proprement à des dizaines de serveurs et est essentiel pour tout ingénieur gérant une infrastructure à grande échelle. La directive ServerAliveInterval 60 envoie un paquet keepalive toutes les 60 secondes, empêchant les connexions inactives d’être interrompues par les pare-feux — une frustration courante chez les fournisseurs cloud.

Gérer plusieurs clés avec l’agent SSH

L’agent SSH conserve les clés privées déchiffrées en mémoire pendant la durée de votre session, de sorte que vous n’entrez la phrase secrète qu’une seule fois plutôt qu’à chaque connexion.

Démarrez l’agent et ajoutez une clé :

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

Sur macOS, vous pouvez conserver les clés entre les redémarrages en ajoutant ce qui suit à ~/.ssh/config :

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

La directive UseKeychain yes s’intègre au trousseau macOS, stockant la phrase secrète de manière sécurisée afin qu’elle survive aux redémarrages du système.

Listez toutes les clés actuellement chargées dans l’agent :

ssh-add -l

Supprimez une clé spécifique de l’agent :

ssh-add -d ~/.ssh/id_ed25519

Avancé : Restreindre les clés dans authorized_keys

Le fichier authorized_keys prend en charge des options par clé qui réduisent considérablement le rayon d’impact d’une clé compromise. Celles-ci sont placées avant le type de clé sur la même ligne :

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

Ces options sont particulièrement précieuses pour les clés de déploiement sur des serveurs dédiés où une seule clé CI/CD compromise ne devrait pas accorder un accès shell complet.

Renforcement du démon SSH après le déploiement des clés

Une fois l’authentification par clé fonctionnelle, désactivez entièrement l’authentification par mot de passe sur le serveur. Modifiez /etc/ssh/sshd_config :

sudo nano /etc/ssh/sshd_config

Définissez les directives suivantes :

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Rechargez le démon sans déconnecter votre session actuelle :

sudo systemctl reload sshd

Ne fermez pas votre session SSH existante avant de tester une nouvelle connexion dans un terminal séparé. Une mauvaise configuration qui vous bloque est récupérable depuis la console, mais elle est perturbatrice et évitable.

Pour les serveurs exécutant des environnements cPanel VPS, sachez que certaines versions de cPanel gèrent leur propre configuration SSH. Vérifiez que les modifications de sshd_config persistent après les mises à jour de cPanel en vérifiant /etc/ssh/sshd_config.d/ pour les fichiers de remplacement.

Rotation et révocation des clés SSH

La rotation des clés est une pratique d’hygiène de sécurité qui limite la fenêtre d’exposition si une clé est silencieusement compromise. Un calendrier de rotation pratique est tous les 12 mois pour les clés personnelles et tous les 90 jours pour les clés de comptes de service.

Pour révoquer une clé : Supprimez sa ligne de ~/.ssh/authorized_keys sur chaque serveur où elle a été déployée. Il n’existe pas de mécanisme de révocation central dans OpenSSH standard — c’est pourquoi maintenir un inventaire de l’endroit où chaque empreinte de clé est déployée est important.

Pour faire tourner une clé :

1. Générez une nouvelle paire de clés.
2. Déployez la nouvelle clé publique sur tous les serveurs cibles.
3. Testez la connectivité avec la nouvelle clé.
4. Supprimez l’ancienne clé publique de tous les fichiers authorized_keys.
5. Supprimez ou archivez l’ancienne clé privée localement.

Pour les environnements avec un hébergement VPS dans plusieurs régions, un outil de gestion de configuration comme Ansible est la solution pratique pour propager les rotations de clés à grande échelle.

Transférer des clés entre machines

Lorsque vous configurez un nouveau poste de travail, vous devez migrer vos clés privées existantes plutôt que d’en générer de nouvelles (ce qui nécessiterait de redéployer les clés publiques partout).

Copiez la clé privée de manière sécurisée en utilisant scp ou rsync via SSH :

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Vous pouvez également utiliser une clé USB chiffrée ou un gestionnaire de mots de passe prenant en charge le stockage des clés SSH (1Password, Bitwarden et HashiCorp Vault le prennent tous en charge). N’envoyez jamais de clés privées par e-mail et ne les stockez pas dans un stockage cloud non chiffré.

Après le transfert, vérifiez immédiatement les permissions sur la nouvelle machine :

chmod 600 ~/.ssh/id_ed25519

Vérifier l’empreinte de la clé d’hôte d’un serveur

La première fois que vous vous connectez à un serveur, OpenSSH présente l’empreinte de la clé d’hôte du serveur et vous demande de la confirmer :

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Ne tapez jamais yes aveuglément. Obtenez l’empreinte attendue via un canal hors bande — le panneau de contrôle de votre hébergeur, un collègue qui a provisionné le serveur, ou la sortie console du serveur. Cette étape prévient les attaques de type homme du milieu. Pour les environnements d’hébergement mutualisé, l’empreinte attendue est généralement répertoriée dans le panneau de contrôle sous les paramètres d’accès SSH.

Une fois acceptée, l’empreinte est stockée dans ~/.ssh/known_hosts. Si l’empreinte change de manière inattendue lors d’une connexion ultérieure, OpenSSH refusera de se connecter et affichera un avertissement — traitez cela comme un événement de sécurité grave nécessitant une investigation avant de continuer.

Matrice de décision et liste de contrôle technique

Utilisez cette liste de contrôle avant de considérer votre configuration de clés SSH prête pour la production :

• [ ] L’algorithme de clé est Ed25519 (ou RSA 4096 pour la compatibilité héritée) — DSA et ECDSA 256 ne sont pas acceptables pour les nouveaux déploiements
• [ ] Les permissions du fichier de clé privée sont 600 ; les permissions du répertoire ~/.ssh/ sont 700
• [ ] Une phrase secrète robuste est définie sur toutes les clés utilisateur interactives
• [ ] Les clés de comptes de service sans phrase secrète sont restreintes via les options authorized_keys (command=, from=, no-pty)
• [ ] PasswordAuthentication no est défini dans /etc/ssh/sshd_config sur tous les serveurs
• [ ] PermitRootLogin prohibit-password ou PermitRootLogin no est imposé
• [ ] Les empreintes de clés d’hôte du serveur ont été vérifiées hors bande
• [ ] Un inventaire des clés existe, mappant chaque empreinte aux serveurs où elle est déployée
• [ ] Le calendrier de rotation des clés est défini et planifié
• [ ] Les blocs d’hôtes ~/.ssh/config sont configurés pour éviter l’utilisation manuelle du drapeau -i
• [ ] L’agent SSH est utilisé pour éviter la saisie répétée de la phrase secrète pendant les sessions de travail
• [ ] Les entrées known_hosts sont examinées périodiquement pour détecter les entrées obsolètes ou inattendues

FAQ

Quelle est la différence entre les clés SSH Ed25519 et RSA ?

Ed25519 utilise la cryptographie à courbe elliptique avec une clé fixe de 256 bits qui fournit environ 128 bits de sécurité, signe les opérations plus rapidement que RSA, et produit des chaînes de clés plus courtes. RSA à 4096 bits offre une sécurité comparable mais est plus lent et génère un matériel de clé plus volumineux. Utilisez Ed25519 pour toutes les nouvelles clés, sauf si vous devez vous connecter à un système exécutant OpenSSH antérieur à la version 6.5.

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

Oui, techniquement. Cependant, la bonne pratique est d’utiliser des paires de clés distinctes par rôle ou environnement (accès au poste de travail personnel, déploiement CI/CD, maintenance de base de données). Cela limite l’impact d’une seule clé compromise et rend la révocation simple sans perturber les systèmes non liés.

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

Vous perdez la capacité de vous authentifier en utilisant cette paire de clés. La clé publique sur le serveur devient inutile. Vous devez accéder au serveur par une méthode alternative — accès console, une clé secondaire, ou l’accès d’urgence de votre hébergeur — puis supprimer la clé publique orpheline de authorized_keys et déployer une nouvelle paire de clés.

Pourquoi SSH demande-t-il encore un mot de passe après que j’ai copié ma clé publique ?

Les causes les plus courantes sont : des permissions incorrectes sur ~/.ssh/ (doit être 700) ou ~/.ssh/authorized_keys (doit être 600) sur le serveur ; le répertoire personnel lui-même étant accessible en écriture par tous ; SELinux ou AppArmor bloquant l’accès au répertoire .ssh ; ou PubkeyAuthentication no étant défini dans /etc/ssh/sshd_config. Exécutez ssh -vvv pour identifier exactement quelle méthode d’authentification est tentée et rejetée.

Comment supprimer une clé SSH d’un serveur auquel je n’ai plus accès ?

Si vous n’avez aucune autre méthode d’authentification, contactez l’équipe de support de votre hébergeur ou utilisez l’accès console hors bande (disponible pour les clients VPS et serveur dédié) pour vous connecter et modifier ~/.ssh/authorized_keys directement. C’est pourquoi maintenir des identifiants d’accès console séparément des clés SSH est une exigence opérationnelle non négociable.