Sécuriser l’accès SSH par clé

Sur tout serveur Linux accessible depuis internet, la sécurisation de l’accès SSH est une étape indispensable. Par défaut, SSH accepte les connexions par mot de passe, une surface d’attaque importante exposée aux attaques par force brute. L’authentification par clé cryptographique règle ce problème élégamment.

1. Pourquoi l’authentification par clé ?

Un serveur exposé sur internet reçoit en permanence des tentatives de connexion SSH automatisées, des bots qui testent des milliers de combinaisons login/mot de passe à la seconde. L’authentification par clé rend ces attaques totalement inopérantes : sans la clé privée, aucune connexion n’est possible, peu importe le mot de passe tenté.

2. Comprendre la cryptographie asymétrique

L’authentification par clé repose sur la cryptographie asymétrique : une paire de clés mathématiquement liées est générée.

• La clé publique est déposée sur le serveur, elle peut être partagée librement
• La clé privée reste sur votre machine et ne la quitte jamais

Lors de la connexion, le serveur envoie un défi chiffré avec votre clé publique. Seule votre clé privée peut le déchiffrer et prouver votre identité, sans jamais transmettre de mot de passe sur le réseau.

3. Pourquoi Ed25519 ?

Il existe plusieurs algorithmes pour générer des paires de clés SSH. Ed25519 est aujourd’hui le standard recommandé.

Ed25519 se décompose ainsi :

• Ed : Edwards-curve Digital Signature Algorithm (EdDSA), famille d’algorithmes de signature numérique basée sur les courbes elliptiques d’Edwards
• 25519 : fait référence au nombre premier 2²⁵⁵ – 19 qui définit la courbe elliptique utilisée, appelée Curve25519, conçue par le cryptographe Daniel J. Bernstein en 2005

Algo.	Taille clé	Sécurité	Vitesse	Recommandé
RSA	2048-4096 bits	Correct	Lent	Ancien
ECDSA	256 bits	Moyen	Rapide	Vulnérabilités connues
Ed25519	256 bits	Excellent	Très rapide	✅ Oui

Ed25519 est recommandé car :

• Clés très courtes — 256 bits suffisent pour une sécurité équivalente à RSA-3000 bits
• Très rapide en signature et vérification
• Aucune vulnérabilité connue contrairement à ECDSA qui dépend d’un générateur aléatoire
• Déterministe — la signature ne dépend pas d’un aléa, éliminant une classe entière d’attaques
• Standard adopté par GitHub, GitLab et OpenSSH depuis 2014

4. Mise en place l’authentification par clé

Étape 1 — Générer la paire de clés

Depuis votre ordinateur (pas le serveur), ouvrez un terminal et lancez :

ssh-keygen -t ed25519 -C "mon pc perso"

L’option -C est un simple commentaire ajouté à la fin de la clé publique. Il n’a aucun impact sur la sécurité ou le fonctionnement de la clé, il sert uniquement à identifier la clé. Si vous ouvrez votre clé publique après génération vous verrez :

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... mon pc perso

Pratique quand vous gérez plusieurs clés sur plusieurs serveurs.

Le système demande ensuite :

• Where to save the key → appuiez sur Entrée (chemin par défaut ~/.ssh/id_ed25519)
• Passphrase → choisez une passphrase solide, c’est le mot de passe qui protège votre clé privée en cas de vol de votre machine

Vous obtenez deux fichiers :

• ~/.ssh/id_ed25519 — clé privée — ne quitte jamais votre ordinateur
• ~/.ssh/id_ed25519.pub — clé publique — à déposer sur le serveur

Étape 2 — Déposer la clé publique sur le serveur

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@<IP_SERVEUR>

ssh-copy-id se connecte au serveur avec votre mot de passe habituel et ajoute automatiquement votre clé publique dans ~/.ssh/authorized_keys sur le serveur.

Étape 3 — Vérifier la connexion par clé

Sans fermer votre terminal actuel, ouvrez un nouveau terminal et testez :

ssh -i ~/.ssh/id_ed25519 utilisateur@<IP_SERVEUR>

Vous devez vous connecter en étant demandé uniquement la passphrase, plus de mot de passe système.

Ne passez pas à l’étape suivante tant que cette connexion n’est pas confirmée. Sinon vous risquez de vous bloquer hors du serveur.

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

Une fois la connexion par clé confirmée, sur le serveur :

sudo nano /etc/ssh/sshd_config

Vérifiez et modifiez ces lignes :

PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin no

Note sur AuthorizedKeysFile : vous verrez peut-être cette ligne avec deux fichiers .ssh/authorized_keys .ssh/authorized_keys2. Ce n’est pas un problème, le second fichier est un héritage de l’ancien protocole SSH2, conservé par compatibilité. En pratique seul authorized_keys est utilisé.

Sauvegarde avec Ctrl+O, Entrée, Ctrl+X, puis redémarre SSH :

sudo systemctl restart ssh

Étape 5 — Test final

Depuis un nouveau terminal :

ssh utilisateur@<IP_SERVEUR>

La connexion s’établit avec votre passphrase uniquement. Toute tentative de connexion par mot de passe est désormais rejetée par le serveur.

5. Bonus! Créer un alias de connexion

nano ~/.ssh/config

Host monsite.fr
    HostName <IP_SERVEUR>
    User utilisateur
    IdentityFile ~/.ssh/id_ed25519

Vous vous connectez désormais simplement avec :

ssh monsite.fr

SSH utilisera automatiquement le bon utilisateur et la bonne clé, pratique si vous gérez plusieurs serveurs avec des configurations différentes.

Récapitulatif des fichiers impliqués:

Sur votre ordinateur :
~/.ssh/
├── id_ed25519          ← clé privée (ne partage jamais ce fichier)
├── id_ed25519.pub      ← clé publique
└── config              ← alias de connexion

Sur le serveur :
~/.ssh/
└── authorized_keys     ← clé publique déposée par ssh-copy-id

/etc/ssh/
└── sshd_config         ← configuration du serveur SSH

6. Conclusion

L’authentification par clé Ed25519 est aujourd’hui le standard de sécurité pour l’accès SSH. En quelques minutes, on passe d’un serveur vulnérable aux attaques par force brute à un serveur qui ignore simplement toute tentative de connexion par mot de passe. La clé privée ne transitant jamais sur le réseau, la surface d’attaque est réduite au minimum.