L’authentification par clé SSH protège vos serveurs contre 99 % des attaques automatisées basées sur les mots de passe. Ce tutoriel vous guide à travers 12 étapes pour générer, configurer et sécuriser des clés SSH Ed25519 ou RSA 4 096 bits sur Linux, macOS et Windows, en moins de 30 minutes.

Pourquoi utiliser les clés SSH plutôt que les mots de passe

Les mots de passe SSH sont vulnérables aux attaques par force brute, aux attaques par dictionnaire et à l’hameçonnage. Un serveur exposé sur Internet reçoit en moyenne plusieurs milliers de tentatives de connexion par mot de passe chaque jour. Les clés SSH éliminent entièrement ce vecteur d’attaque.

Une clé SSH Ed25519 256 bits offre une sécurité équivalente à une clé RSA de 3 000 bits, avec des opérations cryptographiques nettement plus rapides. La paire de clés fonctionne sur le principe de la cryptographie asymétrique : vous gardez la clé privée sur votre machine locale, et déposez la clé publique sur les serveurs auxquels vous souhaitez accéder.

Lorsque vous vous connectez, le serveur chiffre un défi aléatoire avec votre clé publique. Seul le détenteur de la clé privée correspondante peut déchiffrer ce défi et prouver son identité. Aucun mot de passe ne transite sur le réseau. En production, désactiver l’authentification par mot de passe au profit des clés SSH est l’une des mesures de durcissement les plus efficaces que vous pouvez appliquer en quelques minutes.

Les clés SSH sont aussi plus pratiques : une fois l’agent SSH configuré, vous vous connectez à vos serveurs sans saisir de mot de passe. Vous pouvez automatiser les déploiements, les sauvegardes et les scripts d’administration sans stocker de mots de passe en clair dans vos fichiers de configuration.

Prérequis

Avant de commencer, vérifiez que vous disposez des éléments suivants :

  • Client SSH : OpenSSH 8.0 ou supérieur (préinstallé sur Ubuntu 20.04+, Debian 11+, Fedora 35+, macOS 12+, Windows 10 build 1803+)
  • Serveur distant : Un serveur Linux avec accès SSH actif (port 22 par défaut)
  • Accès à un terminal : bash, zsh, PowerShell 7+ ou Windows Terminal
  • Droits administrateur : sudo ou accès root sur le serveur pour modifier sshd_config
  • Adresse IP ou nom de domaine : du serveur cible
  • Connexion Internet : pour le premier accès par mot de passe lors du dépôt de la clé

Vérifiez votre version d’OpenSSH avec cette commande :

ssh -V

Exemple de sortie :

OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 Jan 2024

Si votre version est antérieure à 6.5, Ed25519 n’est pas supporté. Dans ce cas, mettez à jour OpenSSH ou utilisez RSA 4 096 bits. Sur Ubuntu et Debian, la mise à jour s’effectue avec sudo apt update && sudo apt install openssh-client openssh-server.

Vue d’ensemble : comment fonctionne l’authentification par clé SSH

L’authentification par clé SSH repose sur la cryptographie asymétrique. Voici le flux complet d’une connexion réussie :

  1. Le client SSH propose sa clé publique au serveur
  2. Le serveur vérifie que cette clé est présente dans ~/.ssh/authorized_keys
  3. Le serveur génère un défi aléatoire et le chiffre avec la clé publique du client
  4. Le client déchiffre le défi avec sa clé privée
  5. Le client envoie la réponse déchiffrée, combinée à un identifiant de session
  6. Le serveur vérifie la réponse et autorise la connexion sans aucun mot de passe

Ce mécanisme garantit que la clé privée ne quitte jamais votre machine locale. Même si un attaquant intercepte la communication, il ne peut pas retrouver la clé privée à partir du défi chiffré.

AlgorithmeTaille de cléSécurité équivalente RSAPerformance signatureRecommandation 2026
Ed25519256 bits~3 000 bitsTrès rapidePremier choix
RSA 40964 096 bits4 096 bitsMoyenCompatibilité legacy
ECDSA 256256 bits~3 000 bitsRapideDéconseillé
RSA 20482 048 bits2 048 bitsMoyenDéprécié
DSA 10241 024 bitsInsuffisantLentInterdit
Ed25519-SK256 bits~3 000 bitsTrès rapideYubiKey/FIDO2

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

