SSH est un VPN, un proxy et une PKI — vous l’utilisez probablement à 10 % de ses capacités

OpenSSH 10.4 est sorti le 6 juillet 2026, SSH fête ses 30 ans l’année précédente si l’on remonte à la première implémentation de Tatu Ylönen en 1995, et la plupart des administrateurs l’utilisent encore comme un simple ssh user@host. Cette sous-utilisation est un gâchis : SSH n’est pas juste un terminal distant — c’est un VPN, un proxy SOCKS, un système de certificats, un multiplexeur de connexions et un tunnel de fichiers. OpenSSH embarque ces fonctionnalités depuis plus d’une décennie, sans dépendance externe, sans démon supplémentaire, sans surcoût réseau.

Cet article couvre les sept fonctionnalités avancées qui transforment SSH en couteau suisse réseau, avec les configurations testées sur OpenSSH 10.x.

Le multiplexing — une connexion TCP, tous vos shells

Le problème est connu de tous les administrateurs : chaque ssh ouvre une nouvelle connexion TCP, refait l’échange de clés Diffie-Hellman, réauthentifie l’utilisateur. Sur un serveur distant avec 150 ms de latence, une session interactive coûte 2 à 3 secondes. Un scp, un git push via SSH, un rsync : chaque commande paie ce prix.

Le multiplexing SSH résout ce problème radicalement. Une première connexion — la master connection — ouvre le tunnel TCP et s’authentifie une fois. Toutes les connexions suivantes vers le même hôte empruntent ce tunnel via un socket UNIX local, sans nouvelle négociation TCP, sans nouvelle authentification. Le gain de latence est immédiat : 5 à 10 secondes économisées par session sur une connexion à 150 ms.

La configuration tient dans ~/.ssh/config :

Host *
    ControlMaster auto
    ControlPath ~/.ssh/controlmasters/%r@%h:%p
    ControlPersist 10m

Trois directives, trois jobs. ControlMaster auto active le multiplexage automatiquement : si un socket existe déjà pour la cible, le client s’y rattache ; sinon, il crée la master connection. ControlPath définit l’emplacement du socket UNIX — %r pour l’utilisateur distant, %h pour l’hôte, %p pour le port. ControlPersist 10m maintient la master connection ouverte 10 minutes après la fermeture du dernier shell ; sans cette directive, la master tombe dès que le premier shell se déconnecte, rendant le multiplexage inutile pour les commandes consécutives.

Piège n°1 : le répertoire ~/.ssh/controlmasters/ doit exister. Un mkdir -p ~/.ssh/controlmasters && chmod 700 ~/.ssh/controlmasters avant la première connexion.

Piège n°2 : ControlPersist est ignoré en l’absence de ControlMaster auto. Les trois directives vont ensemble.

Vérifiez que le multiplexage fonctionne :

# Ouvrez une première session
ssh user@host

# Dans un autre terminal local, listez les sockets actifs
ls -la ~/.ssh/controlmasters/

# La deuxième connexion utilise le même tunnel — visible dans les logs
ssh -v user@host 2>&1 | grep "auto-mux"
# Doit afficher : "auto-mux: Trying existing master"

La master connection consomme un socket et une poignée de mémoire sur le serveur — négligeable. En contrepartie, une seule déconnexion réseau tue toutes les sessions multiplexées : c’est le prix du partage de tunnel. Le paramètre ControlPersist ne protège pas contre ce risque ; il maintient la master après la fermeture volontaire des shells, pas pendant une coupure réseau.

ProxyJump et bastions — traverser les couches réseau sans VPN

Le scénario est classique : un serveur de production n’est pas directement accessible depuis Internet. Il est derrière un bastion — une machine exposée qui sert de point d’entrée unique vers le réseau interne. La méthode naïve consiste à SSH dans le bastion, puis SSH depuis le bastion vers la cible. Deux authentifications, deux sessions, un scp impossible sans rsync en deux temps.

