SSH Linux : clés Ed25519, config, tunnels et hardening — tutoriel pas-à-pas

📍 Article principal du programme : Linux fondamentaux 2026 — commandes, services, dépannage
Ce tutoriel fait partie du programme « Linux fondamentaux ». Pour la vue d’ensemble, lisez d’abord le guide principal.

Introduction

SSH est la porte d’entrée de tout serveur Linux distant. Mal configurée, c’est aussi la porte la plus attaquée d’Internet — un VPS fraîchement provisionné voit en moyenne plusieurs centaines de tentatives de connexion automatisées par jour, en provenance de scanners qui balaient en permanence les plages d’adresses IP des hébergeurs publics. Ce tutoriel vous fait passer de la connexion par mot de passe (pratique courante mais dangereuse) à une configuration durcie à base de clés Ed25519, agent SSH, fichier ~/.ssh/config, tunnels et bonnes habitudes de production. À la fin, vous saurez configurer une connexion sans mot de passe, désactiver l’authentification faible côté serveur, ouvrir un tunnel pour debug une base distante, et auditer un fichier sshd_config. La référence côté logiciel est OpenSSH 10.3, publiée le 2 avril 2026 par le projet OpenBSD.

Prérequis

• Une machine Linux ou macOS comme client (OpenSSH installé par défaut), ou Windows 11 dont OpenSSH est désormais une fonctionnalité native.
• Un serveur Linux accessible (Ubuntu 24.04/26.04 LTS, Debian 13, AlmaLinux 9, Rocky Linux 9) avec un accès root ou sudo.
• Connaissance des bases de la ligne de commande et des permissions Linux.
• Niveau attendu : intermédiaire débutant.
• Temps estimé : 90 minutes.

Étape 1 — Comprendre comment SSH authentifie

SSH propose plusieurs mécanismes d’authentification, négociés au moment de la connexion. Sur un VPS récent, l’ordre par défaut est typiquement clé publique, puis mot de passe, puis interactif clavier. Le serveur les essaie l’un après l’autre selon ce que le client présente, et accepte la première qui réussit.

L’authentification par mot de passe paraît simple mais elle a deux défauts rédhibitoires en production. D’une part, elle est vulnérable au brute force : les scanners testent en permanence des paires user/password classiques (root/123456, admin/admin, ubuntu/ubuntu) et finissent par tomber sur un mot de passe faible si vous en avez un. D’autre part, elle force un compromis impossible : un mot de passe long et complexe est difficile à mémoriser, donc on le réutilise ailleurs, ce qui crée un effet domino en cas de fuite. La solution moderne est l’authentification par clé publique : on génère sur la machine cliente une paire mathématique privée/publique, on dépose la publique sur le serveur, et on prouve sa possession de la privée à chaque connexion sans la transmettre. Le mot de passe disparaît du protocole.

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

OpenSSH supporte plusieurs algorithmes de clés. RSA 2048 bits est l’historique mais reste correct ; RSA 4096 bits est plus sûr mais plus lent ; ECDSA P-256 est rapide mais moins recommandé. La référence en 2026 est Ed25519, courbe elliptique conçue par Daniel J. Bernstein, courte (32 octets), rapide à signer et à vérifier, et résistante à plusieurs catégories d’attaques connues sur RSA et ECDSA.

ssh-keygen -t ed25519 -C "votre@email.com"
# Enter file in which to save the key (/home/user/.ssh/id_ed25519): [Entrée]
# Enter passphrase (empty for no passphrase): [tapez une phrase de passe robuste]
# Enter same passphrase again: [confirmez]

Trois choix méritent réflexion. L’emplacement par défaut ~/.ssh/id_ed25519 est le bon — l’agent SSH et la plupart des outils le trouvent automatiquement. Le commentaire -C est purement informatif, il s’attache à la clé publique pour vous aider à reconnaître plus tard quelle clé appartient à quoi. La phrase de passe est fortement recommandée : elle chiffre la clé privée sur disque, et même si quelqu’un copie votre fichier id_ed25519, il ne pourra pas l’utiliser sans la phrase. Couplée à ssh-agent (étape 6), elle ne sera demandée qu’une fois par session.

