02 - Les clés SSH de A a Z

Ce que tu vas apprendre

• Generer une clé SSH avec Ed25519
• Comprendre la différence entre clé publique et clé privee
• Configurer ~/.ssh/config pour gerer plusieurs clés
• Utiliser ssh-agent pour ne pas retaper ta passphrase
• Éviter les erreurs classiques de permissions

Prerequisites

• 01 - Chiffrement symetrique vs asymetrique : comprendre le concept de clé publique/privee

Generer ta première clé SSH

Oublie RSA. En 2026, le standard c'est Ed25519. Les clés sont plus courtes (256 bits vs 3072+ pour RSA), la génération est plus rapide, et la sécurité est équivalente. Le seul cas ou tu aurais besoin de RSA, c'est un vieux serveur qui ne supporte pas Ed25519 (avant OpenSSH 6.5, soit 2014).

bashssh-keygen -t ed25519 -C "ton.email@exemple.com"

L'option -C ajoute un commentaire (par convention, ton email). Ca aide a identifier la clé quand tu en as plusieurs.

SSH te demande ou sauvegarder la clé (par défaut ~/.ssh/id_ed25519) et une passphrase. Mets toujours une passphrase. Toujours. Une clé SSH sans passphrase, c'est comme un mot de passe en clair sur ton disque. Si quelqu'un copie ton ~/.ssh/id_ed25519, il a acces a tous tes serveurs.

Tu obtiens deux fichiers :

• ~/.ssh/id_ed25519 : ta clé privee. Ne la partage jamais. Jamais.
• ~/.ssh/id_ed25519.pub : ta clé publique. Tu peux la coller partout : GitHub, GitLab, tes serveurs.

Installer ta clé sur un serveur

Pour te connecter a un VPS sans mot de passe, copie ta clé publique :

bashssh-copy-id -i ~/.ssh/id_ed25519.pub user@mon-serveur.com

Cette commande ajoute ta clé publique dans ~/.ssh/authorized_keys sur le serveur. Si ssh-copy-id n'est pas dispo (Windows sans WSL, par exemple), tu peux faire a la main :

bashcat ~/.ssh/id_ed25519.pub | ssh user@mon-serveur.com "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Les permissions, le piège classique

SSH est paranoiaque sur les permissions. Si tes fichiers sont trop ouverts, il refuse de fonctionner. Et le message d'erreur est souvent juste Permission denied sans plus de détails (ajoute -v pour debugger).

bash# Les permissions correctes
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/config

J'ai perdu des heures la-dessus. Sur mon premier serveur Debian, j'avais copie les fichiers avec scp et les permissions etaient parties en 755. SSH refusait la connexion sans explication claire. Le reflexe a avoir : quand ca marche pas, vérifié les permissions d'abord.

ssh-agent : ne retape pas ta passphrase 50 fois

Si tu mets une passphrase (et tu dois en mettre une), tu vas la taper a chaque git push, chaque ssh, chaque scp. C'est penible. Le ssh-agent resout ca : il garde ta clé dechiffree en mémoire le temps de ta session.

bash# Demarrer l'agent
eval "$(ssh-agent -s)"

# Ajouter ta cle
ssh-add ~/.ssh/id_ed25519

Sur macOS, tu peux ajouter la passphrase au Keychain :

bashssh-add --apple-use-keychain ~/.ssh/id_ed25519

Sur Linux avec un environnement graphique (GNOME, KDE), l'agent est souvent démarré automatiquement. Sur un serveur headless, ajoute le eval dans ton .bashrc ou .zshrc.

~/.ssh/config : le fichier qui change tout

Taper ssh -i ~/.ssh/id_ed25519_perso -p 2222 nicolas@192.168.1.42 a chaque fois, c'est non. Le fichier ~/.ssh/config te permet de créer des alias :

# Serveur perso
Host mon-vps
    HostName 192.168.1.42
    User nicolas
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_perso

# GitHub (compte perso)
Host github-perso
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_perso

# GitLab (compte pro)
Host gitlab-pro
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_ed25519_pro
    IdentitiesOnly yes

L'option IdentitiesOnly yes est importante quand tu as plusieurs clés : elle empeche SSH d'essayer toutes les clés du ssh-agent et de se faire bloquer apres trop de tentatives.

Maintenant, tu peux juste faire :

bashssh mon-vps
git clone git@github-perso:mon-user/mon-repo.git

Exemple concret : VPS + GitLab

Voici un setup réel pour un développeur fullstack qui a un VPS chez Hetzner et un compte GitLab pro :

bash# Generer deux cles separees
ssh-keygen -t ed25519 -C "perso@email.com" -f ~/.ssh/id_ed25519_perso
ssh-keygen -t ed25519 -C "pro@entreprise.com" -f ~/.ssh/id_ed25519_pro

# Copier la cle perso sur le VPS
ssh-copy-id -i ~/.ssh/id_ed25519_perso.pub root@mon-vps.hetzner.com

# Ajouter la cle pro sur GitLab : Settings > SSH Keys > coller le contenu de :
cat ~/.ssh/id_ed25519_pro.pub

Une clé par contexte. Si ta clé pro est compromise, tes serveurs perso ne sont pas affectes. J'en reparle dans l'article sur la gestion des clés.

Les erreurs que tout le monde fait (moi y compris)

1. Pas de passphrase. "C'est plus pratique." Oui, jusqu'a ce que ton laptop se fasse voler.
2. Une seule clé pour tout. Si elle est compromise, tout tombe.
3. Oublier de mettre à jour authorized_keys apres une rotation de clé (mon anecdote du vendredi soir, dans l'introduction).
4. Copier sa clé privee par email ou Slack. Ca arrive plus souvent qu'on croit.
5. Ne pas désactiver l'authentification par mot de passe sur ses serveurs. Edite /etc/ssh/sshd_config et mets PasswordAuthentication no.

La suite

Tu sais générer et utiliser des clés SSH. Mais SSH, c'est de l'authentification. Pour signer des fichiers et chiffrer des messages, il te faut GPG. C'est le sujet du prochain article : GPG : signer, chiffrer, prouver son identité.

Navigation : Precedent : 01 - Symetrique vs asymetrique | Suivant : 03 - GPG

Sources

• SSH Academy - SSH Key Management par SSH.com
• Ed25519: high-speed high-security signatures par Daniel J. Bernstein et al.
• ArchWiki - SSH keys par ArchWiki
• GitHub Docs - Connecting with SSH par GitHub

Retrouve d'autres articles techniques sur paltemps.fr.