Chapitre 4.2 — Les clés SSH

⏱️ TL;DR — Une clé SSH, c’est une paire : une clé privée qui reste chez toi (jamais partagée, jamais copiée nulle part), et une clé publique que tu distribues sans crainte sur chaque serveur. Tu la génères en une commande : ssh-keygen -t ed25519 -C "commentaire". Elle atterrit dans ~/.ssh/id_ed25519 (privée) et ~/.ssh/id_ed25519.pub (publique). Tu déposes la publique sur le serveur avec ssh-copy-id user@host — ou à la main dans ~/.ssh/authorized_keys (attention aux permissions, piège classique). Une passphrase chiffre ta clé privée au repos ; l’agent SSH (ssh-agent + ssh-add) évite de la retaper à chaque fois. Règle d’or, non négociable : on ne partage JAMAIS la clé privée.

🎯 Objectifs

• Comprendre la cryptographie asymétrique en deux phrases (clé privée / clé publique).
• Générer une paire de clés ed25519 avec ssh-keygen, et savoir où elle vit.
• Déposer ta clé publique sur un serveur (ssh-copy-id ou méthode manuelle) et régler les permissions.
• Protéger ta clé privée par une passphrase et l’utiliser sans friction grâce à l’agent SSH.
• Savoir ce qu’est une clé de déploiement (deploy key) pour la CI.

La crypto asymétrique en deux phrases

Tout repose sur une idée simple. Tu possèdes deux clés mathématiquement liées : ce que l’une verrouille, seule l’autre peut le déverrouiller. La clé privée reste secrète et chez toi ; la clé publique peut être donnée à tout le monde sans aucun risque — la connaître ne permet pas de retrouver la privée.

Pour SSH, ça donne : tu déposes ta clé publique sur le serveur ; à la connexion, le serveur te met au défi de prouver que tu détiens la clé privée correspondante, ce que tu fais sans jamais la révéler. Pas de secret transmis, pas de bruteforce possible (revoir le 4.1).

💡 Réflexe — Retiens l’asymétrie par l’image du cadenas : la clé publique est un cadenas ouvert que tu sèmes partout ; la clé privée est l’unique clé qui l’ouvre, et elle ne quitte jamais ta poche. On distribue les cadenas, jamais la clé.

Générer ta paire de clés

Une seule commande, sur ton poste (pas sur le serveur) :

ssh-keygen -t ed25519 -C "alex@formacampus"
# ssh-keygen -> l'outil de generation de cles SSH
# -t ed25519 -> le TYPE de cle : ed25519, moderne, court et solide
# -C "..."   -> un COMMENTAIRE libre, pour identifier la cle (souvent email ou machine)

ssh-keygen te pose alors deux questions :

Enter file in which to save the key (~/.ssh/id_ed25519):   # ou l'enregistrer -> Entree pour l'emplacement par defaut
Enter passphrase (empty for no passphrase):                # une passphrase pour chiffrer la cle privee (recommande)

Quel type de clé choisir ?

• ed25519 : le choix par défaut aujourd’hui. Clés courtes, génération et vérification rapides, sécurité excellente. Recommandé partout.
• rsa en 4096 bits (ssh-keygen -t rsa -b 4096) : l’option de compatibilité, si tu tombes sur un système ancien qui ne gère pas ed25519. Plus long, mais sûr en 4096 bits.

📚 La doc — Les types, tailles et options exactes de ssh-keygen évoluent avec les versions d’OpenSSH. En cas de doute sur un flag ou une valeur, la référence qui fait autorité est man ssh-keygen. On enseigne ici les choix stables (ed25519, RSA 4096) ; le détail courant est dans le manuel.

Où vivent les clés

Par défaut, ta paire atterrit dans le dossier ~/.ssh/ :

~/.ssh/id_ed25519        # la cle PRIVEE  -> reste chez toi, ne sort jamais
~/.ssh/id_ed25519.pub    # la cle PUBLIQUE -> c'est celle-ci qu'on distribue

La règle mnémotechnique : le fichier .pub (publique) est celui qu’on publie. L’autre, celui sans extension, est le trésor. Tu peux afficher ta clé publique sans risque :

cat ~/.ssh/id_ed25519.pub
# affiche une ligne du type : ssh-ed25519 AAAAC3Nza...  alex@formacampus
# c'est CETTE ligne qu'on colle dans authorized_keys du serveur

La passphrase

Quand ssh-keygen te propose une passphrase, dis oui. Elle chiffre ta clé privée sur ton disque. Sans elle, quiconque met la main sur ton fichier id_ed25519 (portable volé, backup qui fuit) obtient un accès direct à tous tes serveurs. Avec elle, le fichier volé est inutilisable sans la phrase secrète.

🔒 Sécurité — Une clé privée sans passphrase posée sur un laptop, c’est un passe pour tous tes serveurs à portée de qui vole la machine. La passphrase est ta deuxième ligne de défense : même clé volée, l’attaquant est bloqué. Le seul « coût » est de la taper — et l’agent SSH (plus bas) le réduit à une fois par session.

Déposer ta clé publique sur le serveur

Pour que le serveur te reconnaisse, il doit connaître ta clé publique. Elle se range dans un fichier précis du compte distant :

~/.ssh/authorized_keys   # sur le SERVEUR, dans le home de l'utilisateur vise (ex. deploy)

La méthode simple : ssh-copy-id

ssh-copy-id deploy@203.0.113.10
# se connecte (par mot de passe cette premiere fois) et AJOUTE ta cle publique
# a ~/.ssh/authorized_keys du compte deploy, avec les bonnes permissions

ssh-copy-id fait tout proprement : il crée ~/.ssh s’il manque, ajoute ta clé sans écraser les clés déjà présentes, et pose les bonnes permissions. C’est la voie recommandée. Ensuite, teste :