Ed25519 est l’algorithme recommandé pour tous les nouveaux déploiements en 2026. Il utilise la courbe elliptique Curve25519, conçue par Daniel J. Bernstein, avec des paramètres publiquement vérifiables. Ses avantages par rapport à RSA sont multiples : clés beaucoup plus courtes (68 octets contre ~800 pour RSA 4096), signatures rapides et un mécanisme déterministe qui élimine les risques liés à un générateur de nombres aléatoires défaillant.

Sur votre machine locale, exécutez :

ssh-keygen -t ed25519 -C "[email protected]"

Sortie attendue :

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/utilisateur/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/utilisateur/.ssh/id_ed25519
Your public key has been saved in /home/utilisateur/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz1234567890abcdef [email protected]
The key's randomart image is:
+--[ED25519 256]--+
|        .o+o..   |
|       . ooo.    |
|        =...     |
|       . *       |
|      S . +      |
+----[SHA256]-----+

Par défaut, ssh-keygen crée deux fichiers :

  • ~/.ssh/id_ed25519 : votre clé privée, à ne jamais partager
  • ~/.ssh/id_ed25519.pub : votre clé publique, à déposer sur les serveurs

Pour nommer la clé différemment, recommandé si vous gérez plusieurs serveurs ou comptes :

ssh-keygen -t ed25519 -C "serveur-prod-2026" -f ~/.ssh/id_ed25519_prod

Vérifiez que la clé est bien générée :

ls -la ~/.ssh/

Affichez votre clé publique pour la copier sur un serveur :

cat ~/.ssh/id_ed25519.pub

Sortie (la vôtre sera différente) :

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcgkBFKMOmNyFJ1VzMz2J5HkqLbGgB7XzABCDE12345 [email protected]

Étape 2 : générer une clé RSA 4 096 bits pour la compatibilité

Certains systèmes plus anciens ne supportent pas Ed25519 : équipements réseau sous firmware vieillissant, serveurs sous CentOS 6, ou certains clients SSH Windows préinstallés. Dans ces cas, utilisez RSA 4 096 bits.

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Sortie attendue :

Generating public/private rsa key pair.
Enter file in which to save the key (/home/utilisateur/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/utilisateur/.ssh/id_rsa
Your public key has been saved in /home/utilisateur/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:XyZaBcDeFgHiJkLmNoPqRsTuVwXyZ12345678abcdef [email protected]

N’utilisez jamais RSA 1 024 ou 2 048 bits pour de nouveaux projets. RSA 1 024 bits est considéré cassable avec des ressources importantes. RSA 2 048 bits reste acceptable pour la compatibilité héritée, mais 4 096 bits est la taille minimale recommandée pour les nouvelles clés RSA en 2026.

Pour vérifier la taille et l’empreinte de votre clé :

ssh-keygen -l -f ~/.ssh/id_rsa.pub

Sortie :

4096 SHA256:XyZaBcDeFgHiJkLmNoPqRsTuVwXyZ12345678abcdef [email protected] (RSA)

Le premier chiffre (4096) confirme la taille de la clé. Si vous voyez 2048 ou moins, régénérez la clé avec -b 4096.

Étape 3 : protéger la clé privée avec une phrase de passe

La phrase de passe chiffre votre clé privée sur disque avec AES-256-CBC. Si quelqu’un accède physiquement à votre machine ou vole le fichier de clé, il ne peut pas l’utiliser sans la phrase de passe. Utilisez une phrase de passe d’au moins 14 caractères, en combinant lettres, chiffres et caractères spéciaux. Une phrase entière est plus facile à retenir qu’une suite de caractères aléatoires et peut être tout aussi sécurisée.

Pour ajouter ou modifier la phrase de passe d’une clé existante :

ssh-keygen -p -f ~/.ssh/id_ed25519

Sortie :

Enter old passphrase:
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

Définissez maintenant les permissions correctes sur vos fichiers SSH. Des permissions trop ouvertes empêchent OpenSSH de fonctionner :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config 2>/dev/null || true

Vérifiez les permissions :

ls -la ~/.ssh/

Sortie attendue :

drwx------  2 utilisateur utilisateur 4096 jun 19 10:00 .
drwxr-xr-x 25 utilisateur utilisateur 4096 jun 19 09:58 ..
-rw-------  1 utilisateur utilisateur  411 jun 19 10:00 id_ed25519
-rw-r--r--  1 utilisateur utilisateur  100 jun 19 10:00 id_ed25519.pub

Étape 4 : copier la clé publique sur le serveur avec ssh-copy-id

ssh-copy-id est l’outil le plus simple pour déposer votre clé publique sur un serveur distant. Il gère automatiquement la création du répertoire ~/.ssh et du fichier authorized_keys avec les bonnes permissions.

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@adresse-ip-serveur

Exemple avec un port non standard :

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected]

