Chapitre 4.3 — Config client & alias

⏱️ TL;DR — Retaper ssh deploy@203.0.113.10 -p 2222 -i ~/.ssh/id_ed25519 dix fois par jour, c’est pénible et source d’erreurs. Le fichier ~/.ssh/config (sur ton poste) te laisse définir des alias : un bloc Host formacampus avec HostName, User, Port, IdentityFile, et tu tapes juste ssh formacampus. Au-delà du confort, c’est de la sécurité : la bonne clé est associée au bon serveur, automatiquement. On y ajoute des options utiles (ServerAliveInterval pour ne pas se faire déconnecter, IdentitiesOnly pour ne présenter que la clé voulue), le rebond par un bastion (ProxyJump) pour atteindre des machines cachées, et un survol du multiplexing (ControlMaster) qui accélère les connexions répétées.

🎯 Objectifs

• Écrire un bloc Host dans ~/.ssh/config pour te connecter en tapant juste un alias.
• Connaître les directives essentielles : HostName, User, Port, IdentityFile.
• Ajouter les options de confort et de sécurité utiles (ServerAliveInterval, IdentitiesOnly).
• Rebondir via un bastion avec ProxyJump pour atteindre une machine non exposée.
• Savoir ce qu’apporte le multiplexing (ControlMaster) et quand l’activer.

Le problème : des commandes longues et fragiles

Sans config, chaque connexion à un serveur un peu particulier ressemble à ça :

ssh deploy@203.0.113.10 -p 2222 -i ~/.ssh/id_ed25519_formacampus
# utilisateur deploy, IP par coeur, port non standard, chemin exact de la bonne cle

Multiplie par plusieurs serveurs (prod, staging, bastion, la base…) et tu obtiens un cocktail d’IP à retenir, de ports à ne pas confondre et de clés à ne pas mélanger. Une erreur de cible, et tu tapes une commande sur la mauvaise machine. Le fichier ~/.ssh/config transforme tout ça en noms clairs.

Le fichier ~/.ssh/config

Il vit sur ton poste, dans ~/.ssh/config. Tu le crées s’il n’existe pas. Sa syntaxe : des blocs qui commencent par Host <alias>, suivis de directives indentées.

Host formacampus
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_formacampus

Décryptage de chaque directive :

• Host formacampus — l’alias que tu tapes. ssh formacampus déclenche ce bloc.
• HostName 203.0.113.10 — l’adresse réelle (IP ou nom de domaine) où se connecter.
• User deploy — l’utilisateur distant. Plus besoin de préfixer deploy@.
• Port 2222 — le port SSH. Plus besoin de -p 2222.
• IdentityFile ~/.ssh/id_ed25519_formacampus — la clé privée à présenter pour ce serveur.

Désormais :

ssh formacampus
# equivaut a : ssh deploy@203.0.113.10 -p 2222 -i ~/.ssh/id_ed25519_formacampus

💡 Réflexe — Dès qu’un serveur a le moindre réglage particulier (port non standard, clé dédiée, utilisateur différent), crée-lui un bloc dans ~/.ssh/config tout de suite. Tu ne le regretteras jamais : tu tapes un nom au lieu d’une ligne, et scp, rsync, git bénéficient du même alias (ils lisent tous ce fichier).

🔒 Sécurité — Associer une clé par serveur via IdentityFile n’est pas que du rangement : ça cloisonne. Si une clé fuit, elle n’ouvre qu’un serveur, pas tout ton parc. Et comme l’alias fixe la bonne clé pour la bonne machine, tu évites de présenter par erreur une clé sensible à un hôte qui n’a rien à voir.

Plusieurs hôtes, et des motifs

Tu peux empiler autant de blocs que de serveurs, et même utiliser des motifs (*) pour appliquer des réglages communs :

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_formacampus

Host staging
    HostName 203.0.113.99
    User deploy
    IdentityFile ~/.ssh/id_ed25519_formacampus

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    IdentitiesOnly yes

Le bloc Host * s’applique à tous les hôtes (il complète les réglages spécifiques). Les options les plus utiles à y mettre :

• ServerAliveInterval 60 — envoie un petit signe de vie toutes les 60 s. Sans ça, une connexion inactive (tu réfléchis, tu vas boire un café) se fait couper par un routeur ou un pare-feu, et tu perds ta session avec un broken pipe.
• ServerAliveCountMax 3 — après 3 signes de vie sans réponse, ssh conclut que le lien est mort et raccroche proprement (au lieu de rester figé).
• IdentitiesOnly yes — n’essaie que la clé indiquée par IdentityFile, pas toutes celles chargées dans l’agent. Utile si tu as beaucoup de clés : ça évite de les présenter une par une au serveur et de te faire jeter pour trop de tentatives (les serveurs limitent les essais — voir 4.4).

⚠️ Piège — Avoir plein de clés chargées dans l’agent sans IdentitiesOnly yes. À la connexion, ssh les propose toutes, une par une. Un serveur avec MaxAuthTries bas te coupe avant d’arriver à la bonne, avec un cryptique « Too many authentication failures ». Le réflexe : IdentitiesOnly yes + IdentityFile explicite dans le bloc de l’hôte concerné.

Rebondir par un bastion : ProxyJump