ProxyJump (introduit dans OpenSSH 7.3, août 2016) règle le problème en une directive :

Host prod-*
    ProxyJump bastion.example.com
    User app

# Une seule commande, une seule saisie de passphrase
ssh prod-db1
# SSH transite automatiquement par le bastion

Sous le capot, ProxyJump établit une connexion SSH vers le bastion, puis demande au démon SSH du bastion de relayer le flux TCP vers la cible (-W host:port). L’authentification reste de bout en bout : vos clés ne quittent jamais votre poste et ne sont jamais exposées sur le bastion. Utilisez ssh-agent ou un FIDO2 key pour ne taper votre passphrase qu’une seule fois.

ProxyJump en cascade. Rien n’empêche d’empiler les bastions :

Host prod-db-deep
    ProxyJump bastion-public,bastion-interne

Le client SSH saute de votre poste vers bastion-public, puis vers bastion-interne, puis vers la cible. La commande ssh prod-db-deep traverse trois couches réseau en une seule frappe.

Agent forwarding : attention. Le réflexe historique est d’utiliser ForwardAgent yes sur le bastion pour que les clés locales soient accessibles depuis le saut suivant. Ne le faites pas. Un bastion compromis peut utiliser votre agent pour rebondir sur toutes les machines où votre clé est autorisée. La faille est documentée depuis 2016 et le risque est réel : si un attaquant obtient les droits root sur le bastion, il peut intercepter le socket SSH_AUTH_SOCK et signer des connexions à votre place. ProxyJump élimine ce risque en gardant l’authentification sur votre poste local.

Si vous devez absolument utiliser ForwardAgent, activez-le uniquement sur l’hôte cible, jamais sur le bastion :

Host prod-*
    ProxyJump bastion.example.com
    ForwardAgent yes   # sur la cible finale uniquement

Et préférez ssh-add -c (confirmation par touche) pour valider chaque utilisation de la clé.

Les certificats SSH — votre propre PKI sans X.509

C’est la fonctionnalité la plus sous-utilisée d’OpenSSH, et la plus puissante. Depuis OpenSSH 5.4 (mars 2010), SSH supporte un format de certificat natif — à ne pas confondre avec les certificats X.509. Le principe : vous créez une clé d’autorité de certification (CA), vous signez les clés publiques de vos utilisateurs et de vos serveurs avec cette CA, et vous configurez vos serveurs pour faire confiance à la CA plutôt qu’à des clés individuelles.

La conséquence est une rupture architecturale. Fini le fichier authorized_keys de 300 lignes synchronisé à la main sur 50 serveurs. Fini les clés orphelines d’un administrateur parti depuis six mois. La rotation des clés devient une opération centralisée : vous révoquez le certificat, pas la clé.

Mise en place pas à pas

1. Créer la CA (une seule fois, sur une machine sécurisée hors ligne idéalement) :

ssh-keygen -t ed25519 -f /etc/ssh/ca_user -C "User CA - Ettayeb Infra"
ssh-keygen -t ed25519 -f /etc/ssh/ca_host -C "Host CA - Ettayeb Infra"

Deux CA séparées : une pour les clés utilisateur, une pour les clés d’hôte. Cette séparation est critique — une CA utilisateur compromise ne doit pas permettre d’usurper un serveur, et inversement.

2. Configurer les serveurs pour faire confiance à ces CA :

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_user.pub
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

3. Signer la clé d’un utilisateur :

# Signe la clé pour 12 heures, avec le nom d'utilisateur forcé
ssh-keygen -s /etc/ssh/ca_user \
    -I "walid-ettayeb" \
    -n "root,app" \
    -V +12h \
    ~/.ssh/id_ed25519.pub

Le -I est un identifiant libre (pour l’audit). Le -n force le principal — l’utilisateur Unix sous lequel la connexion est autorisée. -V +12h définit la durée de validité : un certificat SSH a une date d’expiration, contrairement à une clé nue.

