Générer et utiliser une clé SSH ed25519 pas-à-pas — connexion sans mot de passe

L’authentification SSH par mot de passe est dépassée en 2026. Les bots scannent en permanence les ports 22 d’Internet et tentent les mots de passe courants à raison de plusieurs milliers de tentatives par heure et par serveur. Sur un VPS exposé sans protection, c’est statistiquement une question de jours avant qu’un mot de passe simple ne tombe. La parade standard : remplacer le mot de passe par une paire de clés cryptographiques. La clé privée reste sur le poste, la clé publique sur le serveur — sans la clé privée, l’accès est impossible. Ce tutoriel propose une démarche en sept étapes pour mettre en place une authentification SSH par clé ed25519 entre un poste local (Windows, macOS ou Linux) et un serveur Linux distant.

Pour la vue d’ensemble cryptographie, voir le guide principal : Cryptographie pratique pour développeurs et sysadmins.

Prérequis

• Un poste local avec OpenSSH installé (présent par défaut sur Linux, macOS, et Windows 10/11)
• Un serveur Linux distant accessible en SSH avec mot de passe (pour la première configuration)
• Un terminal ou PowerShell sur le poste local
• 20 minutes

Étape 1 — Comprendre le couple de clés

L’authentification par clé repose sur deux fichiers complémentaires. La clé privée reste sur le poste local — c’est l’équivalent d’une carte d’identité, à protéger absolument. La clé publique se copie sur les serveurs auxquels on veut accéder — comme un cadenas spécifique qui ne s’ouvre qu’avec la clé privée correspondante. Au moment de la connexion, le serveur envoie un défi cryptographique que seule la clé privée peut résoudre. Le mot de passe ne circule jamais.

L’algorithme ed25519 est le standard recommandé en 2026 par OpenSSH, plus rapide et plus sûr que RSA. Une clé ed25519 fait quelques dizaines d’octets et offre un niveau de sécurité équivalent à une clé RSA 3000 bits. Elle est aussi plus rapide à utiliser à la connexion. Tous les serveurs SSH modernes (OpenSSH 6.5+ depuis 2014) la supportent.

Étape 2 — Générer la paire de clés sur le poste local

Ouvrir un terminal (Linux/macOS) ou PowerShell (Windows). Lancer la commande de génération :

ssh-keygen -t ed25519 -C "votre.email@exemple.com"

L’option -t ed25519 impose l’algorithme moderne. L’option -C ajoute un commentaire pour identifier la clé plus tard (utile quand on en a plusieurs). À la question Enter file in which to save the key, accepter le défaut en appuyant sur Entrée : le fichier est créé dans ~/.ssh/id_ed25519 sur Linux/macOS ou C:\Users\<nom>\.ssh\id_ed25519 sur Windows.

À la question Enter passphrase, choisir une phrase secrète robuste (au moins 12 caractères). Cette phrase chiffre la clé privée elle-même : si quelqu’un vole le fichier, il ne peut pas s’en servir sans la phrase. Ne pas laisser vide — une clé sans phrase secrète qui se retrouve sur un disque volé donne accès direct à tous les serveurs configurés.

Deux fichiers sont créés : id_ed25519 (la clé privée, à protéger) et id_ed25519.pub (la clé publique, à diffuser).

Étape 3 — Copier la clé publique sur le serveur

L’opération consiste à ajouter le contenu du fichier id_ed25519.pub à la fin du fichier ~/.ssh/authorized_keys du compte distant. Sur Linux et macOS, l’outil ssh-copy-id automatise tout :

ssh-copy-id utilisateur@serveur.exemple.com

La commande demande le mot de passe une dernière fois (la dernière, donc, avant de basculer sur la clé), copie la clé publique au bon endroit, et configure les permissions correctement. Sur Windows, ssh-copy-id n’est pas toujours disponible — la copie se fait alors manuellement :

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh utilisateur@serveur "cat >> ~/.ssh/authorized_keys"

Cette commande lit la clé publique locale et l’envoie en append sur le serveur. Si le dossier ~/.ssh n’existe pas encore sur le serveur, le créer d’abord avec mkdir -p ~/.ssh && chmod 700 ~/.ssh.

Étape 4 — Tester la connexion par clé

Tenter une connexion :

ssh utilisateur@serveur.exemple.com

À la première connexion par clé, le terminal demande la phrase secrète (pas le mot de passe du compte distant). Si la connexion s’ouvre, l’authentification par clé fonctionne. Si elle demande encore le mot de passe distant, c’est que la copie de la clé publique a échoué — vérifier les permissions sur le serveur (~/.ssh doit être en 700, authorized_keys en 600).

Pour éviter de retaper la phrase secrète à chaque connexion, charger la clé dans ssh-agent. Sur Linux/macOS, ssh-agent tourne déjà — lancer ssh-add ~/.ssh/id_ed25519 une seule fois au début de la session. Sur Windows, le service OpenSSH Authentication Agent doit être démarré : Get-Service ssh-agent | Set-Service -StartupType Automatic; Start-Service ssh-agent, puis ssh-add.