Sortie attendue :

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/utilisateur/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

Sur macOS, si ssh-copy-id n’est pas disponible, installez-le via Homebrew :

brew install ssh-copy-id

Sur Windows avec PowerShell, copiez manuellement avec cette commande :

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "cat >> ~/.ssh/authorized_keys"

Si le répertoire ~/.ssh n’existe pas encore sur le serveur, créez-le d’abord :

ssh [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh"

Étape 5 : configurer authorized_keys manuellement

Si ssh-copy-id n’est pas disponible, ou si vous administrez plusieurs utilisateurs sur un serveur sans accès direct, configurez authorized_keys manuellement.

Connectez-vous au serveur avec un mot de passe ou via un accès console, puis exécutez :

# Sur le serveur distant
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Copiez le contenu de votre clé publique depuis votre machine locale :

# Sur votre machine locale
cat ~/.ssh/id_ed25519.pub

Sur le serveur, ajoutez la clé publique au fichier authorized_keys :

echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcg... [email protected]" >> ~/.ssh/authorized_keys

Vérifiez le contenu du fichier :

cat ~/.ssh/authorized_keys

Vous pouvez restreindre une clé à certaines adresses IP sources ou à une seule commande grâce aux options authorized_keys :

# Restreindre à une adresse IP source
from="192.168.1.50" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... [email protected]

# Limiter à une seule commande (pour les scripts de sauvegarde)
command="rsync --server -avz . /backup/",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... [email protected]

# Combinaison : IP source et commande unique
from="10.0.0.5",command="/usr/bin/rsync --server -avz . /data/" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... [email protected]

Ces restrictions permettent d’accorder un accès SSH minimal à des scripts d’automatisation sans risquer qu’une clé volée soit utilisée pour un accès shell complet.

Étape 6 : tester la connexion SSH par clé

Avant de désactiver l’authentification par mot de passe, testez la connexion par clé dans une nouvelle session distincte, en gardant votre session actuelle ouverte. Si quelque chose tourne mal, vous conservez l’accès.

ssh -i ~/.ssh/id_ed25519 [email protected]

Pour forcer l’authentification par clé uniquement et diagnostiquer les problèmes :

ssh -v -i ~/.ssh/id_ed25519 -o PasswordAuthentication=no [email protected]

Sortie partielle en mode verbeux lors d’une connexion réussie :

debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: Authenticating to 192.168.1.100:22 as 'utilisateur'
debug1: Offering public key: /home/utilisateur/.ssh/id_ed25519 ED25519 SHA256:AbCdEf...
debug1: Server accepts key: /home/utilisateur/.ssh/id_ed25519 ED25519 SHA256:AbCdEf...
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.100 ([192.168.1.100]:22).

La ligne Authentication succeeded (publickey) confirme que la connexion utilise bien votre clé SSH. Si vous voyez à la place Authentication succeeded (password), la configuration de la clé est incorrecte.

Étape 7 : désactiver l’authentification par mot de passe

Une fois la connexion par clé validée et testée, désactivez l’authentification par mot de passe sur le serveur. Cette étape élimine 99 % des tentatives d’attaque par force brute automatisées.

Connectez-vous au serveur avec votre clé SSH, puis éditez le fichier de configuration du daemon SSH :

sudo nano /etc/ssh/sshd_config

Trouvez et modifiez ou ajoutez les directives suivantes :

# Désactiver l'authentification par mot de passe
PasswordAuthentication no

# Désactiver l'authentification par clavier interactif
KbdInteractiveAuthentication no

# Désactiver les mots de passe vides
PermitEmptyPasswords no

# Désactiver la connexion root directe
PermitRootLogin no

# Activer l'authentification par clé publique
PubkeyAuthentication yes

# Spécifier le fichier authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

Testez la configuration avant de recharger :

sudo sshd -t

Si cette commande ne retourne rien, la syntaxe est valide. Rechargez la configuration sans couper les connexions existantes :

# Sur Ubuntu et Debian
sudo systemctl reload ssh

# Sur CentOS, RHEL, Fedora, AlmaLinux
sudo systemctl reload sshd

Depuis une troisième fenêtre de terminal, vérifiez qu’il est impossible de se connecter par mot de passe :

ssh -o PasswordAuthentication=yes -o PubkeyAuthentication=no [email protected]

Sortie attendue :

[email protected]: Permission denied (publickey).

Étape 8 : utiliser ssh-agent pour gérer les clés

Si votre clé privée est protégée par une phrase de passe, vous devrez la saisir à chaque connexion. ssh-agent stocke la clé déchiffrée en mémoire pour la durée de votre session, vous évitant de la saisir plusieurs fois.

Démarrez ssh-agent et ajoutez votre clé :

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

Sortie :

Agent pid 12345
Enter passphrase for /home/utilisateur/.ssh/id_ed25519:
Identity added: /home/utilisateur/.ssh/id_ed25519 ([email protected])

Pour lister les clés chargées dans l’agent :

ssh-add -l

Sortie :

256 SHA256:AbCdEf... [email protected] (ED25519)

Sur macOS, ajoutez votre clé au trousseau Keychain pour qu’elle se recharge automatiquement après chaque redémarrage :

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Ajoutez ces lignes à votre ~/.ssh/config sur macOS :

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

Sur Linux, pour que ssh-agent démarre automatiquement à chaque ouverture de terminal, ajoutez ceci à votre ~/.bashrc ou ~/.zshrc :

if [ -z "$SSH_AUTH_SOCK" ]; then
  eval "$(ssh-agent -s)" > /dev/null
  ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi

Pour supprimer une clé de l’agent sans tuer le processus :

ssh-add -d ~/.ssh/id_ed25519

Étape 9 : configurer le fichier ~/.ssh/config

Le fichier ~/.ssh/config simplifie la gestion de multiples serveurs SSH en définissant des alias et des options par hôte. Il vous évite de taper l’adresse IP complète, le port ou le nom d’utilisateur à chaque connexion.

nano ~/.ssh/config

Exemple de configuration complète avec plusieurs serveurs :

# Serveur de production
Host prod
  HostName 203.0.113.10
  User deployer
  IdentityFile ~/.ssh/id_ed25519_prod
  Port 2222
  IdentitiesOnly yes

# Serveur de staging
Host staging
  HostName 203.0.113.20
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519
  Port 22
  IdentitiesOnly yes

# Bastion SSH (jump host)
Host bastion
  HostName bastion.entreprise.fr
  User admin
  IdentityFile ~/.ssh/id_ed25519
  Port 22

# Serveur interne via bastion
Host serveur-interne
  HostName 10.0.0.50
  User admin
  ProxyJump bastion
  IdentityFile ~/.ssh/id_ed25519

# Configuration globale
Host *
  ServerAliveInterval 60
  ServerAliveCountMax 3
  IdentitiesOnly yes
  AddKeysToAgent yes

Avec cette configuration, vous vous connectez au serveur de production avec :

ssh prod

La directive IdentitiesOnly yes empêche ssh d’essayer toutes les clés de l’agent avant d’utiliser celle spécifiée. Sans cette option, des serveurs avec des politiques restrictives (MaxAuthTries bas) peuvent refuser la connexion après trop de tentatives. ServerAliveInterval 60 envoie un paquet keepalive toutes les 60 secondes pour éviter les déconnexions intempestives dues aux pare-feux.

Définissez les bonnes permissions sur ce fichier :

chmod 600 ~/.ssh/config

Étape 10 : configurer les clés SSH pour GitHub et GitLab

GitHub et GitLab utilisent les clés SSH pour authentifier les opérations Git (clone, push, pull) sans mot de passe. Voici comment configurer une clé dédiée et gérer plusieurs comptes sur la même machine.

Générez une clé dédiée pour GitHub :

ssh-keygen -t ed25519 -C "git@github-compte-pro" -f ~/.ssh/id_ed25519_github

Affichez votre clé publique :

cat ~/.ssh/id_ed25519_github.pub

Sur GitHub, allez dans Paramètres > Clés SSH et GPG > Nouvelle clé SSH. Collez le contenu de votre clé publique. Choisissez un titre descriptif comme “MacBook Pro 2026” ou “Laptop Dev”.

Ajoutez une entrée dans ~/.ssh/config :

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github
  IdentitiesOnly yes

Host gitlab.com
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_ed25519_gitlab
  IdentitiesOnly yes

Testez la connexion à GitHub :

ssh -T [email protected]

Sortie attendue :

Hi votre-nom-utilisateur! You've successfully authenticated, but GitHub does not provide shell access.

Pour gérer plusieurs comptes GitHub, un personnel et un professionnel, sur la même machine :

Host github-perso
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github_perso
  IdentitiesOnly yes

Host github-pro
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github_pro
  IdentitiesOnly yes

Clonez les dépôts en utilisant l’alias correspondant :

# Compte personnel
git clone git@github-perso:votre-pseudo/mon-projet.git

# Compte professionnel
git clone git@github-pro:entreprise/projet-pro.git

Étape 11 : rotation et révocation des clés SSH

La rotation régulière des clés SSH est une pratique essentielle dans les environnements professionnels. Une clé compromise représente un accès permanent jusqu’à sa révocation. Voici la procédure complète pour effectuer une rotation sans interruption de service.

Pour révoquer une clé, supprimez la ligne correspondante dans ~/.ssh/authorized_keys sur le serveur :

# Vérifier les clés actuellement autorisées
cat ~/.ssh/authorized_keys

# Supprimer une clé par son commentaire
sed -i '/[email protected]/d' ~/.ssh/authorized_keys

# Vérifier la suppression
cat ~/.ssh/authorized_keys

Procédure de rotation en 3 étapes sans coupure de service :

  1. Générez une nouvelle paire de clés sur votre machine locale : ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_nouveau
  2. Ajoutez la nouvelle clé publique dans authorized_keys sur chaque serveur, les deux clés coexistant temporairement
  3. Testez la connexion avec la nouvelle clé, puis supprimez l’ancienne

Pour les environnements avec plusieurs serveurs, ce script automatise la rotation :

#!/bin/bash
# Script de rotation de clé SSH sur plusieurs serveurs

NOUVELLE_CLE=$(cat ~/.ssh/id_ed25519_nouveau.pub)
ANCIENNE_CLE_COMMENTAIRE="[email protected]"
SERVEURS=("prod1.domaine.fr" "prod2.domaine.fr" "staging.domaine.fr")

for SERVEUR in "${SERVEURS[@]}"; do
  echo "Traitement de $SERVEUR..."

  # Ajouter la nouvelle clé
  ssh utilisateur@$SERVEUR "echo '$NOUVELLE_CLE' >> ~/.ssh/authorized_keys"

  # Tester la connexion avec la nouvelle clé
  if ssh -i ~/.ssh/id_ed25519_nouveau utilisateur@$SERVEUR "echo 'Connexion OK'" 2>/dev/null; then
    # Supprimer l'ancienne clé seulement si la nouvelle fonctionne
    ssh -i ~/.ssh/id_ed25519_nouveau utilisateur@$SERVEUR \
      "sed -i '/$ANCIENNE_CLE_COMMENTAIRE/d' ~/.ssh/authorized_keys"
    echo "$SERVEUR : rotation terminee avec succes"
  else
    echo "$SERVEUR : ECHEC - ancienne cle conservee"
  fi
done

Étape 12 : durcissement avancé du serveur SSH (sshd_config)

La configuration par défaut de sshd n’est pas optimisée pour la sécurité en production. Voici une configuration durcie pour 2026, qui limite les algorithmes aux plus sûrs et réduit la surface d’attaque. Cette configuration s’aligne avec les recommandations de l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) pour la sécurisation des accès SSH.