Le résultat est un fichier id_ed25519-cert.pub aux côtés de votre clé publique. SSH l’utilise automatiquement si le serveur fait confiance à la CA qui l’a signé.

4. Voir les détails d’un certificat :

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub
# Affiche : type, CA, principaux, validité, ID, extensions

Ce que les certificats SSH apportent de plus que les clés nues

• Expiration. Une clé signée pour 12 heures limite la fenêtre de compromission. Si votre laptop est volé, le certificat expire avant que vous ayez fini de remplir la déclaration de vol.
• Révocation. Ajoutez le numéro de série dans un fichier RevokedKeys sur le serveur, et le certificat est immédiatement inutilisable — partout, en une seule opération.
• Principaux forcés. Le -n root dans la signature verrouille l’utilisateur Unix. Même si un attaquant vole le certificat, il ne peut pas se connecter en tant qu’un autre utilisateur.
• Audit. L’identifiant -I est logué côté serveur dans /var/log/auth.log, ce qui permet de tracer qui s’est connecté, pas seulement quelle clé.
• Extensions. Vous pouvez embarquer des contraintes dans le certificat : permit-port-forwarding, permit-pty, force-command. Un certificat peut devenir un « jeton d’accès limité » à un sous-ensemble de fonctionnalités SSH.

Le coût. Une infrastructure à base de certificats SSH demande un outil de signature — un script Python de 50 lignes ou un service comme Smallstep SSH, HashiCorp Vault ou Teleport. Le standard est ouvert et documenté dans le fichier PROTOCOL.certkeys du dépôt OpenSSH.

Le forwarding de ports — SSH comme VPN et proxy SOCKS

Le forwarding de ports est la fonctionnalité qui transforme SSH en tunnel réseau universel. Trois modes existent, et connaître la différence entre eux change la façon dont vous concevez l’accès à vos services internes.

Forwarding local (-L) : amener un port distant sur votre machine

ssh -L 8080:internal-db:5432 user@bastion

Cette commande écoute sur localhost:8080 et relaie tout le trafic vers internal-db:5432, du point de vue du bastion. Depuis votre poste, psql -h localhost -p 8080 atteint la base de données interne sans que celle-ci soit exposée sur Internet. Le bastion fait office de relais TCP — pas de proxy HTTP, pas de translation d’adresse, juste une redirection de flux.

Le forwarding local est le mode le plus sûr : le port n’est pas exposé sur le réseau, uniquement sur localhost. Pour une écoute sur toutes les interfaces, utilisez -L 0.0.0.0:8080:... ou configurez GatewayPorts yes côté serveur.

Forwarding distant (-R) : exposer un port local sur le serveur distant

ssh -R 9000:localhost:3000 user@bastion

Cette commande ouvre le port 9000 sur le bastion et relaie le trafic vers localhost:3000 sur votre poste. Utile pour exposer temporairement un service de développement à un collègue, ou pour donner à un webhook externe un accès à votre environnement local.

Le forwarding distant est désactivé par défaut sur la plupart des serveurs (AllowTcpForwarding yes ne suffit pas pour -R) : la directive GatewayPorts clientspecified ou yes doit être présente dans sshd_config pour autoriser l’écoute sur autre chose que localhost.

Forwarding dynamique (-D) : un proxy SOCKS à travers SSH

ssh -D 1080 user@bastion

Cette commande transforme votre machine en proxy SOCKS5 sur localhost:1080. Tout le trafic qui passe par ce proxy est routé à travers le bastion — résolution DNS incluse si vous ajoutez -D 1080 avec un navigateur configuré en « proxy SOCKS v5 ».

# Navigateur : configurer le proxy SOCKS sur localhost:1080
# Ou ligne de commande :
curl --socks5-hostname localhost:1080 https://ifconfig.me
# Renvoie l'IP du bastion, pas la vôtre