Étape 5 — Désactiver l’authentification par mot de passe

Tant que le serveur accepte les mots de passe, les bots continuent à le tester — la clé n’apporte aucune protection si l’autre porte reste ouverte. Désactiver les mots de passe en éditant la configuration SSH du serveur :

sudo nano /etc/ssh/sshd_config

Modifier les lignes suivantes (les décommenter si elles sont précédées d’un #) :

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

La directive PasswordAuthentication no ferme la voie mot de passe. PermitRootLogin prohibit-password autorise root par clé seulement, jamais par mot de passe. PubkeyAuthentication yes active explicitement l’authentification par clé. Sauvegarder et recharger SSH :

sudo systemctl reload ssh

Important : ne pas fermer la connexion SSH actuelle avant d’avoir testé une nouvelle connexion dans une autre fenêtre. Si la nouvelle session s’ouvre par clé, la configuration est bonne. Si elle est rejetée, on a encore l’ancienne session pour corriger — sinon le serveur devient inaccessible et il faut passer par la console du fournisseur cloud pour récupérer.

Étape 6 — Configurer un alias pour simplifier

Taper ssh utilisateur@adresse-longue-serveur.fournisseur.com -p 22 -i ~/.ssh/id_ed25519 à chaque fois est pénible. Le fichier ~/.ssh/config permet de définir des alias :

Host monserveur
    HostName serveur.exemple.com
    User utilisateur
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Avec ce bloc dans ~/.ssh/config, la commande devient simplement ssh monserveur. Les permissions du fichier doivent être 600 (chmod 600 ~/.ssh/config). Pour plusieurs serveurs, ajouter des blocs Host supplémentaires.

Étape 7 — Sauvegarder la clé privée

La clé privée est devenue la condition d’accès à tous les serveurs configurés. Si le poste lâche, on perd l’accès. Trois pratiques de sauvegarde recommandées. Cryptomator + cloud : créer un coffre Cryptomator chiffré, y déposer une copie de id_ed25519, synchroniser sur OneDrive ou Google Drive. La clé reste illisible pour le fournisseur cloud. Bitwarden ou KeePass : stocker la clé comme attachement ou note sécurisée dans le gestionnaire de mots de passe. Disque externe chiffré : copie sur une clé USB chiffrée stockée dans un endroit sûr.

En complément, garder une trace de la phrase secrète qui chiffre la clé — sans elle, la clé restaurée est inutilisable. Stockage dans le gestionnaire de mots de passe.

Vérification du livrable

• La connexion SSH par clé fonctionne sans demander le mot de passe distant
• L’authentification par mot de passe est désactivée sur le serveur
• La phrase secrète protège la clé privée
• Un alias dans ~/.ssh/config simplifie l’usage
• La clé privée est sauvegardée de manière chiffrée

Erreurs fréquentes

Erreur	Cause	Solution
Permissions trop ouvertes	Fichiers en 644 ou 777	chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519
Désactiver mots de passe trop tôt	Clé pas encore copiée	Tester d’abord la connexion par clé dans une autre fenêtre
Phrase secrète vide	Confort sans sécurité	Phrase robuste + ssh-agent pour ne pas la retaper
Clé privée committée dans Git	Push automatique du dossier home	Vérifier .gitignore, ne jamais committer id_ed25519
Clé partagée entre collègues	Mauvaise pratique	Une clé par personne, comptes séparés sur le serveur

VPS Hetzner ou Sonatel Cloud à protéger

Trois pratiques utiles pour qui sysadmin sur infrastructure ouest-africaine. Le VPS abordable à exposer en SSH (DigitalOcean, Hetzner, OVH, Sonatel Cloud) doit être configuré dès la création avec une clé fournie au lieu d’un mot de passe — la plupart des fournisseurs le proposent au moment de la commande, c’est l’option par défaut chez Hetzner. Le port SSH non standard (par exemple 2222 au lieu de 22) réduit drastiquement le bruit des bots dans les logs : les scans automatisés ciblent essentiellement le port 22 par défaut. Et fail2ban, bien que moins critique avec authentification par clé, reste un bon complément qui bloque automatiquement les IP qui tentent trop de connexions ratées — installation en une commande sur Ubuntu (sudo apt install fail2ban), particulièrement utile sur un VPS très exposé.

Tutoriels frères

• Configurer Let’s Encrypt avec Certbot
• Hasher des mots de passe avec bcrypt et argon2
• Chiffrer un fichier avec GPG

Pour aller plus loin

• 🔝 Retour au guide principal : Cryptographie pratique pour développeurs et sysadmins

Sources et références

• OpenSSH — site officiel
• man ssh-keygen — documentation officielle
• GitHub — connexion en SSH