# /etc/ssh/sshd_config - Configuration durcie 2026

# Port non standard (réduit le bruit des scans automatiques)
Port 2222

# Écouter uniquement en IPv4 si IPv6 non nécessaire
AddressFamily inet

# Clés d'hôte (Ed25519 en priorité)
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Algorithmes d'échange de clés
KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group16-sha512

# Chiffrements authentifiés
Ciphers [email protected],[email protected],[email protected]

# Codes d'authentification de message
MACs [email protected],[email protected]

# Authentification
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
UsePAM yes

# Restrictions d'accès
PermitRootLogin no
AllowUsers deployer admin
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

# Désactiver les fonctionnalités inutiles
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
PrintMotd no

# Journalisation détaillée
LogLevel VERBOSE
SyslogFacility AUTH

# Keepalive
ClientAliveInterval 300
ClientAliveCountMax 2

Validez et rechargez :

sudo sshd -t && sudo systemctl reload sshd

Si vous changez le port SSH, mettez à jour votre pare-feu. Sur Ubuntu avec ufw :

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo ufw status

Comparaison des algorithmes SSH : Ed25519, RSA, ECDSA en détail

Le choix d’algorithme détermine la résistance de votre clé SSH aux attaques actuelles et futures. Voici un tableau de décision complet pour 2026 :

