Clé SSH : connexion sans mot de passe en 12 étapes [2026]

Le mot de passe SSH est le maillon faible de presque tous les serveurs Linux exposés sur Internet. Les robots d’attaque par force brute frappent le port 22 en continu, et un seul identifiant deviné ouvre l’accès complet à la machine. L’authentification par clé SSH supprime ce risque : au lieu d’un secret partagé que l’on tape, vous présentez une preuve cryptographique qu’un serveur ne peut ni deviner ni rejouer. Ce tutoriel vous guide en 12 étapes pour générer une clé SSH moderne avec ssh-keygen, la déployer sur vos serveurs, désactiver complètement les mots de passe et durcir le démon SSH selon les recommandations de l’ANSSI et de Mozilla.

Comptez environ 30 minutes pour la configuration de base, et 60 minutes si vous ajoutez le durcissement serveur et une clé matérielle FIDO2. Toutes les commandes ont été testées sur Ubuntu 26.04 LTS et Debian 13 « Trixie » avec OpenSSH 10.x, mais elles s’appliquent à macOS, Windows 11 (OpenSSH intégré) et toute distribution Linux récente.

Pourquoi abandonner les mots de passe SSH en 2026

Un mot de passe, même long, reste un secret réutilisable. S’il fuite via un keylogger, un dépôt Git public ou une attaque par dictionnaire, l’attaquant obtient un accès direct. Une clé SSH fonctionne différemment. Vous générez une paire mathématiquement liée : une clé privée qui ne quitte jamais votre poste, et une clé publique que vous distribuez librement. Le serveur stocke la clé publique et lance un défi cryptographique à chaque connexion. Seul le détenteur de la clé privée peut y répondre. Aucun secret réutilisable ne transite sur le réseau.

L’écart de sécurité est mesurable. Une clé Ed25519 offre un niveau de résistance d’environ 128 bits, l’équivalent d’un mot de passe aléatoire d’une trentaine de caractères que personne ne pourrait mémoriser ni saisir. Les serveurs publics subissent des milliers de tentatives d’authentification par mot de passe chaque jour. En désactivant PasswordAuthentication, vous rendez ces attaques structurellement impossibles : il n’y a plus rien à deviner.

Les clés SSH apportent aussi du confort opérationnel. Une fois la clé chargée dans ssh-agent, vous ne tapez plus rien pour vous connecter. Vous automatisez les déploiements, les sauvegardes via rsync et les pipelines CI/CD sans coller de mot de passe dans un script. Et contrairement à un mot de passe partagé, chaque clé est nominative : vous révoquez l’accès d’un développeur en supprimant une seule ligne du fichier authorized_keys, sans changer le secret de toute l’équipe.

L’ANSSI, l’agence nationale française de cybersécurité, recommande de longue date l’authentification par clé publique pour l’administration des systèmes, et de proscrire l’accès direct du compte root. Les référentiels d’hébergeurs européens vont dans le même sens : OVHcloud, Scaleway et Hetzner proposent tous le dépôt d’une clé publique dès la création d’une instance, précisément pour éviter la phase à risque où le serveur n’accepte qu’un mot de passe. Adopter les clés SSH n’est donc pas une coquetterie d’expert, c’est la configuration attendue d’un serveur de production en 2026.

Pour aller plus loin sur la protection du port 22 contre les attaques résiduelles, notre tutoriel Fail2ban pour protéger SSH complète parfaitement cette approche par clés. Les deux se combinent : la clé SSH supprime l’authentification par mot de passe, et Fail2ban bannit les adresses IP qui multiplient les sondages, ce qui allège vos journaux.

Comment fonctionne l’authentification par clé SSH

L’authentification par clé SSH repose sur la cryptographie asymétrique. La clé privée et la clé publique forment un couple indissociable. Ce qu’une clé signe, l’autre le vérifie, mais on ne peut pas reconstruire la clé privée à partir de la clé publique en un temps raisonnable. C’est cette asymétrie qui permet de publier la clé publique sans aucun risque.

Voici le déroulé d’une connexion. Votre client SSH contacte le serveur et annonce qu’il souhaite s’authentifier avec une clé. Le serveur consulte le fichier ~/.ssh/authorized_keys de l’utilisateur ciblé pour vérifier qu’il connaît la clé publique correspondante. Si oui, un échange de défi-réponse a lieu : le serveur s’assure, via une signature numérique, que le client détient bien la clé privée associée. Aucun moment de cet échange ne révèle la clé privée, et chaque session établit ses propres clés de chiffrement éphémères.