ls -l ~/.ssh/
# -rw------- 1 user user 411 May  5 09:00 id_ed25519        ← clé privée, à protéger
# -rw-r--r-- 1 user user 102 May  5 09:00 id_ed25519.pub    ← clé publique, à diffuser

cat ~/.ssh/id_ed25519.pub
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM... votre@email.com

La clé privée doit être en mode 600 (lecture-écriture pour le propriétaire seul) et le répertoire ~/.ssh en mode 700. SSH refuse d’utiliser une clé dont les permissions sont plus permissives, par sécurité. chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519 && chmod 644 ~/.ssh/id_ed25519.pub remet tout d’aplomb si nécessaire.

Étape 3 — Pousser la clé publique vers le serveur

L’opération consiste à copier le contenu de id_ed25519.pub dans le fichier ~/.ssh/authorized_keys du compte cible sur le serveur. La commande ssh-copy-id automatise ça proprement.

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@adresse-du-serveur
# vous tapez votre mot de passe une dernière fois, la clé est ajoutée
# Number of key(s) added: 1

# Test : la connexion ne doit plus demander de mot de passe (mais peut demander la phrase)
ssh user@adresse-du-serveur

Si ssh-copy-id n’est pas disponible (cas rare sur Windows), la version manuelle marche partout :

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

Une fois la clé en place, ouvrez une nouvelle session SSH pour confirmer que la connexion par clé fonctionne. Ne fermez pas la session précédente avant cette confirmation : si vous avez une faute dans authorized_keys et que la connexion par clé échoue, la session ouverte vous permet de corriger. Cette précaution simple a sauvé bien des administrateurs d’avoir à passer par la console de secours de leur hébergeur.

Étape 4 — Durcir sshd_config côté serveur

La configuration du démon SSH se trouve dans /etc/ssh/sshd_config. Quatre directives, posées tôt, font la majeure partie du travail de durcissement.

sudo nano /etc/ssh/sshd_config

# ajouter ou modifier :
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes

# tester la syntaxe avant de recharger
sudo sshd -t

# recharger sans couper la session courante
sudo systemctl reload ssh    # Debian/Ubuntu
sudo systemctl reload sshd   # Alma/Rocky/RHEL

PermitRootLogin no interdit la connexion directe en root — un attaquant qui devine un mot de passe doit déjà connaître un nom d’utilisateur valide, ce qui élimine 99% du bruit des scanners. PasswordAuthentication no coupe entièrement l’authentification par mot de passe ; n’activez cette ligne qu’après avoir confirmé que votre clé fonctionne. sshd -t est l’équivalent de nginx -t : il vérifie la syntaxe du fichier sans recharger, ce qui évite de casser le serveur sur une faute de frappe.

À lire ensuite, AllowUsers deploy malick restreint la connexion à des comptes nommés ; MaxAuthTries 3 coupe la session après trois échecs ; ClientAliveInterval 300 et ClientAliveCountMax 2 ferment automatiquement les sessions oisives. Évitez la mauvaise idée fréquente de changer le port SSH de 22 vers 2222 : c’est de la sécurité par obscurité qui n’arrête pas les scanners modernes mais complique les outils d’audit, les pare-feu, et la mémoire des coéquipiers.

Étape 5 — Configurer le client avec ~/.ssh/config

Si vous taper ssh deploy@1.2.3.4 -i ~/.ssh/id_prod -p 22 -L 5432:localhost:5432 à chaque connexion, vous allez vous lasser. Le fichier ~/.ssh/config définit des alias paramétrés qui réduisent la commande à ssh prod.

nano ~/.ssh/config
chmod 600 ~/.ssh/config

# contenu :
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    HashKnownHosts no

Host prod
    HostName 1.2.3.4
    User deploy
    IdentityFile ~/.ssh/id_prod
    Port 22

Host bastion
    HostName bastion.exemple.com
    User malick
    IdentityFile ~/.ssh/id_ed25519