CritèreEd25519RSA 4096ECDSA 256DSA 1024
Taille de clé publique68 octets~800 octets~180 octets~444 octets
Vitesse de signatureTrès rapideLenteRapideLente
Résistance PRNG faibleOui (déterministe)PartielleNon (vulnérable)Non (vulnérable)
Support OpenSSH depuis6.5 (2014)Depuis l’origine5.7 (2011)Obsolète
Supporté GitHub 2026OuiOuiOuiNon
Compatibilité legacyBonne (post-2014)UniverselleBonneAucune
Recommandation 2026Premier choixCompatibilitéDéconseilléInterdit

L’avantage majeur d’Ed25519 sur ECDSA repose dans son caractère déterministe. ECDSA génère un nonce aléatoire à chaque signature : si ce nonce est répété ou prévisible, la clé privée peut être mathématiquement reconstruite. C’est exactement ce qui s’est produit avec la PlayStation 3 en 2010, dont la clé privée ECDSA a été exposée à cause d’un nonce fixe. Ed25519 évite ce risque par construction.

DSA est désactivé par défaut depuis OpenSSH 7.0 (2015) et complètement supprimé depuis OpenSSH 9.0 (2022). Ne l’utilisez sous aucun prétexte.

5 pièges courants et comment les éviter

Ces erreurs représentent la quasi-totalité des cas de support liés à la configuration SSH. Vérifiez-les systématiquement avant de conclure que votre configuration est défaillante.