Un second mécanisme protège l’autre sens de la relation : la clé d’hôte du serveur. Lors de votre toute première connexion, le client affiche l’empreinte de la clé d’hôte et l’enregistre dans ~/.ssh/known_hosts. Ce modèle, appelé « confiance à la première utilisation » (TOFU), garantit qu’aux connexions suivantes vous parlez bien au même serveur. Si l’empreinte change sans raison, OpenSSH refuse net la connexion : c’est sa protection intégrée contre les attaques de l’intercepteur. Vérifiez toujours l’empreinte affichée à la première connexion auprès de votre hébergeur, qui la publie généralement dans son panneau de gestion.

Pourquoi Ed25519 plutôt que RSA

OpenSSH propose plusieurs algorithmes, mais en 2026 le choix par défaut recommandé est Ed25519. Cet algorithme de signature s’appuie sur la courbe elliptique Curve25519, conçue par Daniel J. Bernstein. Il produit des clés de seulement 256 bits, soit une clé publique d’environ 68 caractères, là où une clé RSA équivalente exige 3072 ou 4096 bits. Ed25519 signe et vérifie plus vite, résiste aux attaques par canaux auxiliaires par conception, et son implémentation laisse peu de place aux erreurs de configuration.

RSA 4096 bits reste un choix valable pour les systèmes anciens qui ne comprennent pas Ed25519, mais il devient l’exception. ECDSA souffre de la méfiance autour des courbes NIST et d’une dépendance critique à la qualité de l’aléa lors de la signature. Quant à DSA, OpenSSH 10.0 (avril 2025) a définitivement retiré sa prise en charge : ne générez plus jamais de clé DSA. Notre règle simple : Ed25519 partout, RSA 4096 uniquement en cas d’incompatibilité avérée.

Prérequis et versions logicielles

Avant de générer votre première clé SSH, vérifiez que votre environnement réunit les éléments suivants. Le tableau précise les versions utilisées pour valider ce tutoriel en juin 2026.

Élément	Version testée	Rôle
OpenSSH (client et serveur)	10.x	Génération de clés, connexion, démon sshd
Ubuntu Server	26.04 LTS	Serveur de démonstration
Debian stable	13 « Trixie »	Alternative serveur
Noyau Linux	7.0	Base d’Ubuntu 26.04 LTS
Poste client	Linux, macOS 15+, Windows 11	Là où réside votre clé privée
Accès initial	mot de passe ou console	Nécessaire pour déployer la première clé

Vous avez besoin d’un compte utilisateur sur le serveur cible et d’un accès initial pour y déposer votre clé publique, que ce soit par mot de passe temporaire, par console du fournisseur cloud ou par une clé déjà en place. Sur Windows 11, OpenSSH est inclus mais parfois désactivé : activez la fonctionnalité « Client OpenSSH » dans les paramètres optionnels. Sur macOS, le client est présent nativement dans le Terminal.

Étape 1 : Vérifier OpenSSH et sa version

Commencez par confirmer qu’OpenSSH est installé et suffisamment récent pour gérer Ed25519. Ouvrez un terminal sur votre poste client et lancez la commande suivante.

ssh -V
# Sortie attendue (exemple) :
# OpenSSH_10.0p1, OpenSSL 3.5.0 1 Apr 2026

Toute version OpenSSH 6.5 ou supérieure prend en charge Ed25519, donc n’importe quel système de 2026 convient largement. Si la commande renvoie une erreur sur Linux, installez le paquet avec sudo apt install openssh-client. Côté serveur, vérifiez que le démon est présent avec sudo systemctl status ssh sur Debian et Ubuntu (le service s’appelle parfois sshd sur d’autres distributions).

Profitez-en pour lister les clés déjà présentes sur votre poste, afin de ne pas écraser une paire existante à l’étape suivante.

ls -al ~/.ssh
# Cherchez des fichiers comme id_ed25519, id_ed25519.pub,
# id_rsa, id_rsa.pub. Le suffixe .pub designe la cle publique.

Étape 2 : Générer une paire de clés Ed25519

Le cœur du tutoriel. La commande ssh-keygen crée votre paire de clés. Utilisez l’algorithme Ed25519, ajoutez un commentaire identifiant et renforcez la dérivation de la phrase secrète avec l’option -a.

ssh-keygen -t ed25519 -a 100 -C "sam@poste-bureau-2026"

# -t ed25519  : type d'algorithme (recommande)
# -a 100      : 100 tours de derivation KDF pour proteger la cle privee
# -C "..."    : commentaire libre, utile pour identifier la cle

