SSH par clés Ed25519 : durcir l’accès sans se verrouiller dehors

ParKelvin Carretero-Corrales

Passer SSH d’un mot de passe à une clé publique est une amélioration simple et efficace. Le piège, ce n’est pas la cryptographie : c’est de désactiver le mot de passe trop tôt, de fermer sa seule session ouverte, puis de découvrir que la clé ne fonctionne pas.

Voici une méthode progressive pour un serveur Ubuntu ou Debian avec OpenSSH. L’objectif est double : réduire le risque d’accès frauduleux et conserver une porte de sortie à chaque étape.

Clé SSH : ce qui reste sur le poste et ce qui part sur le serveur

Une paire de clés contient deux éléments :

  • la clé privée, qui reste sur votre ordinateur et ne doit jamais être envoyée sur le serveur ;
  • la clé publique, que l’on ajoute dans le fichier ~/.ssh/authorized_keys du compte distant.

Lors de la connexion, le serveur vérifie que le client possède bien la clé privée correspondant à la clé publique autorisée. Le secret ne traverse pas le réseau.

1. Générer une clé Ed25519 sur le poste client

La documentation Ubuntu recommande Ed25519 pour sa clé courte et son faible coût de calcul. La génération se fait sur l’ordinateur depuis lequel vous administrerez le serveur, pas sur le serveur lui-même :

ssh-keygen -t ed25519 -C "admin-serveur-2026"

Conservez l’emplacement proposé si vous n’avez pas de besoin particulier. Ajoutez une phrase secrète solide : si le fichier privé est copié ou volé, cette protection complique son utilisation immédiate. Un agent SSH peut mémoriser temporairement la phrase secrète pour éviter de la ressaisir à chaque connexion.

Par défaut, vous obtenez généralement :

  • ~/.ssh/id_ed25519 : clé privée, à ne jamais partager ;
  • ~/.ssh/id_ed25519.pub : clé publique, destinée au serveur.

2. Installer uniquement la clé publique

Tant que l’authentification par mot de passe fonctionne encore, la méthode la plus simple est :

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

Remplacez utilisateur et serveur par vos valeurs. Cette commande ajoute la clé publique au fichier authorized_keys du bon compte. Elle ne copie pas la clé privée.

Si vous gérez plusieurs clés, indiquez explicitement celle à utiliser lors du test :

ssh -i ~/.ssh/id_ed25519 utilisateur@serveur

3. Tester dans une deuxième fenêtre, sans fermer la première

Gardez votre session SSH actuelle ouverte. Ouvrez un second terminal et connectez-vous avec la clé. Vérifiez trois choses :

  • la connexion aboutit sans demander le mot de passe du compte distant ;
  • vous arrivez sur le bon compte avec whoami ;
  • la commande sudo -v fonctionne si ce compte doit administrer le serveur.

La phrase secrète de la clé peut toujours être demandée : c’est normal. Elle protège le fichier privé local et ne correspond pas au mot de passe du compte Linux.

Si le test échoue, ne touchez pas encore à la configuration du serveur. Consultez les journaux dans la première session :

sudo journalctl -fu ssh.service

Les causes courantes sont un mauvais propriétaire, des permissions trop larges sur ~/.ssh ou authorized_keys, ou une clé ajoutée au mauvais utilisateur.

4. Ajouter une configuration serveur claire

Sur Ubuntu récent, le fichier principal inclut généralement les fragments placés dans /etc/ssh/sshd_config.d/. OpenSSH retient la première valeur rencontrée pour la plupart des directives : l’ordre des fichiers compte donc réellement.

Créez par exemple un fichier /etc/ssh/sshd_config.d/10-furetlabs-hardening.conf contenant :

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Ces réglages autorisent les clés publiques, désactivent l’authentification classique par mot de passe et l’authentification interactive au clavier, puis interdisent la connexion directe du compte root. L’administration passe par un utilisateur nominatif autorisé à utiliser sudo.

Attention : ne désactivez pas KbdInteractiveAuthentication si vous utilisez volontairement un second facteur SSH fourni par PAM. Dans ce cas, adaptez la politique d’authentification au mécanisme réellement déployé.

5. Valider avant de recharger

Une faute de frappe peut empêcher le service SSH de repartir. OpenSSH fournit précisément un mode de test :

sudo sshd -t

Si la commande ne renvoie rien, la syntaxe est valide. Cela ne prouve toutefois pas que les valeurs effectives sont celles attendues. Vérifiez-les avec :

sudo sshd -T | grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

Le résultat attendu est :

pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
permitrootlogin no

Si une valeur diffère, cherchez un réglage contradictoire dans /etc/ssh/sshd_config et dans les fichiers de /etc/ssh/sshd_config.d/. Ne rechargez pas le service avant d’avoir compris quelle directive gagne réellement.

6. Recharger, puis refaire un test neuf

Sur Ubuntu, rechargez la configuration avec :

sudo systemctl reload ssh.service

Le nom du service peut être sshd.service sur une autre distribution. Gardez toujours la première session ouverte, puis lancez une troisième connexion neuve. Ce nouveau test est indispensable : une session déjà établie continue souvent de fonctionner même si la configuration des nouvelles connexions est cassée.

Testez aussi volontairement l’échec du mot de passe :

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password utilisateur@serveur

La connexion doit être refusée. Ensuite seulement, vous pouvez fermer la session de secours.

Ce que cette configuration ne règle pas

Une clé SSH ne remplace pas toute la sécurité du serveur. Il reste nécessaire de :

  • mettre OpenSSH et le système à jour ;
  • limiter les comptes autorisés à se connecter ;
  • protéger et sauvegarder les clés privées de façon maîtrisée ;
  • retirer rapidement les clés d’un appareil perdu ou d’un intervenant parti ;
  • surveiller les journaux et les tentatives de connexion ;
  • conserver un accès de secours fourni par l’hébergeur ou la console locale.

Changer le port 22 peut réduire le bruit dans les journaux, mais ce n’est pas une protection d’authentification. Cela ne remplace ni les clés, ni les permissions minimales, ni une configuration vérifiée.

En conclusion

Le durcissement SSH le plus sûr n’est pas celui qui empile vingt directives. C’est celui qui suit une bascule contrôlée : créer la clé, installer uniquement la partie publique, tester une nouvelle session, vérifier la configuration effective, puis désactiver le mot de passe.

Pour un serveur ou un poste qui doit être remis à plat sans avancer à l’aveugle, FuretLabs présente ses prestations de diagnostic, remise en service et bonnes pratiques de sécurité. Le périmètre est défini avant toute intervention.

Sources

Publications similaires