Créer et gérer des clés SSH

ssh-keygen -t ed25519

Ed25519 est l'algorithme recommandé dans OpenSSH 8.x et plus récent. Il est plus rapide et plus sûr que RSA-2048 ou RSA-3072. La commande crée deux fichiers : une clé privée et une clé publique.

2. Choisissez l'emplacement de stockage

`ssh-keygen` demande un chemin de fichier. Appuyez sur Entrée pour accepter l'emplacement par défaut :

Enter file in which to save the key (/home/utilisateur/.ssh/id_ed25519):

L'emplacement par défaut est `~/.ssh/id_ed25519` pour la clé privée et `~/.ssh/id_ed25519.pub` pour la clé publique. Le client SSH cherche automatiquement à ces chemins lors d'une connexion. Si vous voulez gérer plusieurs clés, donnez un nom propre, par exemple `~/.ssh/id_ed25519_pixzo`.

3. Définissez une passphrase

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Une passphrase chiffre la clé privée sur le disque. Sans passphrase, toute personne ayant un accès en lecture au fichier peut utiliser directement la clé. Mettez toujours une passphrase sur les clés qui se trouvent sur des systèmes partagés ou de production.

4. Vérifiez les fichiers générés

ls -la ~/.ssh/

Vous voyez maintenant deux fichiers : `id_ed25519` (privé) et `id_ed25519.pub` (public). La clé privée doit être lisible uniquement par votre utilisateur — vérifiez avec `ls -l` que les permissions sont `-rw-------`. Si ce n'est pas le cas, corrigez avec :

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

5. Copiez la clé publique vers le serveur

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@serveur.example.com

`ssh-copy-id` place la clé publique dans `~/.ssh/authorized_keys` sur le serveur. Cette commande demande une fois le mot de passe de l'utilisateur du serveur. Si `ssh-copy-id` ne fonctionne pas (par exemple sur une installation Linux minimale), copiez la clé manuellement :

cat ~/.ssh/id_ed25519.pub | ssh utilisateur@serveur.example.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

6. Testez l'authentification par clé

ssh utilisateur@serveur.example.com

Si la clé est correctement placée et que la passphrase est bonne, vous vous connectez sans mot de passe. Si un mot de passe est encore demandé, vérifiez l'étape 5 et les permissions sur le serveur : `~/.ssh` doit être `700` et `authorized_keys` doit être `600`.

7. Ajoutez la clé à ssh-agent (optionnel)

Pour l'administration quotidienne, vous ne voulez pas taper la passphrase à chaque fois. Chargez la clé dans l'agent SSH :

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

L'agent garde la clé déverrouillée en mémoire. Lors d'une nouvelle session de terminal, vous devez réexécuter `ssh-add`. Utilisez `ssh-add -l` pour vérifier quelles clés sont chargées.

8. Protégez la clé privée sur le client

La clé privée ne quitte jamais la machine locale. Assurez-vous que le dossier `~/.ssh` lui-même est bien protégé :

chmod 700 ~/.ssh

Sur un ordinateur portable qui peut être perdu, envisagez un répertoire personnel chiffré ou un chiffrement complet du disque. Une clé privée avec passphrase est la dernière ligne de défense — sans passphrase, un fichier volé est directement utilisable.

Vérification

Vérifiez que la clé fonctionne et que le serveur affiche la bonne empreinte :

ssh -v utilisateur@serveur.example.com

Dans la sortie de débogage, vous voyez `Authenticated to serveur.example.com ([IP]:22)` et `Server accepts key`. Vous pouvez aussi vérifier explicitement la clé publique sur le serveur :

ssh utilisateur@serveur.example.com "cat ~/.ssh/authorized_keys"

La sortie doit correspondre exactement au contenu de `~/.ssh/id_ed25519.pub` sur votre machine locale.

Problèmes fréquents

1. Permission denied (publickey) lors de la connexion

Le serveur n'accepte pas la clé. Vérifiez les permissions sur le serveur : `~/.ssh` doit être `700`, `authorized_keys` doit être `600`. Vérifiez aussi que vous présentez la bonne clé : `ssh -i ~/.ssh/id_ed25519 utilisateur@serveur`. Sur certains systèmes, `PubkeyAuthentication no` est défini dans `/etc/ssh/sshd_config` — mettez-le à `yes` et redémarrez `sshd`.

2. `ssh-keygen` n'existe pas sur Windows

Windows 10 (build 1809 ou plus récent) et Windows 11 ont OpenSSH intégré. Ouvrez PowerShell ou l'invite de commandes et exécutez `ssh-keygen.exe`. S'il n'est pas présent, installez le client OpenSSH via Paramètres → Applications → Fonctionnalités optionnelles → Ajouter une fonctionnalité → Client OpenSSH.

3. Les clés PuTTY ne fonctionnent pas avec OpenSSH

PuTTYgen enregistre les clés privées au format `.ppk`. OpenSSH utilise son propre format. Convertissez avec :

puttygen id_ed25519.ppk -O private-openssh -o id_ed25519

Si vous n'avez pas `puttygen` sur Linux, installez `putty-tools` (Debian/Ubuntu : `sudo apt install putty-tools`). La clé publique peut être copiée directement depuis PuTTYgen — elle est compatible avec `authorized_keys`.

La gestion des clés SSH ne s’arrête pas à leur création. Les clés n’expirent pas, donc une clé divulguée reste valable jusqu’à ce que vous la supprimiez manuellement de `authorized_keys` sur chaque serveur où elle a été installée — et c’est précisément pour cela que vous gardez un nombre limité de clés et que vous utilisez une clé distincte par environnement.