Le programme vous pose deux questions. La première porte sur l’emplacement du fichier : acceptez la valeur par défaut ~/.ssh/id_ed25519 en appuyant sur Entrée, sauf si vous gérez plusieurs clés (voir l’étape 11). La seconde demande une phrase secrète. Saisissez-en une, robuste et mémorisable. Elle chiffre la clé privée sur le disque : si votre ordinateur est volé, le voleur ne pourra pas utiliser la clé sans cette phrase.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/sam/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sam/.ssh/id_ed25519
Your public key has been saved in /home/sam/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:8Hq2k...exemple...9fJ sam@poste-bureau-2026

L’image « randomart » affichée à la fin est une représentation visuelle de l’empreinte. Elle aide à repérer d’un coup d’œil un changement de clé inattendu. Ne sautez jamais l’étape de la phrase secrète sur un poste de travail : une clé privée sans phrase secrète équivaut à un mot de passe écrit en clair sur votre disque.

Étape 3 : Comprendre les fichiers générés

ssh-keygen a créé deux fichiers dans ~/.ssh. Comprendre leur rôle évite la plupart des erreurs de débutant, notamment le partage accidentel de la clé privée.

id_ed25519 : votre clé privée. Elle ne quitte jamais votre poste. Ne la copiez nulle part, ne l’envoyez par aucun canal, ne la versionnez dans aucun dépôt Git.
id_ed25519.pub : votre clé publique. C’est elle que vous déployez sur les serveurs. Elle peut circuler librement, par e-mail, dans un ticket ou un dépôt.

Affichez le contenu de la clé publique. Elle tient sur une seule ligne et commence par le préfixe ssh-ed25519.

cat ~/.ssh/id_ed25519.pub
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH8q...exemple...k9fJ sam@poste-bureau-2026

Les permissions de fichiers comptent. OpenSSH refuse d’utiliser une clé privée trop ouverte. Le dossier ~/.ssh doit être en 700 et la clé privée en 600. ssh-keygen applique ces permissions automatiquement, mais après une copie ou une restauration de sauvegarde, corrigez-les avec chmod 700 ~/.ssh puis chmod 600 ~/.ssh/id_ed25519.

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

Pour autoriser votre clé SSH, le serveur doit connaître votre clé publique. La méthode la plus simple est ssh-copy-id, qui ajoute proprement la clé au fichier ~/.ssh/authorized_keys du compte distant.

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
# Le serveur demande votre mot de passe une derniere fois,
# puis enregistre la cle publique dans ~/.ssh/authorized_keys

Si ssh-copy-id n’est pas disponible, par exemple sur Windows, déployez la clé manuellement. La commande ci-dessous fonctionne depuis n’importe quel poste disposant du client SSH.

cat ~/.ssh/id_ed25519.pub | ssh [email protected] \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Cette commande crée le dossier ~/.ssh si besoin, applique les bonnes permissions et ajoute votre clé publique en fin de fichier authorized_keys sans écraser les clés déjà présentes. Chez un fournisseur cloud, vous pouvez aussi coller la clé publique dans la console web lors de la création de l’instance, ce qui évite tout accès par mot de passe dès le départ.

Étape 5 : Tester la connexion par clé

Avant de désactiver les mots de passe, vérifiez que la connexion par clé SSH fonctionne. C’est l’étape de sécurité la plus importante : ne coupez jamais l’authentification par mot de passe tant que vous n’avez pas confirmé un accès par clé.

ssh [email protected]
# Si une phrase secrete protege la cle, le client la demande
# (et non le serveur). Vous arrivez ensuite sur le shell distant.

Si la connexion réussit sans demander de mot de passe serveur, l’authentification par clé est opérationnelle. En cas de doute, lancez le mode verbeux pour voir exactement quelle méthode SSH tente et laquelle réussit.

ssh -v [email protected]
# Cherchez les lignes :
# debug1: Offering public key: /home/sam/.ssh/id_ed25519 ED25519
# debug1: Server accepts key: ...
# debug1: Authentication succeeded (publickey).

La ligne Authentication succeeded (publickey) confirme que tout est en place. Gardez cette session ouverte pendant le durcissement du serveur : elle vous servira de filet de sécurité si une mauvaise configuration vous verrouille à l’étape 8.

Étape 6 : Charger la clé dans ssh-agent

Taper la phrase secrète à chaque connexion devient vite pénible. L’agent SSH garde la clé déchiffrée en mémoire pour la durée de votre session, ce qui combine sécurité au repos et confort d’usage. Lancez l’agent puis ajoutez votre clé.

# Demarrer l'agent (souvent deja actif sur les bureaux Linux et macOS)
eval "$(ssh-agent -s)"
# Agent pid 4521

# Ajouter la cle : la phrase secrete est demandee une seule fois
ssh-add ~/.ssh/id_ed25519
# Identity added: /home/sam/.ssh/id_ed25519 (sam@poste-bureau-2026)

