Quelle version d'OpenSSH faut-il pour les clés FIDO2 (ed25519-sk) ?

Côté serveur comme côté client, il faut OpenSSH 8.2 au minimum, et plutôt 8.3 pour les clés résidentes. C'est acquis sur Debian 11+, Ubuntu 20.04+, RHEL 9. Le piège, ce sont les vieux serveurs encore en production : une Debian 10 plafonne à OpenSSH 7.9 et ne reconnaîtra pas ce type de clé. Vérifiez avec `ssh -V` avant de promettre du FIDO2 à un client, sinon vous vous rabattez sur une clé ed25519 classique.

On gère les clés autorisées à la main sur chaque serveur ?

Au-delà de quelques machines, non, ça devient ingérable et c'est la première source de comptes fantômes. Les `authorized_keys` se déploient par votre outil de configuration (Ansible, Salt) à partir d'une source unique. Mieux, sur un parc qui grossit : un certificat SSH signé par une autorité interne, à durée de vie courte. Vous signez une fois, vous n'avez plus à pousser de clé sur chaque hôte, et la révocation passe par l'expiration plutôt que par un nettoyage manuel.

Le bastion devient un point de défaillance unique, non ?

C'est l'objection juste. Si le bastion tombe, plus personne n'entre par la voie normale. La réponse tient en deux temps. D'abord on le redonde : deux bastions derrière un même nom, pas un seul. Ensuite on garde l'accès console de l'hébergeur comme issue de secours indépendante de SSH. Un point de passage unique pour le quotidien ne veut pas dire un point de défaillance unique, à condition de l'avoir prévu.

Un prestataire externe qui doit intervenir ponctuellement, comment on l'intègre ?

Sans lui donner une clé permanente sur le parc. Le bastion sert exactement à ça : un compte dédié au prestataire, un accès ouvert pour la durée de l'intervention puis refermé, et la trace de tout ce qui s'est connecté pendant ce temps. Si l'enjeu est fort, on couple à un certificat de quelques heures, qui expire de lui-même même si on oublie de couper l'accès.

Durcir l'accès SSH d'un parc de serveurs

Durcir SSH, c’est restreindre la manière dont on prouve son identité au serveur et réduire le nombre de portes qui acceptent une connexion. Concrètement : authentification par clé seule, mot de passe désactivé, accès concentrés derrière un bastion, second facteur sur ce qui le mérite.

Pourquoi s’en préoccuper en priorité ? SSH est la première chose que cherchent les attaques automatisées. Exposez un serveur frais sur le port 22, attendez dix minutes, ouvrez les journaux : des tentatives de connexion par centaines, depuis des adresses du monde entier. Aucun humain là-dedans. Juste des robots qui balaient Internet sans relâche.

Durcir l’accès SSH, c’est n’accepter que l’authentification par clé, couper le mot de passe, concentrer les accès derrière un bastion et ajouter un second facteur là où l’enjeu le justifie.

Clés uniquement, mot de passe coupé

C’est la mesure qui change tout. Une clé SSH est un secret cryptographique qu’aucune force brute ne devine, là où un mot de passe finit par tomber sous assez de tentatives. Vous configurez le serveur pour n’accepter que les clés et refuser l’authentification par mot de passe (PasswordAuthentication no dans sshd_config, et tant qu’à faire PermitRootLogin no). Le trafic d’attaque tourne alors dans le vide.

Le jour où je pose ça sur un parc, l’effet se lit dès le lendemain : les milliers de lignes de tentatives échouées s’évaporent des logs. Cinq minutes par serveur, et c’est de loin le meilleur rapport effort/résultat de la liste.

Le bastion, une seule porte

Exposer le SSH de chaque machine, c’est multiplier les portes à surveiller. Une porte, ça suffit. On préfère exposer un bastion : un serveur durci par lequel transitent tous les accès, les machines internes n’étant joignables qu’à travers lui.

Trois bénéfices se cumulent. La surface chute d’abord : une seule porte sur Internet au lieu de dizaines. La journalisation se centralise ensuite, et vous savez d’un coup d’œil qui s’est connecté, quand, vers où. Reste la gestion des accès, accordés et révoqués au même endroit : un départ dans l’équipe se coupe au bastion, pas sur quinze serveurs un par un.

Sur un parc d’une vingtaine de machines chez un client industriel, ce seul changement a divisé la surface exposée par vingt et rendu l’audit des accès trivial. Avant, personne ne savait vraiment qui pouvait se connecter où.

Le second facteur, là où ça compte

Sur les accès sensibles, j’ajoute un second facteur au-delà de la clé. Une clé, ça fuite. Un poste volé, une clé privée laissée par mégarde dans un dépôt Git, ça arrive plus souvent qu’on ne l’admet. Avec un second facteur, l’attaquant qui récupère la clé reste bloqué à la porte. Je le pose en priorité sur le bastion, puisque tout y transite : c’est le point qui mérite la protection la plus sérieuse.

Le reste qui paie

Quelques réglages plus discrets complètent l’ensemble. Pas de connexion root directe, mais des comptes nominatifs : quand quelque chose tourne mal, vous voulez savoir qui était derrière le clavier. Restreindre les sources quand c’est possible, en n’ouvrant SSH que depuis des adresses connues ; sur un parc dont les administrateurs se connectent depuis n’importe où ce n’est pas toujours faisable, sur les serveurs vraiment sensibles ça l’est presque toujours. Et surveiller les échecs répétés comme les connexions hors horaires : une session à 3 h du matin sur un compte qui ne travaille jamais la nuit mérite une alerte.

Là où la méthode s’arrête

Soyons honnête sur le périmètre. Tout ce qui précède protège l’accès au serveur, et rien d’autre. Une clé légitime sur un poste compromis ouvre la porte aussi proprement que la vôtre. Et le second facteur ne vous sauve que si le poste qui le saisit n’est pas déjà aux mains de l’attaquant. Le durcissement SSH ferme le harcèlement automatisé et discipline les accès humains, deux gains réels. Il ne remplace ni la mise à jour des services exposés, ni la surveillance de ce que font les sessions une fois ouvertes. C’est un socle, pas une fin. Je l’applique dès la mise en service, en sachant que c’est le premier mur, pas le dernier.