ssh deploy@203.0.113.10   # si tout est bon, tu entres SANS mot de passe (ou juste ta passphrase locale)

La méthode manuelle (et le piège des permissions)

Si ssh-copy-id n’est pas disponible, tu peux le faire à la main. Il faut créer le dossier, y écrire ta clé publique, et — le point critique — poser des permissions strictes, sinon sshd refuse la clé (par sécurité) :

# sur le SERVEUR, connecte en tant que deploy :
mkdir -p ~/.ssh                       # cree le dossier si absent
chmod 700 ~/.ssh                      # SEUL le proprietaire peut lire/ecrire/traverser
# colle ta cle publique a la fin du fichier :
echo "ssh-ed25519 AAAAC3Nza... alex@formacampus" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys      # SEUL le proprietaire peut lire/ecrire

Les deux permissions à connaître par cœur :

⚠️ Piège — Le grand classique : « j’ai copié ma clé, mais SSH me redemande quand même le mot de passe ». 9 fois sur 10, c’est les permissions. Si ~/.ssh ou authorized_keys sont accessibles au groupe ou aux autres (ex. 755, 644), sshd considère le dossier comme non sûr et ignore silencieusement ta clé. Remets chmod 700 ~/.ssh et chmod 600 ~/.ssh/authorized_keys. C’est aussi pour ça que ssh-copy-id est préférable : il ne se trompe pas de permissions.

L’agent SSH : taper sa passphrase une seule fois

Une passphrase, c’est sûr — mais la retaper à chaque ssh, c’est pénible. L’agent SSH résout ça : c’est un petit programme qui garde ta clé déverrouillée en mémoire pour la durée de ta session. Tu déverrouilles une fois, il s’occupe du reste.

ssh-add ~/.ssh/id_ed25519
# demande ta passphrase UNE fois, puis charge la cle dans l'agent
# les connexions suivantes ne te la redemandent plus de la session
ssh-add -l
# -l -> liste les cles actuellement chargees dans l'agent

Sur la plupart des systèmes de bureau, l’ssh-agent démarre tout seul avec ta session. Sur macOS, le trousseau peut mémoriser la passphrase durablement ; sur Linux, l’agent est souvent lancé par l’environnement de bureau.

🐚 Au terminal — Le trio à retenir pour une session de travail confortable :

eval "$(ssh-agent -s)"        # demarre l'agent si besoin (souvent deja lance)
ssh-add ~/.ssh/id_ed25519     # deverrouille la cle une fois pour la session
ssh deploy@203.0.113.10       # se connecte sans reclamer la passphrase

La règle absolue : ne jamais partager la clé privée

Ça mérite son propre encadré, parce que c’est l’erreur qui ruine tout :

🔒 Sécurité — Ta clé privée (id_ed25519, sans .pub) ne se partage JAMAIS : pas par email, pas sur un Slack, pas dans un dépôt git, pas « juste pour dépanner un collègue ». Elle ne quitte pas ta machine. Si tu dois donner accès à quelqu’un d’autre, il génère sa propre paire et tu ajoutes sa clé publique dans authorized_keys. Une clé privée qui a fuité est à considérer comme compromise : on la révoque (on retire la publique correspondante des serveurs) et on en régénère une neuve. La seule chose qu’on distribue, toujours, c’est le .pub.

Un mot sur les clés de déploiement (deploy keys)

Quand tu automatiseras le déploiement (Partie 13), ce n’est plus toi qui te connectes, mais un robot de CI (GitHub Actions) qui doit, par exemple, git pull sur le serveur ou pousser des fichiers. Pour ça, on utilise une clé de déploiement : une paire dédiée à cette automatisation, séparée de ta clé personnelle.

L’idée : la clé privée de déploiement vit dans les secrets de la CI (jamais dans le code), et sa portée est limitée (souvent en lecture seule, sur un seul dépôt ou serveur). Ainsi, si la CI est compromise, on révoque cette seule clé sans toucher à ton accès personnel ni à celui de l’équipe. On la met en place le moment venu — retiens juste le principe : une clé par usage, jamais une clé fourre-tout partagée.

🧭 Sur FormaCampus — Chaque membre de l’équipe FormaCampus génère sa propre paire ed25519 avec passphrase. On collecte les fichiers .pub (jamais les privées) et on les ajoute tous dans ~/.ssh/authorized_keys du compte deploy. Résultat : Alex, Léa et Sami se connectent chacun avec sa clé au même utilisateur deploy, et si l’un quitte l’équipe, on retire sa ligne du fichier — son accès disparaît, sans toucher aux autres. Plus tard, une clé de déploiement dédiée sera créée pour GitHub Actions, distincte des clés humaines.

✏️ Exercices

Exercice 1 — Génère et repère. Tu tapes ssh-keygen -t ed25519 -C "moi@laptop" et tu valides tout par défaut. Quels deux fichiers obtiens-tu, lequel est secret, et lequel copies-tu sur un serveur ?

Exercice 2 — Débogue la clé ignorée. Tu as copié ta clé publique à la main sur le serveur, mais ssh te redemande le mot de passe à chaque fois. ls -l montre drwxr-xr-x sur ~/.ssh et -rw-r--r-- sur authorized_keys. Quel est le problème et comment le corriges-tu ?

Exercice 3 — Un collègue rejoint l’équipe. Sami arrive et doit accéder au VPS via le compte deploy. Il te demande « tu peux m’envoyer ta clé ? ». Que réponds-tu, et quelle est la bonne procédure ?

🧠 Quiz de révision

Chapitre suivant : Config client & alias — pour taper ssh formacampus au lieu d’une longue ligne, et gérer plusieurs serveurs sans t’emmêler.