Piège 1 : permissions incorrectes sur les fichiers SSH

OpenSSH refuse de fonctionner si les permissions des fichiers SSH sont trop ouvertes. C’est la cause d’échec la plus fréquente, surtout après une copie de fichiers ou un changement de propriétaire.

Fichier / RépertoirePermission correcteErreur courante
~/.ssh/700 (drwx——)755 ou 777
~/.ssh/authorized_keys600 (-rw——-)644 ou 777
~/.ssh/id_ed25519600 (-rw——-)644 ou 755
~/.ssh/id_ed25519.pub644 (-rw-r–r–)777
~/.ssh/config600 (-rw——-)644 ou 755
Répertoire home /home/user755 (drwxr-xr-x)777 (bloque StrictModes)

Corrigez toutes les permissions en une seule commande :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys ~/.ssh/id_ed25519 ~/.ssh/config 2>/dev/null
chmod 644 ~/.ssh/id_ed25519.pub

Piège 2 : désactiver les mots de passe avant de tester la clé

Ne modifiez jamais PasswordAuthentication no dans sshd_config sans avoir au préalable testé la connexion par clé dans une session séparée, en gardant votre session actuelle ouverte. Si votre clé ne fonctionne pas et que vous coupez l’accès par mot de passe, vous vous retrouvez bloqué hors du serveur. Sur un VPS, vous aurez besoin d’accéder à la console de secours du fournisseur pour corriger l’erreur.

Piège 3 : confondre clé publique et clé privée

La clé publique (.pub) se dépose sur les serveurs dans authorized_keys. La clé privée (sans extension) reste exclusivement sur votre machine locale. Déposer la clé privée sur un serveur représente une faille de sécurité critique. Si cela se produit, générez immédiatement une nouvelle paire de clés, déployez la nouvelle clé publique sur tous vos serveurs, et supprimez l’ancienne clé compromise de tous les authorized_keys.

Piège 4 : répertoire home avec permissions incorrectes (StrictModes)

OpenSSH active par défaut StrictModes yes, qui vérifie les permissions du répertoire home de l’utilisateur. Si /home/utilisateur est accessible en écriture par d’autres (permission 777), SSH refuse l’authentification par clé même si authorized_keys est correctement configuré. Vérifiez :

ls -ld ~
# Attendu : drwxr-xr-x (755) ou drwx------ (700)
# Interdit : drwxrwxrwx (777)

Piège 5 : clé publique copiée avec des sauts de ligne

Une clé SSH publique doit tenir sur une seule ligne dans authorized_keys. Si vous copiez-collez depuis un éditeur de texte qui insère des retours à la ligne automatiques (Word, certains éditeurs de code), la clé devient invalide. Utilisez toujours cat pour afficher la clé, et vérifiez avec :

# Compter les lignes (1 ligne par clé)
wc -l ~/.ssh/authorized_keys

# Vérifier la syntaxe de la clé
ssh-keygen -l -f ~/.ssh/authorized_keys

Dépannage : 8 erreurs SSH fréquentes

