Clé SSH

Votre mot de passe transite sur le câble. Chaque switch, chaque appareil sur la route peut le lire. Les clés SSH résolvent ce problème avec la cryptographie, mais le passage du mot de passe à la clé effraie beaucoup d'administrateurs — à tort. Cet article explique comment générer, installer et utiliser une clé Ed25519 sur un serveur Linux, et pourquoi cette approche est meilleure que ce que vous faites actuellement.

Prérequis

• Un client Linux avec OpenSSH 7.0 ou plus récent (vérifiez avec `ssh -V`). Tout ce qui date d'Ubuntu 16.04 ou Debian 9 convient.
• Un accès à un serveur distant via SSH avec mot de passe.
• `ssh-copy-id` présent sur votre client (standard avec OpenSSH, paquet séparé sur certaines distributions).

Ce que fait une clé SSH

Une clé SSH est une paire cryptographique : une clé privée qui reste sur votre machine et une clé publique qui est placée sur le serveur. Lors de la connexion, votre client prouve avec la clé privée qu'il correspond à la clé publique. Le serveur vérifie cela avec la clé publique et vous laisse entrer — sans mot de passe.

Ce n'est pas un détail. Cela signifie qu'aucun mot de passe ne circule plus sur le réseau et ne peut être intercepté. Cela signifie aussi qu'une attaque par force brute sur votre port SSH devient inutile : il n'y a rien à deviner.

Le prix de cette sécurité est que votre clé privée devient la nouvelle surface d'attaque. Quelqu'un qui s'empare de votre ordinateur portable et trouve la clé sans phrase de passe a accès à tout ce que cette clé permet d'ouvrir. C'est pourquoi une phrase de passe doit être placée sur votre clé — nous y reviendrons plus tard.

Générer une paire de clés

Ouvrez un terminal sur votre client et tapez :

ssh-keygen -t ed25519 -a 100 -C "votre@email.fr"

Ed25519 est l'algorithme que vous voulez. Il est plus rapide que RSA, les clés sont plus petites et la sécurité est mieux documentée. Le `-a 100` indique à ssh-keygen de faire passer la clé 100 fois par la fonction KDF ; cela rend une attaque par force brute sur votre phrase de passe plus coûteuse. Le `-C` est un champ de commentaire, utile pour voir plus tard quelle clé sert à quoi.

La commande demande où vous voulez enregistrer la clé. L'emplacement par défaut est `~/.ssh/id_ed25519`. Vous pouvez le conserver, sauf si vous avez déjà une clé à cet endroit — ne l'écrasez pas. Ensuite, elle demande une phrase de passe. Vous pouvez la laisser vide, mais ne le faites pas. Une clé sans phrase de passe est un fichier texte qui, une fois volé, fonctionne directement.

La sortie se termine par une empreinte et une "image randomart". Notez cette empreinte quelque part ; plus tard, vous pourrez vérifier avec elle que vous parlez au bon serveur.

Installer la clé publique

La clé publique doit aller sur le serveur, dans le fichier `~/.ssh/authorized_keys` de l'utilisateur avec lequel vous voulez vous connecter. Cela peut se faire manuellement, mais il existe une commande qui le fait pour vous :

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

Vous devez encore taper votre mot de passe une fois, ensuite `ssh-copy-id` copie la clé au bon endroit et règle correctement les permissions. Si votre serveur écoute sur un autre port que le 22, ajoutez `-p ` à la commande.

Pas de `ssh-copy-id` sur votre système ? Alors collez la clé manuellement. Affichez la clé publique avec :

cat ~/.ssh/id_ed25519.pub

Copiez la ligne complète et ajoutez-la sur le serveur dans `~/.ssh/authorized_keys`. Créez ce dossier s'il n'existe pas :

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "la-clé-publique-copiée" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Les permissions ne sont pas une formalité. OpenSSH refuse d'utiliser des clés provenant de fichiers lisibles par d'autres. Une `authorized_keys` avec `chmod 644` ne fonctionne tout simplement pas.

Se connecter sans mot de passe

Maintenant, vous pouvez vous connecter sans mot de passe :

ssh utilisateur@serveur.exemple.com

Vous tapez maintenant votre phrase de passe au lieu de votre mot de passe. Cela semble identique, mais ce ne l'est pas : la phrase de passe ne quitte pas votre machine. Elle ne fait que déverrouiller votre clé privée en mémoire.

Si vous n'avez pas défini de phrase de passe, vous vous connectez maintenant sans aucune invite. Pratique pour les scripts, mais votre clé privée est alors stockée non chiffrée sur le disque.