# Verifier les cles chargees
ssh-add -l

Sur macOS, ajoutez l’option --apple-use-keychain à ssh-add pour stocker la phrase secrète dans le trousseau et la recharger automatiquement à chaque démarrage. Sur Linux, les bureaux GNOME et KDE intègrent un agent qui propose de mémoriser la phrase. Pour une session purement automatisée (CI/CD), préférez une clé dédiée sans phrase secrète, à droits restreints, plutôt que de désactiver la protection de votre clé personnelle.

Étape 7 : Simplifier les accès avec ~/.ssh/config

Le fichier ~/.ssh/config transforme des commandes longues en alias courts. Au lieu de retenir adresses IP, ports et noms d’utilisateur, vous définissez chaque hôte une fois. Créez ou éditez ce fichier sur votre poste client.

# ~/.ssh/config

Host prod
    HostName 203.0.113.10
    User sam
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host *
    AddKeysToAgent yes
    ServerAliveInterval 60
    HashKnownHosts yes

Désormais, ssh prod suffit pour vous connecter avec le bon utilisateur, le bon port et la bonne clé. L’option IdentitiesOnly yes évite que le client propose toutes vos clés à la suite, ce qui peut déclencher un blocage temporaire du serveur après trop de tentatives. AddKeysToAgent yes charge la clé dans l’agent à la première utilisation. Appliquez la permission 600 au fichier avec chmod 600 ~/.ssh/config.

Étape 8 : Désactiver les mots de passe côté serveur

Vous avez confirmé l’accès par clé. Il est temps de fermer la porte aux attaques par mot de passe. Toutes les modifications se font dans le fichier de configuration du démon, /etc/ssh/sshd_config, ou mieux, dans un fichier dédié sous /etc/ssh/sshd_config.d/. Cette seconde approche survit aux mises à jour de paquet.

# Creer un fichier de durcissement dedie
sudo nano /etc/ssh/sshd_config.d/99-durcissement.conf

Renseignez les directives suivantes. Elles imposent l’authentification par clé, interdisent la connexion root par mot de passe et coupent les mécanismes inutiles.

# /etc/ssh/sshd_config.d/99-durcissement.conf

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
PermitEmptyPasswords no
UsePAM yes
MaxAuthTries 3
LoginGraceTime 20

Avant de recharger, validez la syntaxe avec sudo sshd -t. Si la commande ne renvoie rien, la configuration est correcte. Rechargez ensuite le service sans couper votre session active.

sudo sshd -t              # test de syntaxe, aucune sortie = OK
sudo systemctl reload ssh # appliquer sans tuer les sessions ouvertes

Ouvrez maintenant une nouvelle fenêtre de terminal et reconnectez-vous. Si l’accès par clé fonctionne toujours et qu’une tentative de mot de passe est refusée, le durcissement est réussi. Gardez l’ancienne session ouverte jusqu’à cette confirmation : c’est votre garantie contre un verrouillage accidentel.

Étape 9 : Restreindre utilisateurs, port et écoute

Au-delà des clés, vous pouvez réduire encore la surface d’attaque. Limitez les comptes autorisés à se connecter en SSH, et choisissez d’écouter sur une interface précise. Ajoutez ces directives au même fichier de durcissement.

# Restreindre l'acces SSH a des comptes nommes
AllowUsers sam deploy

# Ecouter uniquement sur l'IPv4 publique (exemple)
# ListenAddress 203.0.113.10

# Changer le port par defaut reduit le bruit des robots
# Port 2222

Changer le port de 22 vers une valeur comme 2222 n’est pas une mesure de sécurité au sens strict, car un scan de ports le retrouve, mais cela réduit fortement le volume de journaux et les tentatives automatisées. Si vous modifiez le port, pensez à l’ouvrir dans votre pare-feu : sudo ufw allow 2222/tcp puis sudo ufw delete allow 22/tcp une fois la nouvelle configuration confirmée. Sur les distributions récentes utilisant l’activation par socket, configurez plutôt le port via systemctl edit ssh.socket.

Pour un serveur exposé, associez ces réglages à un pare-feu et à un certificat valide si vous y hébergez des services web. Notre guide certificat SSL gratuit avec Certbot couvre le volet HTTPS de cette même machine.

Étape 10 : Choisir des algorithmes modernes

Les versions récentes d’OpenSSH retiennent déjà de bons algorithmes par défaut, mais vous pouvez verrouiller la liste pour interdire les primitives anciennes. Les recommandations de Mozilla pour OpenSSH servent de référence solide. Ajoutez ces lignes au fichier de durcissement serveur si vous voulez un contrôle explicite.