Ces erreurs couvrent 95 % des problèmes de connexion SSH rencontrés après la configuration de l’authentification par clé.

Erreur 1 : Permission denied (publickey)

Cause : La clé n’est pas dans authorized_keys, les permissions sont incorrectes, ou PubkeyAuthentication est désactivé sur le serveur.

# Diagnostic côté client
ssh -vvv utilisateur@serveur 2>&1 | grep -A2 "Offering\|Server accepts\|denied"

# Diagnostic côté serveur
sudo journalctl -u sshd -n 50 --no-pager | grep -i "auth\|key\|denied"

# Sur les systèmes sans journald
sudo tail -50 /var/log/auth.log | grep -i ssh

Erreur 2 : Too many authentication failures

Cause : ssh-agent propose trop de clés et le serveur atteint MaxAuthTries avant que la bonne clé soit essayée.

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes utilisateur@serveur

Erreur 3 : WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Cause : L’empreinte du serveur a changé (réinstallation, migration). Vérifiez physiquement l’empreinte avant de supprimer l’entrée, car cette erreur peut aussi indiquer une attaque man-in-the-middle.

# Sur le serveur, récupérez l'empreinte actuelle
sudo ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

# Sur le client, supprimez l'ancienne entrée après vérification
ssh-keygen -R 192.168.1.100

Erreur 4 : Could not open a connection to your authentication agent

Cause : ssh-agent n’est pas démarré ou la variable d’environnement SSH_AUTH_SOCK n’est pas définie.

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

Erreur 5 : No supported authentication methods available

Cause : Le serveur n’accepte que l’authentification par clé, mais aucune clé valide n’est proposée. Vérifiez que ssh-agent contient votre clé (ssh-add -l) et que ~/.ssh/config pointe vers la bonne clé pour cet hôte.

Erreur 6 : Bad permissions on /home/user/.ssh

Cause : StrictModes détecte des permissions trop ouvertes sur le répertoire home ou ~/.ssh.

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
chmod 755 ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Erreur 7 : Connection refused (port 22)

Cause : Le service SSH n’écoute pas sur le port 22, ou un pare-feu bloque la connexion.

# Vérifier le statut du service
sudo systemctl status sshd

# Vérifier les ports d'écoute
sudo ss -tlnp | grep ssh

# Tester un port alternatif
ssh -p 2222 utilisateur@serveur

Erreur 8 : Load key: bad permissions

Cause : Les permissions de la clé privée sont trop ouvertes, d’autres utilisateurs peuvent la lire.

chmod 600 ~/.ssh/id_ed25519
ls -la ~/.ssh/id_ed25519
# Attendu : -rw------- 1 utilisateur utilisateur ...

Conseils avancés : clés matérielles et certificats SSH

Pour les environnements à haute sécurité, plusieurs techniques avancées permettent d’aller bien au-delà des clés logicielles stockées sur disque.

Clés SSH sur YubiKey : Depuis OpenSSH 8.2, les types de clés ed25519-sk et ecdsa-sk permettent de générer des clés SSH dont la partie privée réside sur un dispositif FIDO2 (YubiKey, SoloKey). La clé privée ne quitte jamais le hardware, même si votre machine est compromise.

# Générer une clé SSH résidente sur YubiKey (nécessite OpenSSH 8.2+ et libfido2)
ssh-keygen -t ed25519-sk -O resident -C "yubikey-prod-2026"

# Récupérer les clés résidentes sur une nouvelle machine
ssh-keygen -K

Certificats SSH : Pour les équipes de plus de 10 personnes, la gestion des authorized_keys sur chaque serveur devient rapidement ingérable. Les certificats SSH permettent à chaque serveur de faire confiance à une Autorité de Certification (CA SSH), éliminant la nécessité de déployer des clés individuelles. Chaque utilisateur reçoit un certificat signé par la CA, avec une durée de validité limitée.

# Créer une CA SSH (sur un serveur de gestion sécurisé)
ssh-keygen -t ed25519 -f /etc/ssh/ca_utilisateurs -C "CA SSH Production 2026"

# Signer la clé d'un utilisateur (validité 30 jours)
ssh-keygen -s /etc/ssh/ca_utilisateurs \
  -I "[email protected]" \
  -n deployer,admin \
  -V +30d \
  ~/.ssh/id_ed25519.pub

# Sur chaque serveur cible, faire confiance à la CA
echo "TrustedUserCAKeys /etc/ssh/ca_utilisateurs.pub" | sudo tee -a /etc/ssh/sshd_config
sudo systemctl reload sshd

