8 choses que tu ignorais sur SSH

Tu ouvres une session SSH dix fois par jour. Une clé, une commande, un shell : ça marche, donc tu n'y penses plus. Le problème est là. Derrière cette routine, il y a des clés mal comprises, des portes laissées ouvertes et une confiance que tu accordes sans le savoir. Voilà huit choses qui se passent dans ton dos.

1. La première connexion, tu la fais à l'aveugle

Première connexion à un serveur. SSH t'affiche une empreinte et te pose une question : tu continues ? Tu tapes « yes », sans rien vérifier. L'empreinte file dans known_hosts, et SSH fera confiance à cette machine pour toujours. Voilà le paradoxe. Tout le protocole repose sur l'identité prouvée. Mais sur la connexion la plus risquée, la toute première, il te demande de ne rien contrôler. C'est le modèle TOFU, Trust On First Use. Un attaquant glissé entre toi et le serveur ce jour-là devient le serveur. Et tu ne le sauras jamais.

2. L'agent forwarding offre ta clé sans la donner

Tu sautes vers un serveur en passant par une machine de rebond. Pour ne pas retaper ta clé à chaque saut, tu actives l'agent forwarding avec l'option -A. Pratique, recommandé partout. Et c'est là le piège. Sur le rebond, SSH crée une socket reliée à ton agent, resté chez toi. Quiconque a les droits root sur ce rebond peut s'en servir. Il ne vole pas ta clé. Il s'en sert, en ton nom, pour ouvrir d'autres serveurs.

Agent forwarding should be enabled with caution.

— OpenSSH — man ssh_config (ForwardAgent)

La parade

Sur un rebond, tu n'as pas besoin de l'agent. ProxyJump fait le même travail sans exposer ta clé : ton client garde la main de bout en bout, et rien ne traîne sur la machine intermédiaire.

ssh -J rebond.exemple.com serveur.interne

3. SSH traverse ton pare-feu, dans le mauvais sens

SSH ne transporte pas que ton shell. Il transporte n'importe quel flux TCP. Tu peux pousser un port local vers le serveur, tirer un port distant vers toi, ou monter un proxy complet. C'est un VPN que tu as déjà sous la main.

ssh -L 8080:interne:80 serveur      # pousser un port local vers le distant
ssh -R 2222:localhost:22 externe    # la machine interne rouvre sa porte dehors
ssh -D 1080 serveur                 # proxy SOCKS : SSH devient un VPN

Le tunnel inverse

Une machine coincée derrière un pare-feu sort en SSH vers l'extérieur. Légitime : le pare-feu ne filtre que l'entrant. Mais ce tunnel rouvre une porte vers la machine interne. La connexion part de l'intérieur, donc personne ne la bloque. C'est exactement comme ça qu'une backdoor rappelle son opérateur.

4. OpenSSH a eu son premier RCE root en presque vingt ans

OpenSSH, c'est la référence : audité, durci, partout. Et pourtant. Juillet 2024, la faille regreSSHion. Exécution de code à distance, sans authentification, en root, dans la configuration par défaut. Le détail vertigineux ? C'était un bug déjà corrigé. En 2006. Une régression l'a fait revenir dix-huit ans plus tard, d'où le nom. La cause technique : une condition de course dans un gestionnaire de signal. L'exploitation reste difficile, plusieurs heures de tentatives. Mais la leçon est claire.

5. Ta clé « ssh-rsa » n'est pas une clé RSA morte

Un jour, ta connexion casse. Le message : algorithme de signature refusé. Le coupable affiché : ssh-rsa. Réflexe de panique : RSA est mort, je regénère tout en ed25519. Erreur. Ce n'est pas RSA qui est mort, c'est SHA-1. Depuis OpenSSH 8.8, en septembre 2021, la signature ssh-rsa, qui repose sur SHA-1, est désactivée par défaut. Ta clé RSA, elle, va très bien : depuis OpenSSH 7.2, elle signe déjà en SHA-256. Le problème n'apparaît que face à un serveur trop vieux.

# Le message qui déclenche la panique :
no mutual signature algorithm

# Parler à un vieux serveur, en dernier recours seulement :
Host vieux-serveur
    PubkeyAcceptedAlgorithms +ssh-rsa

6. Ton client SSH cache une interface secrète

Ta session SSH se fige, le serveur ne répond plus. Réflexe : tu fermes brutalement le terminal. Mauvaise idée. Ton client écoute un caractère d'échappement, le tilde, en début de ligne (après Entrée). C'est une petite console cachée, présente dans chaque session. Presque personne ne le sait. Pourtant, c'est dans le manuel, section ESCAPE CHARACTERS.

7. Une seule connexion peut servir dix sessions

Chaque connexion SSH coûte : échange de clés, authentification, négociation, à chaque fois. Sauf si tu actives le multiplexing. La première connexion reste ouverte en arrière-plan, les suivantes l'empruntent. Plus de poignée de main à répéter, une nouvelle session s'ouvre presque instantanément. C'est le covoiturage : une seule voiture fait le trajet, tous les passagers montent dedans. Ansible, l'outil d'automatisation, repose là-dessus pour aller vite.

# Dans ~/.ssh/config
Host *
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m

8. Les certificats SSH font disparaître le known_hosts hell

Reviens au premier fait : le problème de la première connexion, le fichier known_hosts qui gonfle, les authorized_keys éparpillés sur chaque serveur. Tout le monde vit là-dedans. Presque personne ne connaît la sortie. OpenSSH sait signer des certificats — pas seulement des clés, des certificats, comme une carte d'identité. Une autorité de certification, ta CA, signe les clés des serveurs et celles des utilisateurs. Tu fais confiance à la CA une seule fois. Plus de TOFU, plus de known_hosts à maintenir, et un certificat peut même expirer tout seul.

Durcir ton SSH en 6 réflexes

Si tu ne retiens qu'une chose de cette page, retiens cette liste.

• Vérifie l'empreinte d'un serveur au premier contact, par un canal de confiance.
• Sur un rebond, utilise ProxyJump (ssh -J), jamais l'agent forwarding.
• Désactive l'agent forwarding et tout forwarding inutile sur tes bastions.
• Préfère une clé ed25519, et ne garde RSA que si tu sais pourquoi.
• Tiens OpenSSH à jour : regreSSHion a frappé la configuration par défaut.
• Pour une flotte, passe aux certificats SSH plutôt que de distribuer des clés à la main.