# Algorithmes d'echange de cles, chiffrements et MAC modernes
KexAlgorithms curve25519-sha256,[email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512

Ces réglages garantissent l’usage de Curve25519 pour l’échange de clés, ChaCha20-Poly1305 ou AES-256-GCM pour le chiffrement, et des MAC en mode « encrypt-then-MAC » plus robustes. Testez toujours avec sudo sshd -t avant de recharger : une faute de frappe dans la liste des chiffrements peut rendre le serveur inaccessible. Si un client ancien ne parvient plus à se connecter, élargissez prudemment la liste plutôt que de la supprimer.

Étape 11 : Gérer plusieurs clés et la rotation

Beaucoup d’utilisateurs séparent leurs clés SSH par usage : une pour le travail, une pour les projets personnels, une pour GitHub. Générez une clé nommée explicitement et déclarez-la dans ~/.ssh/config.

# Generer une cle dediee a GitHub
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_github -C "github-sam"

# ~/.ssh/config : associer chaque hote a la bonne cle
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github
    IdentitiesOnly yes

La rotation des clés est une bonne hygiène. Pour remplacer une clé compromise ou ancienne, générez-en une nouvelle, déployez la nouvelle clé publique avec ssh-copy-id, confirmez l’accès, puis supprimez l’ancienne ligne du fichier authorized_keys sur chaque serveur. Tenez un inventaire de vos clés : savoir quelle clé donne accès à quoi est indispensable le jour où un poste est perdu.

Étape 12 : Renforcer avec une clé matérielle FIDO2

Le niveau de sécurité supérieur consiste à ancrer la clé SSH dans un jeton matériel comme une YubiKey ou tout authentifiant FIDO2. La partie sensible de la clé ne réside alors plus sur le disque mais dans la puce du jeton, et chaque connexion exige une présence physique (un appui sur le bouton). OpenSSH gère cela depuis la version 8.2 via les types de clés ed25519-sk et ecdsa-sk.

# Brancher la cle materielle, puis generer une cle ancree au jeton
ssh-keygen -t ed25519-sk -a 100 -C "yubikey-sam"
# Touchez le jeton lorsque la diode clignote.
# Deux fichiers sont crees : id_ed25519_sk et id_ed25519_sk.pub

Déployez ensuite id_ed25519_sk.pub exactement comme une clé classique, avec ssh-copy-id. À chaque connexion, le serveur exigera la présence du jeton et un appui physique. C’est la défense la plus efficace contre le vol de clé à distance : même un attaquant qui copie le fichier de clé ne peut rien faire sans le jeton. Pour les sauvegardes critiques, conservez un second jeton FIDO2 enregistré en parallèle, afin de ne pas perdre tout accès en cas de perte du premier.

Déployer les clés SSH en équipe et à grande échelle

Gérer une clé SSH sur un serveur est simple. Gérer les accès de dix personnes sur cinquante machines exige de la méthode. La règle d’or : chaque membre possède sa propre paire de clés et ne partage jamais sa clé privée. Vous centralisez uniquement les clés publiques, par exemple dans un dépôt Git d’infrastructure, puis vous les distribuez avec un outil de gestion de configuration.

Ansible illustre bien cette approche. Le module ansible.posix.authorized_key ajoute ou retire une clé publique sur un parc entier en une seule exécution. Vous décrivez l’état souhaité (telle clé présente, telle clé absente) et l’outil l’applique partout de façon idempotente.

- name: Autoriser la cle de Sam sur les serveurs web
  ansible.posix.authorized_key:
    user: deploy
    state: present
    key: "{{ lookup('file', 'cles/sam_ed25519.pub') }}"

Pour les organisations plus grandes, les certificats SSH constituent l’étape suivante. Plutôt que de copier chaque clé publique sur chaque serveur, une autorité de certification SSH signe les clés des utilisateurs pour une durée limitée. Les serveurs font confiance à l’autorité, pas à chaque clé individuelle, ce qui supprime la gestion manuelle de authorized_keys et offre une révocation immédiate à l’expiration. Des solutions comme HashiCorp Vault ou Teleport automatisent ce flux, mais la base reste la même paire de clés Ed25519 que vous avez générée à l’étape 2.

Comparatif des types de clés SSH

Le choix de l’algorithme conditionne la sécurité et la compatibilité de votre clé SSH. Ce tableau résume les options disponibles avec OpenSSH en 2026.

Type	Taille	Sécurité	Recommandation 2026
Ed25519	256 bits	~128 bits, rapide, courbe Curve25519	Choix par défaut, à privilégier
Ed25519-sk	256 bits + jeton	Clé ancrée au matériel FIDO2	Idéal pour les accès critiques
RSA 4096	4096 bits	Solide mais lent, clés volumineuses	Compatibilité systèmes anciens
ECDSA	256-521 bits	Dépend des courbes NIST et de l’aléa	À éviter sauf contrainte
DSA	1024 bits	Obsolète, retiré d’OpenSSH 10.0	Ne plus jamais utiliser

En résumé : Ed25519 pour l’usage courant, Ed25519-sk avec jeton matériel pour les serveurs sensibles, et RSA 4096 seulement face à un équipement qui ne comprend rien d’autre. ECDSA et DSA appartiennent au passé. Cette logique rejoint nos principes sur les bonnes pratiques détaillées dans notre dossier sécurité des mots de passe.

5 pièges courants à éviter

Ces erreurs reviennent sans cesse dans les configurations SSH. Les connaître vous épargnera des heures de débogage et, surtout, un verrouillage hors de votre propre serveur.

Désactiver les mots de passe avant de tester la clé. Si l’accès par clé échoue après la coupure, vous perdez tout accès SSH. Confirmez toujours une connexion par clé dans une seconde session avant de recharger sshd.
Partager ou versionner la clé privée. La clé privée ne quitte jamais votre poste. Une clé poussée dans un dépôt Git, même privé, doit être considérée comme compromise et révoquée immédiatement.
Permissions trop larges sur ~/.ssh. OpenSSH ignore une clé privée lisible par d’autres utilisateurs et un fichier authorized_keys modifiable par le groupe. Respectez 700 pour le dossier, 600 pour les fichiers.
Générer une clé sans phrase secrète sur un poste personnel. Une clé en clair sur disque est exploitable telle quelle en cas de vol. Réservez les clés sans phrase aux comptes de service isolés et à droits limités.
Oublier d’ouvrir le nouveau port dans le pare-feu. Changer le port SSH sans ajuster ufw ou nftables bloque la prochaine connexion. Ouvrez le nouveau port avant de fermer l’ancien.

Dépannage : 8 erreurs fréquentes

Voici les messages d’erreur les plus courants liés aux clés SSH et leur résolution. Lancez toujours ssh -v pour obtenir le détail de la négociation avant de conclure.

Symptôme	Cause probable	Solution
Permission denied (publickey)	Clé non déployée ou mauvais compte	Vérifier `authorized_keys` et l’utilisateur cible
Le serveur demande encore un mot de passe	Clé non proposée par le client	Ajouter `IdentityFile` dans `~/.ssh/config`
WARNING: UNPROTECTED PRIVATE KEY FILE	Permissions trop ouvertes	`chmod 600 ~/.ssh/id_ed25519`
Authentications that can continue: password	Pubkey refusée côté serveur	Contrôler permissions de `~/.ssh` distant (700)
Could not open a connection to your agent	ssh-agent non démarré	`eval "$(ssh-agent -s)"` puis `ssh-add`
Too many authentication failures	Trop de clés proposées	Ajouter `IdentitiesOnly yes`
Host key verification failed	Empreinte serveur changée	Vérifier l’hôte, corriger `~/.ssh/known_hosts`
sign_and_send_pubkey: signing failed	Jeton FIDO2 absent ou agent figé	Rebrancher le jeton, relancer l’agent

Pour l’erreur « Host key verification failed », prudence. Elle signifie que la clé d’hôte du serveur a changé depuis votre dernière connexion. C’est parfois légitime (réinstallation), mais cela peut aussi trahir une attaque de l’intercepteur. Confirmez l’empreinte par un canal indépendant avant de supprimer l’ancienne ligne de known_hosts avec ssh-keygen -R 203.0.113.10.

Si vous êtes verrouillé hors du serveur après le durcissement, la console de secours du fournisseur cloud (KVM ou « rescue mode ») reste votre porte de sortie. Connectez-vous par la console, corrigez /etc/ssh/sshd_config.d/99-durcissement.conf, testez avec sshd -t, puis rechargez le service.

Astuces avancées pour aller plus loin

Restreindre une clé à une seule commande

Pour une clé de sauvegarde ou de déploiement, limitez-la à une commande précise directement dans authorized_keys. La clé ne pourra rien faire d’autre, même si elle fuite.

# Dans ~/.ssh/authorized_keys du serveur :
command="/usr/local/bin/sauvegarde.sh",no-port-forwarding,no-pty ssh-ed25519 AAAA...cle... backup

Auditer les connexions par clé

Savoir qui se connecte, quand et avec quelle clé fait partie d’une bonne hygiène. Le journal système enregistre chaque authentification réussie ou refusée. Sur Ubuntu et Debian, consultez-le avec journalctl ou le fichier d’authentification.

# Voir les connexions SSH acceptees et refusees
sudo journalctl -u ssh --since "today" | grep -i "Accepted\|Failed"

# Lister les dernieres connexions reussies
last -a | head

Pour tracer précisément quelle clé a servi, ajoutez LogLevel VERBOSE au fichier de durcissement : OpenSSH journalisera alors l’empreinte SHA256 de la clé utilisée à chaque connexion. Croisé avec votre inventaire de clés, ce détail permet d’identifier nominativement chaque accès, un atout précieux lors d’un audit ou d’une réponse à incident.

Rebondir via un hôte bastion

Pour atteindre un serveur interne sans l’exposer à Internet, passez par un hôte bastion grâce à la directive ProxyJump. La clé n’est jamais déposée sur le bastion : l’agent fait suivre l’authentification de bout en bout.

# ~/.ssh/config
Host interne
    HostName 10.0.0.5
    User sam
    ProxyJump bastion

Host bastion
    HostName 203.0.113.10
    User sam
    IdentityFile ~/.ssh/id_ed25519

Évitez l’option ForwardAgent yes par défaut : elle expose votre agent sur le serveur distant. Préférez ProxyJump, qui ne partage jamais vos clés avec les machines intermédiaires. Pour relier des sites distants par un tunnel chiffré complet, notre tutoriel VPN WireGuard sur Linux propose une alternative au rebond SSH.

Et la cryptographie post-quantique ?

Ed25519 repose sur des courbes elliptiques classiques, vulnérables en théorie à un futur ordinateur quantique. OpenSSH a déjà commencé à intégrer des échanges de clés hybrides post-quantiques pour la couche de transport, et des projets comme Rosenpass ajoutent une couche d’établissement de clés résistante au quantique devant le tunnel. Pour la signature d’authentification, Ed25519 reste sûr face aux menaces actuelles. Surveillez les notes de version d’OpenSSH pour les évolutions.

Projet complet : du poste au serveur durci

Récapitulons l’ensemble du projet sous forme d’une séquence reproductible. Adaptez l’adresse IP, le nom d’utilisateur et le port à votre environnement.

# === Sur le poste client ===
# 1. Generer la cle Ed25519 protegee par phrase secrete
ssh-keygen -t ed25519 -a 100 -C "sam@poste-bureau-2026"

# 2. Deployer la cle publique sur le serveur
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# 3. Charger la cle dans l'agent
eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519

# 4. Tester l'acces par cle
ssh [email protected] "echo Connexion par cle reussie"

# === Sur le serveur, une fois l'acces par cle confirme ===
# 5. Creer le fichier de durcissement
sudo tee /etc/ssh/sshd_config.d/99-durcissement.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3
AllowUsers sam
EOF

# 6. Valider et appliquer
sudo sshd -t && sudo systemctl reload ssh

Après l’étape 6, ouvrez une nouvelle session pour confirmer que la clé fonctionne toujours et que le mot de passe est refusé. Vous disposez alors d’un serveur dont le seul moyen d’accès SSH est une clé SSH Ed25519, sans aucun mot de passe exploitable à distance. C’est la base de toute administration sécurisée en 2026.

Questions fréquentes sur les clés SSH

Une clé SSH peut-elle être piratée ?

Casser une clé Ed25519 par force brute est hors de portée des moyens actuels, avec ses ~128 bits de sécurité. Le risque réel n’est pas mathématique mais opérationnel : vol du fichier de clé privée, phrase secrète faible ou absente, ou clé exposée dans un dépôt. Une phrase secrète robuste et, idéalement, un jeton matériel FIDO2 neutralisent ces vecteurs.

Faut-il une clé différente par serveur ?

Non, ce n’est pas nécessaire. Une même clé peut autoriser l’accès à plusieurs serveurs sans perte de sécurité, puisque seule la clé publique y est stockée. En revanche, séparez vos clés par contexte (travail, personnel, GitHub) pour cloisonner les usages et faciliter la révocation ciblée.

Que faire si j’oublie ma phrase secrète ?

La phrase secrète n’est pas récupérable : elle chiffre la clé privée localement. Si vous l’oubliez, la clé est inutilisable. Générez une nouvelle paire avec ssh-keygen, déployez la nouvelle clé publique sur vos serveurs, puis supprimez l’ancienne des fichiers authorized_keys.

Ed25519 ou RSA, lequel choisir ?

Ed25519 dans la quasi-totalité des cas : plus rapide, plus court et conçu pour résister aux erreurs d’implémentation. Réservez RSA 4096 aux équipements anciens qui ne reconnaissent pas Ed25519. Ne générez plus de clés ECDSA ou DSA.

Comment supprimer l’accès d’un utilisateur ?

Ouvrez le fichier ~/.ssh/authorized_keys du compte concerné sur le serveur et supprimez la ligne contenant la clé publique de l’utilisateur. L’accès est révoqué dès la prochaine tentative de connexion, sans affecter les autres clés autorisées.

Les clés SSH fonctionnent-elles sur Windows ?

Oui. Windows 11 intègre OpenSSH. Activez le « Client OpenSSH » dans les fonctionnalités optionnelles, puis utilisez ssh-keygen dans PowerShell exactement comme sous Linux. Les clés se rangent dans %USERPROFILE%\.ssh.

Dois-je sauvegarder ma clé privée ?

Sauvegardez la clé privée sur un support chiffré hors ligne si la perdre vous couperait l’accès à des systèmes critiques. Pour les clés ancrées à un jeton FIDO2, enregistrez plutôt un second jeton en parallèle, car la partie sensible ne peut pas être copiée.

Sources et références externes : la documentation officielle OpenSSH, le manuel de ssh-keygen, les recommandations OpenSSH de Mozilla, le guide OpenSSH Server d’Ubuntu et les publications de l’ANSSI.

Clé SSH : connexion sans mot de passe, 12 étapes [2026]

Pourquoi abandonner les mots de passe SSH en 2026

Comment fonctionne l’authentification par clé SSH

Pourquoi Ed25519 plutôt que RSA

Prérequis et versions logicielles

Étape 1 : Vérifier OpenSSH et sa version

Étape 2 : Générer une paire de clés Ed25519

Étape 3 : Comprendre les fichiers générés

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

Étape 5 : Tester la connexion par clé

Étape 6 : Charger la clé dans ssh-agent

Étape 7 : Simplifier les accès avec ~/.ssh/config

Étape 8 : Désactiver les mots de passe côté serveur

Étape 9 : Restreindre utilisateurs, port et écoute

Étape 10 : Choisir des algorithmes modernes

Étape 11 : Gérer plusieurs clés et la rotation

Étape 12 : Renforcer avec une clé matérielle FIDO2

Déployer les clés SSH en équipe et à grande échelle

Comparatif des types de clés SSH

5 pièges courants à éviter

Dépannage : 8 erreurs fréquentes

Astuces avancées pour aller plus loin

Restreindre une clé à une seule commande

Auditer les connexions par clé

Rebondir via un hôte bastion

Et la cryptographie post-quantique ?

Projet complet : du poste au serveur durci

Questions fréquentes sur les clés SSH

Une clé SSH peut-elle être piratée ?

Faut-il une clé différente par serveur ?

Que faire si j’oublie ma phrase secrète ?

Ed25519 ou RSA, lequel choisir ?

Comment supprimer l’accès d’un utilisateur ?

Les clés SSH fonctionnent-elles sur Windows ?

Dois-je sauvegarder ma clé privée ?

Derniers articles

Clé SSH : connexion sans mot de passe, 12 étapes [2026]

Pourquoi abandonner les mots de passe SSH en 2026

Comment fonctionne l’authentification par clé SSH

Pourquoi Ed25519 plutôt que RSA

Prérequis et versions logicielles

Étape 1 : Vérifier OpenSSH et sa version

Étape 2 : Générer une paire de clés Ed25519

Étape 3 : Comprendre les fichiers générés

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

Étape 5 : Tester la connexion par clé

Étape 6 : Charger la clé dans ssh-agent

Étape 7 : Simplifier les accès avec ~/.ssh/config

Étape 8 : Désactiver les mots de passe côté serveur

Étape 9 : Restreindre utilisateurs, port et écoute

Étape 10 : Choisir des algorithmes modernes

Étape 11 : Gérer plusieurs clés et la rotation

Étape 12 : Renforcer avec une clé matérielle FIDO2

Déployer les clés SSH en équipe et à grande échelle

Comparatif des types de clés SSH

5 pièges courants à éviter

Dépannage : 8 erreurs fréquentes

Astuces avancées pour aller plus loin

Restreindre une clé à une seule commande

Auditer les connexions par clé

Rebondir via un hôte bastion

Et la cryptographie post-quantique ?

Projet complet : du poste au serveur durci

Questions fréquentes sur les clés SSH

Une clé SSH peut-elle être piratée ?

Faut-il une clé différente par serveur ?

Que faire si j’oublie ma phrase secrète ?

Ed25519 ou RSA, lequel choisir ?

Comment supprimer l’accès d’un utilisateur ?

Les clés SSH fonctionnent-elles sur Windows ?

Dois-je sauvegarder ma clé privée ?

Related Coverage

Derniers articles