Host db-via-bastion
    HostName 10.0.0.5
    User dba
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Avec ce fichier, ssh prod suffit. ssh db-via-bastion rebondit automatiquement par le bastion grâce à ProxyJump, sans avoir à exposer la base sur Internet. Le bloc Host * en tête s’applique à toutes les connexions et envoie un keep-alive toutes les 60 secondes, ce qui évite les déconnexions par les pare-feu intermédiaires. La directive HashKnownHosts no garde les empreintes des serveurs en clair dans ~/.ssh/known_hosts, plus pratique à inspecter qu’une version hachée.

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

Si votre clé privée a une phrase de passe (et elle devrait), vous serez prompté à chaque connexion — frustrant si vous vous connectez plusieurs fois par heure. ssh-agent est un démon qui garde la clé déchiffrée en mémoire pour la session courante.

# Démarrer l'agent (sur la plupart des systèmes, lancé automatiquement par le bureau)
eval "$(ssh-agent -s)"

# Ajouter la clé
ssh-add ~/.ssh/id_ed25519
# Enter passphrase for /home/user/.ssh/id_ed25519: [tapez une fois]
# Identity added: /home/user/.ssh/id_ed25519

# Lister les clés chargées
ssh-add -l

# Vider l'agent (par exemple en quittant le bureau)
ssh-add -D

Sur macOS, le trousseau du système peut stocker la phrase entre redémarrages : ssh-add --apple-use-keychain ~/.ssh/id_ed25519. Sur Windows 11, le service OpenSSH Authentication Agent doit être démarré (sc config ssh-agent start=auto && sc start ssh-agent dans une PowerShell admin). Quand l’agent tourne, ssh prod n’affiche plus la moindre invite — c’est le confort qui débloque vraiment la productivité.

Étape 7 — Tunnels et port forwarding

Une fonction sous-utilisée et pourtant cruciale : SSH peut transporter des connexions arbitraires à travers la session chiffrée. Trois usages couvrent la plupart des besoins quotidiens.

# Local forward : exposer un port distant sur la machine locale
# Cas : se connecter à PostgreSQL distant (port 5432) sans l'exposer sur Internet
ssh -L 5432:localhost:5432 deploy@prod
# puis dans un autre terminal :
psql -h localhost -p 5432 -U app

# Remote forward : exposer un port local sur le serveur
# Cas : laisser un collègue tester un service en dev local via le serveur public
ssh -R 8080:localhost:3000 deploy@prod

# Dynamic forward : proxy SOCKS5 à travers SSH
# Cas : naviguer comme si vous étiez sur le serveur (debug pare-feu, géolocalisation)
ssh -D 1080 deploy@prod
# puis configurer le navigateur en SOCKS5 localhost:1080

Les tunnels sont chiffrés par SSH, donc utilisables sans peur sur un Wi-Fi public. Le tunnel local est l’outil quotidien du développeur qui doit interroger une base de production sans la rendre publique : la base écoute sur localhost:5432 du serveur, le client se connecte sur localhost:5432 de sa machine, et SSH fait le pont. Pour rendre un tunnel persistant, ajoutez LocalForward 5432 localhost:5432 dans le bloc Host prod du fichier ~/.ssh/config.

Étape 8 — Vérification et audit

Pour valider l’ensemble, lancez la batterie suivante depuis votre machine cliente. Elle teste la connexion, la version du serveur, l’algorithme négocié, et signale toute anomalie de configuration.

ssh -V                                              # version OpenSSH côté client
ssh -G prod | grep -i "identityfile\|user\|port"    # config résolue pour l'alias prod
ssh -o "BatchMode=yes" prod true && echo "OK clé"   # connexion non-interactive

# Côté serveur (en SSH ouvert) :
sudo sshd -T | grep -iE "permitroot|password|pubkey|maxauth"
sudo grep "Failed\|Accepted" /var/log/auth.log | tail -50
sudo lastlog | head -20