Le -D est un VPN applicatif sans privilège root. Pas d’interface tun, pas de table de routage, pas de configuration réseau. Un processus utilisateur, un socket local, et tout votre trafic applicatif sort par le bastion. La combinaison ssh -D 1080 -N -f user@bastion ouvre le tunnel en arrière-plan (-f), sans shell (-N), prêt à servir indéfiniment.

Limite : le SOCKS via SSH est en TCP uniquement. Pas d’UDP, pas de DNS natif (sauf avec --socks5-hostname côté client qui délègue la résolution au proxy). Pour un vrai VPN complet, combinez SSH avec sshuttle — un outil qui crée un tunnel VPN transparent en utilisant SSH comme transport, sans serveur VPN dédié.

SSHFS — monter un système de fichiers distant avec les droits de votre clé

SSHFS (basé sur FUSE et le protocole SFTP) fait pour les systèmes de fichiers ce que ssh -L fait pour les ports TCP : il expose un répertoire distant comme un montage local, sans NFS, sans Samba, sans configuration serveur.

# Installation (une fois)
apt install sshfs

# Montage
sshfs user@host:/var/log /mnt/host-logs

# Utilisation — le répertoire distant se comporte comme un répertoire local
ls /mnt/host-logs
grep ERROR /mnt/host-logs/syslog

# Démontage
fusermount -u /mnt/host-logs

Aucune configuration côté serveur n’est nécessaire au-delà du sous-système SFTP (activé par défaut). Les permissions sont celles de l’utilisateur SSH : vous voyez ce que votre clé vous autorise à voir.

Les options utiles :

sshfs -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 \
      -o cache=yes,cache_timeout=60 \
      user@host:/data /mnt/data

• reconnect : rétablit automatiquement la connexion après une coupure réseau.
• ServerAliveInterval=15 : envoie un keepalive toutes les 15 secondes pour éviter le timeout.
• cache=yes,cache_timeout=60 : met en cache les attributs des fichiers pendant 60 secondes — accélère massivement les ls et les find.

SSHFS n’est pas un NAS. Les performances sont limitées par le débit SSH et la latence réseau : sur une liaison à 50 ms, le débit plafonne autour de 30 à 50 Mo/s avec un CPU moderne. Pour un usage de consultation de logs, d’édition de configuration ou de transfert ponctuel, c’est amplement suffisant. Pour du montage permanent ou du gros transfert, préférez NFS ou un système de fichiers distribué.

MOSH — le shell qui survit au changement de réseau

MOSH (Mobile Shell), sorti en avril 2012 par une équipe du MIT, résout un problème que SSH ne traite pas : la mobilité réseau. Si vous fermez votre laptop, changez de Wi-Fi ou passez de l’Ethernet à la 4G, SSH coupe la connexion — le socket TCP est rompu, le shell est mort, votre session tmux aussi (sauf si vous vous y êtes reconnecté).

MOSH remplace le transport TCP de SSH par un protocole UDP appelé SSP (State Synchronization Protocol). Le principe : le terminal distant est synchronisé en temps réel avec le client, et chaque frappe est affichée localement de façon prédictive avant même que le serveur n’ait répondu. Le soulignement indique les prédictions non confirmées — une idée empruntée aux éditeurs collaboratifs.

Ce que MOSH fait mieux que SSH :

• Roaming IP. Changez de réseau, votre session MOSH survit. L’UDP n’a pas de connexion — le serveur continue d’envoyer des paquets vers la dernière IP source reçue.
• Écho local prédictif. Sur une liaison à 300 ms, SSH affiche chaque caractère avec 300 ms de délai. MOSH affiche vos frappes instantanément, rattrape les corrections prédictives quand la réponse arrive, et souligne ce qui n’est pas encore confirmé.
• Pas de buffer bloqué. Ctrl+C interrompt toujours le processus distant immédiatement, même si le buffer réseau est saturé — le protocole SSP fixe un débit adaptatif basé sur les conditions réseau.