Ne pas taper la phrase de passe à chaque fois

Une phrase de passe à saisir à chaque connexion devient vite agaçante, surtout si vous vous connectez plusieurs fois par jour. `ssh-agent` mémorise la clé déverrouillée pour votre session.

Démarrez l'agent et ajoutez votre clé :

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

Vous tapez votre phrase de passe une fois. Ensuite, `ssh` utilise la clé de l'agent pour toutes les connexions, jusqu'à ce que vous arrêtiez l'agent ou vous déconnectiez. Sur la plupart des bureaux Linux, un ssh-agent tourne déjà dans votre session ; vérifiez avec `ssh-add -l` si des clés sont chargées.

C'est aussi ce que vous voulez pour l'automatisation. Une tâche cron qui fait une sauvegarde via rsync ne peut pas saisir une phrase de passe de manière interactive. Avec l'agent chargé, elle fonctionne sans invite.

Désactiver l'authentification par mot de passe

Vous avez maintenant l'authentification par clé qui fonctionne. L'étape suivante est de désactiver la connexion par mot de passe sur le serveur, car tant qu'elle est active, la force brute reste un risque.

Sur le serveur, modifiez `/etc/ssh/sshd_config` en tant que root :

sudo nano /etc/ssh/sshd_config

Ajoutez ou modifiez ces lignes :

PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no

La troisième ligne est importante. Beaucoup de systèmes utilisent PAM pour l'authentification "keyboard-interactive", et cela contourne parfois `PasswordAuthentication no`. Avec `KbdInteractiveAuthentication no`, vous fermez cette porte dérobée.

Redémarrez ensuite SSH :

sudo systemctl restart sshd

Avant de fermer la session actuelle : ouvrez un deuxième terminal et testez si vous pouvez encore vous connecter avec votre clé. S’il y a une erreur dans votre configuration, vous êtes dehors et vous devrez rentrer par la console ou le panneau du fournisseur. Cette erreur vous coûte un après-midi.

Vérification

Vérifiez que tout fonctionne :

ssh -v utilisateur@serveur.exemple.com

Dans la sortie, cherchez une ligne comme `Authenticated to serveur.exemple.com ([IP]:22)` et `Server accepts key`. Si vous voyez `Permission denied (publickey)`, le serveur n’accepte pas votre clé — vérifiez les permissions de `~/.ssh` et de `authorized_keys` sur le serveur.

Un deuxième contrôle : regardez sur le serveur si des connexions par mot de passe arrivent encore :

sudo grep "Failed password" /var/log/auth.log | tail -20

Après la désactivation de l’authentification par mot de passe, cette liste devrait rester vide, à part les tentatives qui étaient déjà en cours.

Erreurs fréquentes

Le serveur n’accepte pas la clé. Vérifiez les permissions : `~/.ssh` doit être `700`, `authorized_keys` `600`. Vérifiez aussi que vous avez copié la clé publique et non la privée — celle-ci ne doit jamais se trouver sur un serveur.

`ssh-copy-id` demande un mot de passe pour un autre utilisateur. Vous copiez la clé vers le mauvais compte. Connectez-vous avec le nom d’utilisateur que vous utilisez normalement et répétez la commande.

Vous ne pouvez plus vous connecter après la désactivation de l’auth par mot de passe. La configuration sshd contient une erreur ou votre clé n’est pas correctement placée sur le serveur. Connectez-vous via la console ou une solution hors bande, remettez `PasswordAuthentication` sur `yes`, redémarrez sshd et refaites les étapes.

Les clés ne fonctionnent pas dans une tâche cron. Cron tourne sans votre agent ssh. N’utilisez pas une clé sans phrase de passe pour cela ; créez une clé séparée par tâche avec sa propre phrase de passe et chargez-la dans un agent accessible à la tâche cron, ou utilisez un outil comme `keychain` pour démarrer l’agent par session.

Ce que vous avez maintenant

Vous vous connectez sans mot de passe sur le réseau, votre serveur n’est plus ouvert aux attaques par force brute et votre clé privée est chiffrée sur votre machine. Au cas où vous vous poseriez la question : oui, c’est aussi comme cela que vous sécurisez Git-over-SSH et les sauvegardes rsync. La même clé fonctionne pour cela.

Une clé SSH n’est pas une configuration à faire une seule fois. Si votre machine est volée, vous devez retirer la clé publique de tous les serveurs et générer une nouvelle paire. Mais c’est un incident, pas un souci quotidien. Le souci quotidien — un mot de passe qui passe sur le réseau à chaque fois — est réglé.