La sortie de sshd -T montre la configuration effective après application de tous les fichiers d’inclusion ; permitrootlogin no, passwordauthentication no, pubkeyauthentication yes doivent apparaître. Le grep sur auth.log donne la liste récente des connexions réussies et échouées — un nombre élevé de « Failed » provenant d’IP inconnues est normal sur un serveur public, mais un « Accepted » provenant d’une adresse inattendue mérite une enquête immédiate. Pour un audit plus poussé, l’outil ssh-audit (gratuit, open source) note la configuration de votre serveur de A à F selon les algorithmes proposés et les options posées.

Erreurs fréquentes

Tutoriels associés

• Permissions Linux : chmod, chown, sudo, ACL
• Réseau Linux : ip, ss, dig, curl, tcpdump

Dans la continuité

• 🔝 Retour au guide principal : Linux fondamentaux 2026
• OpenSSH — site officiel et notes de version openssh.org
• Pages de manuel : man ssh, man ssh_config, man sshd_config, man ssh-keygen.
• Mozilla OpenSSH Guidelines — infosec.mozilla.org/guidelines/openssh
• Outil ssh-audit — github.com/jtesta/ssh-audit

FAQ

Faut-il changer le port SSH par défaut pour la sécurité ?
Non. Changer le port de 22 vers 2222 ou 22000 n’arrête pas un attaquant sérieux — un scan complet de l’IPv4 prend désormais quelques heures avec masscan ou zgrab — et complique l’usage légitime (firewalls, proxys, monitoring, mémoire d’équipe). La défense efficace consiste à supprimer l’authentification par mot de passe, à ajouter fail2ban qui bannit les IP qui échouent trop souvent, et à filtrer le port 22 côté pare-feu si vous avez une plage source connue.

Comment partager un compte de service entre plusieurs développeurs sans partager de clé privée ?
Chaque développeur génère sa propre paire de clés et place sa clé publique dans ~/.ssh/authorized_keys du compte de service. La trace des connexions reste personnelle (chaque clé publique a un commentaire identifiant), et révoquer un accès se fait en supprimant la ligne correspondante. Pour les organisations plus grandes, les certificats SSH (signés par une CA) remplacent authorized_keys et permettent de gérer des centaines de développeurs sans copier de fichiers.

Que faire si je perds ma clé privée ?
Si vous avez encore une session ouverte sur le serveur, supprimez la ligne correspondante de ~/.ssh/authorized_keys et générez une nouvelle paire que vous redéployez. Si vous n’avez plus aucun accès, utilisez la console de secours de votre hébergeur (KVM/VNC chez OVH, console Hetzner, EC2 Instance Connect) pour entrer dans le serveur, puis remettez en place une nouvelle clé. Cet épisode justifie à lui seul de tester votre procédure de récupération avant que l’incident n’arrive.

OpenSSH 10.3 a-t-elle introduit des changements incompatibles ?
La version 10.3 d’avril 2026 retire la compatibilité avec les implémentations qui ne supportent pas la renégociation de clés en cours de session — un changement qui affecte uniquement quelques très vieux clients ou bibliothèques exotiques. Pour la quasi-totalité des usages, la mise à jour est transparente. Les notes de version officielles listent les correctifs de sécurité associés.

Comment connecter SSH avec une clé matérielle (YubiKey) ?
OpenSSH supporte les clés FIDO2/U2F depuis la version 8.2. La commande ssh-keygen -t ed25519-sk -C "email" génère une paire dont la partie privée vit dans la YubiKey et ne peut pas être copiée. À chaque connexion, la clé physique doit être présente et l’utilisateur tape un PIN ou touche un bouton selon la configuration. C’est la protection la plus solide en 2026 contre l’exfiltration de clés via malware.

Quelle est la différence entre ~/.ssh/known_hosts et ~/.ssh/authorized_keys ?
known_hosts contient les empreintes publiques des serveurs auxquels vous vous êtes connecté — c’est votre client qui s’en sert pour vérifier que le serveur n’a pas été remplacé. authorized_keys contient les clés publiques autorisées à se connecter à un compte donné — c’est le serveur qui s’en sert pour reconnaître ses utilisateurs légitimes. Ils sont en miroir et faciles à confondre, mais leur rôle est inverse.