En entreprise (et souvent en prod sérieuse), les serveurs applicatifs ne sont pas joignables directement depuis Internet. On passe par un bastion (aussi appelé jump host) : une machine unique, durcie et exposée, par laquelle transitent toutes les connexions vers le réseau interne.

Host bastion
    HostName bastion.formacampus.fr
    User jump
    IdentityFile ~/.ssh/id_ed25519_formacampus

Host db-interne
    HostName 10.0.0.5
    User deploy
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_formacampus

Ici, db-interne a une IP privée (10.0.0.5) injoignable depuis chez toi. La directive ProxyJump bastion dit à ssh : « connecte-toi d’abord au bastion, puis rebondis de là vers 10.0.0.5 ». Une seule commande fait les deux sauts :

ssh db-interne
# 1) ssh se connecte a bastion.formacampus.fr
# 2) depuis le bastion, il atteint 10.0.0.5 (le reseau interne)
# le tout dans un seul tunnel chiffre de bout en bout

🔒 Sécurité — Un bastion réduit la surface d’attaque à une seule machine exposée, ultra-durcie et loguée, au lieu d’exposer chaque serveur. ProxyJump fait le rebond côté client proprement : ta connexion vers la machine interne reste chiffrée de bout en bout (le bastion relaie, il ne déchiffre pas ta session). C’est le bon pattern quand on sépare un réseau public d’un réseau privé.

Multiplexing : réutiliser une connexion (ControlMaster)

Quand tu enchaînes beaucoup de connexions vers le même serveur (déploiements, scripts, git répétés), établir un nouveau tunnel à chaque fois coûte du temps. Le multiplexing garde une connexion maîtresse ouverte et fait passer les suivantes dedans, instantanément.

Host prod
    HostName 203.0.113.10
    User deploy
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 5m

• ControlMaster auto — réutilise une connexion existante s’il y en a une, sinon en crée une.
• ControlPath ~/.ssh/cm-%r@%h:%p — le socket local qui matérialise la connexion partagée (%r = user, %h = hôte, %p = port).
• ControlPersist 5m — garde la connexion maîtresse 5 minutes après la dernière session, prête à être réutilisée.

C’est un confort avancé, surtout utile pour l’outillage et la CI. Retiens le principe (une connexion réutilisée = des commandes suivantes quasi instantanées) ; les réglages fins sont dans le manuel.

📚 La doc — ~/.ssh/config a des dizaines de directives (redirections, environnement, algorithmes…). La référence exhaustive et à jour est man ssh_config (avec un underscore), à ne pas confondre avec man sshd_config qui est la config du serveur (chapitre suivant). N’invente pas d’option : cherche-la là.

Un exemple complet

Voici à quoi peut ressembler un ~/.ssh/config réaliste, réglages communs inclus :

# Reglages appliques a TOUS les hotes
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    IdentitiesOnly yes
    AddKeysToAgent yes

# Le bastion, seule machine exposee
Host bastion
    HostName bastion.formacampus.fr
    User jump
    IdentityFile ~/.ssh/id_ed25519_formacampus

# La prod, port non standard, via le bastion
Host prod
    HostName 10.0.0.10
    User deploy
    Port 2222
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_formacampus

# Le staging, joignable directement
Host staging
    HostName 203.0.113.99
    User deploy
    IdentityFile ~/.ssh/id_ed25519_formacampus

Avec ça, ssh prod, ssh staging, ssh bastion suffisent. La directive AddKeysToAgent yes charge en plus ta clé dans l’agent au premier usage, pour ne plus taper la passphrase ensuite.

🧭 Sur FormaCampus — Chaque dev de FormaCampus a le même ~/.ssh/config : un alias prod (le VPS Ubuntu, port SSH déplacé), un alias staging, et — le jour où l’infra grossit — un bastion en ProxyJump. Tout le monde tape ssh prod et atterrit sur deploy@ avec la bonne clé, sans mémoriser d’IP ni de port. Bonus : les scripts de déploiement et rsync de l’équipe réutilisent ces alias, donc changer l’IP du serveur = éditer une seule ligne (HostName) au lieu de traquer l’IP partout.

✏️ Exercices

Exercice 1 — Écris le bloc. Tu te connectes souvent avec ssh deploy@198.51.100.7 -p 22022 -i ~/.ssh/id_ed25519_fc. Écris le bloc ~/.ssh/config qui te permet de taper juste ssh fc.

Host fc
    HostName 198.51.100.7
    User deploy
    Port 22022
    IdentityFile ~/.ssh/id_ed25519_fc

Exercice 2 — Trop de tentatives. Un collègue se connecte à un serveur et reçoit « Too many authentication failures » alors que sa clé est bien autorisée. Il a cinq clés chargées dans son agent. Quelle option de ~/.ssh/config règle le problème, et pourquoi ?

Exercice 3 — Atteindre une machine cachée. La base de données a l’IP privée 10.0.0.5, injoignable depuis Internet, mais accessible depuis le bastion bastion.exemple.fr. Écris les deux blocs ~/.ssh/config pour taper ssh db et rebondir automatiquement.

Host bastion
    HostName bastion.exemple.fr
    User jump
    IdentityFile ~/.ssh/id_ed25519

Host db
    HostName 10.0.0.5
    User deploy
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

🧠 Quiz de révision

Chapitre suivant : Durcir le serveur SSH — le chapitre sécurité central : fermer root, couper le mot de passe, n’autoriser que deploy, sans jamais te verrouiller dehors.