Ce que MOSH ne fait pas :

• Pas de forwarding de ports (-L, -R, -D).
• Pas de scp ni de SFTP — MOSH est un shell interactif, pas un tunnel.
• Pas de ssh-agent forwarding natif.
• Pas de multiplexing : chaque session MOSH est indépendante.

Fonctionnement : le client MOSH se connecte d’abord en SSH au serveur (authentification classique), lance le processus mosh-server qui écoute sur un port UDP aléatoire, puis le client MOSH se connecte à ce port UDP. La connexion SSH initiale peut tomber immédiatement après — MOSH fonctionne ensuite entièrement en UDP, avec son propre chiffrement AES-128-OCB.

# Installation (client + serveur)
apt install mosh

# Connexion — identique à SSH
mosh user@host

# Avec un port SSH non standard
mosh --ssh="ssh -p 2222" user@host

MOSH ne remplace pas SSH — il le complète. Gardez SSH pour les tunnels, les transferts de fichiers et l’automatisation. Utilisez MOSH pour les sessions interactives longues, surtout sur des liaisons mobiles ou à haute latence. La version 1.4.0 (octobre 2022, dernière stable) a ajouté le support true color, qui manquait cruellement pour les thèmes de terminal modernes.

Durcir sshd_config — le minimum que chaque serveur devrait avoir

L’essentiel du durcissement SSH tient dans cinq directives qui ferment les portes laissées ouvertes par défaut. Voici ce qu’un sshd_config minimal devrait contenir, au-delà des clés d’hôte :

# /etc/ssh/sshd_config — extrait durci

# 1. Désactiver la connexion root — toujours
PermitRootLogin no

# 2. Authentification par clé uniquement — plus de mot de passe
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes   # garder PAM pour les modules de session, mais sans auth par mot de passe

# 3. Restreindre les algorithmes faibles
KexAlgorithms curve25519-sha256,[email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]
HostKeyAlgorithms ssh-ed25519,[email protected]

# 4. Limiter l'exposition réseau
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# 5. Verrouiller le forwarding inutile
AllowTcpForwarding no          # ou yes si vous en avez besoin
X11Forwarding no
AllowAgentForwarding no        # critique si vous utilisez ProxyJump
PermitTunnel no                # sauf si vous faites du VPN SSH (tun)

Les justifications, directive par directive :

• PermitRootLogin no est la première chose qu’un scanner SSH teste. Depuis OpenSSH 8.4 (septembre 2020), la valeur par défaut est prohibit-password — la connexion root n’est possible que par clé. Passez à no : aucun scénario de production ne devrait nécessiter un accès root direct.
• PasswordAuthentication no élimine le brute-force de mot de passe. Si vous devez garder l’authentification par mot de passe pour certains utilisateurs (héritage), isolez-les dans un bloc Match et activez le rate-limiting avec PerSourcePenalties (OpenSSH 9.8+, juin 2024) qui pénalise les adresses IP après des échecs répétés.
• Les algorithmes listés ci-dessus excluent les courbes NIST P-256/P-384 (potentiellement affaiblies), le CBC (vulnérable au padding oracle), SHA-1 (cassé) et le MAC umac-64 (trop court). Le guide complet est le fichier moduli livré avec OpenSSH — gardez uniquement les groupes ≥ 3072 bits.
• ClientAliveInterval 300 + ClientAliveCountMax 2 déconnectent les sessions fantômes après 10 minutes d’inactivité réseau. Sans ces directives, un client qui perd sa connexion sans envoyer de TCP RST bloque un slot de session indéfiniment.
• AllowTcpForwarding no si vous n’utilisez pas -L/-R/-D. Un attaquant qui obtient un shell limité peut utiliser le forwarding de ports pour rebondir sur le réseau interne. Si vous en avez besoin, restreignez-le avec PermitOpen.