Audit des clés SSH : Examinez régulièrement les clés autorisées sur vos serveurs. Des clés orphelines d’anciens collaborateurs ou de services dépréciés représentent un risque permanent souvent sous-estimé.

# Trouver tous les fichiers authorized_keys sur le système
sudo find /home /root /etc -name "authorized_keys" -type f 2>/dev/null

# Surveiller les connexions SSH réussies
last -n 20 | grep -v "^$"

# Analyser les tentatives d'authentification échouées par IP
sudo grep "Failed password" /var/log/auth.log | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

FAQ : clés SSH en 2026

Quelle est la différence entre Ed25519 et RSA pour SSH ?

Ed25519 utilise la courbe elliptique Curve25519, produit des clés courtes (68 octets contre ~800 pour RSA 4096), et signe les données plus rapidement. Une clé Ed25519 de 256 bits offre une sécurité comparable à une clé RSA de 3 000 bits. Ed25519 est déterministe, contrairement à ECDSA. Choisissez Ed25519 pour tout nouveau déploiement. Utilisez RSA 4096 uniquement pour la compatibilité avec des systèmes ne supportant pas Ed25519.

Dois-je utiliser une phrase de passe pour ma clé SSH ?

Oui, dans la quasi-totalité des cas. Une phrase de passe d’au moins 14 caractères chiffre votre clé privée sur disque. Si votre machine est volée ou compromise, la clé reste inutilisable. Utilisez ssh-agent pour ne saisir la phrase de passe qu’une fois par session. Sur macOS, le trousseau Keychain la mémorise entre les redémarrages, ce qui élimine toute friction au quotidien.

Où dois-je stocker mes clés SSH ?

Les clés SSH se stockent dans ~/.ssh/ avec des permissions strictes (700 pour le répertoire, 600 pour les fichiers de clés privées). Pour une sécurité maximale, stockez les clés privées sur un dispositif matériel comme un YubiKey ou une TPM. Ne sauvegardez jamais les clés privées dans un service cloud non chiffré sans chiffrement supplémentaire comme VeraCrypt ou GPG.

Comment savoir si ma connexion utilise l’authentification par clé ?

Utilisez ssh -v utilisateur@serveur et cherchez la ligne Authentication succeeded (publickey). Si vous voyez Authentication succeeded (password), la connexion utilise le mot de passe. Vous pouvez forcer l’authentification par clé uniquement avec ssh -o PasswordAuthentication=no utilisateur@serveur.

Peut-on utiliser la même clé SSH sur plusieurs serveurs ?

Techniquement oui, mais ce n’est pas la meilleure pratique. Si la clé est compromise, tous les serveurs où elle est déployée sont exposés simultanément. Utilisez des clés distinctes par environnement (développement, staging, production) ou par service. Cela limite l’impact d’une compromission et facilite la révocation ciblée sans affecter les autres accès.

Comment désactiver l’accès SSH d’un utilisateur sans le supprimer ?

Deux méthodes : (1) supprimez sa ligne dans ~/.ssh/authorized_keys, ou (2) ajoutez son nom à DenyUsers dans /etc/ssh/sshd_config avec la directive DenyUsers ex-employe. La deuxième méthode est plus robuste car elle s’applique même si la clé est réajoutée ultérieurement par erreur.

Quelle est la différence entre ssh-keygen -t ed25519 et -t ecdsa ?

Les deux utilisent des courbes elliptiques, mais ECDSA emploie des courbes NIST (P-256, P-384, P-521) dont les paramètres de génération suscitent des interrogations chez certains cryptographes. ECDSA nécessite un bon générateur aléatoire à chaque signature et est vulnérable si ce générateur est défaillant. Ed25519 utilise Curve25519 avec une signature déterministe, éliminant ce risque. Choisissez toujours Ed25519.

ssh-copy-id ne fonctionne pas : que faire ?

Si ssh-copy-id échoue, copiez manuellement votre clé publique. Affichez-la avec cat ~/.ssh/id_ed25519.pub, connectez-vous au serveur par un autre moyen (console VPS, accès physique), puis ajoutez la clé avec echo "VOTRE_CLE_PUBLIQUE" >> ~/.ssh/authorized_keys. Vérifiez ensuite les permissions avec chmod 600 ~/.ssh/authorized_keys.

Couverture connexe

Pour renforcer davantage la sécurité de vos serveurs et applications :

Sources :