Aller plus loin — Match blocks conditionnels :

# Restreindre le forwarding à un groupe d'administrateurs réseau
Match Group netadmins
    AllowTcpForwarding yes
    PermitOpen 10.0.0.0/8:* 172.16.0.0/12:*

# Authentification par mot de passe pour les stagiaires, rate-limiting actif
Match Group interns
    PasswordAuthentication yes

Après toute modification, validez sans redémarrer :

sshd -t && systemctl reload sshd

sshd -t teste la syntaxe — si elle est incorrecte, le daemon ne redémarre pas et vous conservez votre session ouverte. Ne faites jamais systemctl restart sshd directement : une erreur de syntaxe vous coupe de la machine.

Le verdict

SSH est le seul outil réseau que vous avez déjà installé sur 100% de vos serveurs, et il fait plus que ce que 90% des administrateurs lui demandent. Le passage à la vitesse supérieure ne demande aucun nouveau logiciel — seulement de la configuration.

• Vous gérez plus de trois serveurs et vous tapez ssh user@host cinq fois par jour : activez le multiplexing. Trois lignes dans ~/.ssh/config, et chaque session après la première s’ouvre en moins de 100 ms. C’est le gain de productivité le plus immédiat.
• Vous avez un bastion et vous faites ssh bastion puis ssh serveur : passez à ProxyJump. Une commande, une authentification, et votre ssh-agent ne quitte jamais votre poste.
• Vous avez 10 administrateurs et 50 serveurs, et vos authorized_keys sont ingérables : déployez les certificats SSH. Une CA ed25519, un script de signature de 50 lignes, et la rotation des clés devient une opération de routine au lieu d’un cauchemar de synchronisation.
• Vous exposez un service interne à un collaborateur via une règle de firewall temporaire : utilisez ssh -R. Une commande, pas de modification de pare-feu, pas de règle à nettoyer.
• Vous travaillez dans le train ou depuis un café avec un Wi-Fi instable : installez MOSH. Votre shell survit au changement de réseau, et vos frappes s’affichent instantanément même avec 300 ms de latence.
• Vous voulez explorer les logs d’un serveur sans télécharger de fichier : montez le répertoire avec SSHFS. grep, less, tail -f comme en local — sans scp, sans rsync, sans session interactive.
• Vous gérez des serveurs exposés sur Internet : appliquez les cinq directives de durcissement. PermitRootLogin no et PasswordAuthentication no à eux seuls bloquent 99% des attaques automatisées.

La puissance de SSH vient de ce qu’il fait une chose et qu’il la fait bien depuis 30 ans — mais cette chose est bien plus large que « terminal distant ». Maîtrisez ces sept fonctionnalités, et vous aurez supprimé trois outils de votre stack et deux abonnements SaaS de votre budget.

Références

• OpenSSH 10.4 Release Notes, OpenSSH, 6 juillet 2026.
• OpenSSH Cookbook — Multiplexing, Wikibooks, consulté juin 2026.
• PROTOCOL.certkeys — OpenSSH Certificate Protocol, OpenBSD CVS, version initiale mars 2010.
• SSH Certificates — Smallstep Blog, Carl Tashian, Smallstep, mars 2020.
• ProxyJump in OpenSSH 7.3, OpenSSH Release Notes, août 2016.
• ssh(1) Manual — OpenBSD, section Forwarding, OpenBSD, 2026.
• sshd_config(5) Manual — OpenBSD, OpenBSD, 2026.
• Mosh: the mobile shell, MIT, version 1.4.0, octobre 2022.
• Mosh research paper, Winstein & Balakrishnan, USENIX ATC, 2012.
• SSHFS — GitHub, libfuse, 2026.
• Hardening OpenSSH — ANSSI Guide, ANSSI, mise à jour 2024.
• Applied Crypto Hardening — BetterCrypto.org, chapitre SSH, 2023.