Sécuriser OpenSSH sans se couper l'accès au serveur

OpenSSH est souvent la porte d’entrée la plus importante d’un serveur. Quand il est bien configuré, il permet d’administrer une machine à distance sans exposer inutilement les comptes, les mots de passe ou les services internes. Quand il est laissé tel quel, il devient une cible visible pour les scans automatiques, les essais de connexion et les erreurs de maintenance, avec un niveau de risque disproportionné par rapport à quelques réglages simples.

Le bon objectif n’est pas de rendre SSH “invisible” par magie. Il faut réduire la surface d’attaque, garder un accès de secours, tester chaque changement et documenter le retour arrière. Une configuration sérieuse se construit donc par étapes : clés publiques, comptes autorisés, restrictions réseau, validation de sshd_config, puis rechargement prudent du service, avec un contrôle immédiat depuis une nouvelle session et une lecture des journaux juste après application.

Comprendre ce que protège vraiment OpenSSH

OpenSSH protège un accès d’administration. Cela veut dire qu’une erreur ne touche pas seulement un service secondaire : elle peut donner un shell, un tunnel ou un transfert de fichiers à une personne non autorisée. Le durcissement doit donc rester simple, lisible et reproductible, afin qu’un autre administrateur puisse comprendre les règles sans dépendre de votre mémoire, relire le fichier en urgence et savoir quelle exception est volontaire.

Le fichier central côté serveur est sshd_config, généralement situé dans /etc/ssh/. Il définit les ports d’écoute, les méthodes d’authentification, les comptes autorisés, les règles par groupe et plusieurs limites de session. Le fichier ssh_config, lui, concerne surtout le comportement du client SSH, ce qui évite de mélanger une préférence locale avec une règle réellement appliquée au serveur lorsque plusieurs machines clientes utilisent des profils différents.

La première règle consiste à ne jamais modifier un serveur distant sans filet. Ouvrez une seconde session, gardez un accès console si votre hébergeur le propose, copiez le fichier original et préparez la commande de rollback. Ce rituel paraît lent, mais il évite de vous enfermer dehors après une faute de syntaxe, une directive trop restrictive ou un pare-feu mis à jour dans le mauvais ordre, surtout sur un VPS sans support immédiat.

Commencer par l’accès de secours

Avant de toucher à l’authentification, gardez votre session SSH actuelle ouverte. Ouvrez ensuite une nouvelle fenêtre et vérifiez que vous pouvez encore vous connecter avec le compte prévu. Cette double vérification évite de découvrir trop tard qu’une clé est mal copiée, qu’un groupe n’est pas autorisé ou que le service écoute sur une interface différente de celle que vous utilisez.

Faites aussi une sauvegarde lisible : cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-YYYYMMDD. Notez le port actuel, le compte administrateur, l’adresse IP d’administration et la commande de restauration. La sauvegarde doit être compréhensible par quelqu’un d’autre que vous, surtout si l’incident arrive pendant une astreinte ou après un changement d’équipe.

Le durcissement SSH est utile seulement si vous pouvez encore administrer le serveur après l’avoir appliqué, testé et documenté.

Passer aux clés publiques sans se piéger

L’authentification par clé publique est la base d’un accès SSH propre. Elle évite d’exposer un mot de passe au bruteforce et permet de révoquer une clé sans changer tout le compte. Mais elle doit être testée avant de désactiver l’authentification par mot de passe, car une mauvaise permission sur le dossier utilisateur peut suffire à faire échouer une clé pourtant correcte.

La séquence prudente est simple : générer une clé moderne côté poste, copier la clé publique dans authorized_keys, vérifier les permissions, tester une nouvelle connexion, puis seulement ensuite durcir PasswordAuthentication. Si vous sautez l’étape de test, la clé SSH peut devenir votre point de blocage au lieu d’être votre protection, en particulier sur les distributions qui appliquent des permissions strictes aux dossiers utilisateur ou aux répertoires personnels chiffrés, et sur les serveurs où plusieurs comptes se ressemblent.

Pour approfondir ce point, consultez dumbphone, qui traite plus précisément de revenir au dumbphone sans se couper du monde.

• À vérifier : la clé publique est dans le bon compte, pas dans celui de root par erreur.
• À éviter : partager une même clé privée entre plusieurs administrateurs.
• À conserver : une clé de secours contrôlée, documentée et protégée.
• À surveiller : les clés anciennes laissées dans authorized_keys après un départ.

Limiter root et les comptes autorisés

Un accès root direct est confortable, mais il concentre le risque. Un compte administrateur nominatif, associé à sudo, donne une meilleure traçabilité et limite les dégâts si une clé est compromise. Selon votre distribution, PermitRootLogin peut être déjà restreint, mais il faut le vérifier explicitement, car une image serveur ancienne ou une migration peut conserver un comportement inattendu.

La directive AllowUsers permet de n’autoriser que certains comptes. AllowGroups est souvent plus pratique dans une équipe, parce qu’il suffit de gérer l’appartenance au groupe. Dans les deux cas, le compte autorisé doit être testé avant rechargement définitif, puis revu à chaque départ, changement de prestataire ou fin de mission temporaire, car les accès oubliés deviennent vite plus dangereux que les réglages manquants et survivent souvent aux refontes d’infrastructure.

Ne multipliez pas les comptes “admin” génériques. Ils compliquent les audits, masquent les responsabilités et restent souvent actifs trop longtemps. Un accès SSH doit correspondre à une personne, un usage ou une automatisation clairement identifiée.

Changer le port SSH : utile, mais secondaire

Changer le port par défaut peut réduire le bruit dans les journaux, car beaucoup de robots scannent d’abord le port 22. C’est utile pour respirer un peu côté logs, mais ce n’est pas une protection suffisante. Un scan complet trouvera le service si le serveur est exposé.

Traitez ce réglage comme un filtre de confort, pas comme une preuve de sécurité durable sur un serveur exposé.

Si vous changez de port, ouvrez le nouveau port dans le pare-feu avant de recharger SSH. Testez la connexion avec ssh -p. Gardez le port 22 ouvert quelques minutes seulement si nécessaire, puis fermez-le une fois la bascule validée. Le pare-feu doit suivre la configuration, sinon le service est prêt mais inaccessible, ce qui donne l’impression d’une panne SSH alors que la règle réseau bloque simplement l’entrée et ralentit le diagnostic.

Sur un serveur d’entreprise, la restriction par adresse IP est souvent plus forte qu’un simple changement de port. Autoriser SSH uniquement depuis un VPN, un bastion ou quelques adresses d’administration réduit beaucoup la surface exposée.

Valider la configuration avant reload

Chaque modification doit passer par un test de syntaxe. La commande sshd -t signale les erreurs de configuration sans interrompre le service. Elle ne garantit pas que votre logique est parfaite, mais elle évite les fautes qui empêchent le démon de redémarrer, ce qui est déjà une protection essentielle quand le serveur n’a pas d’accès console immédiat ou dépend d’une fenêtre de maintenance courte.

Préférez ensuite un reload lorsque le système le permet : systemctl reload sshd ou systemctl reload ssh, selon la distribution. Un restart complet peut fermer des sessions et augmenter le risque si vous n’avez pas d’accès console. Le reload reste le choix le plus prudent pour appliquer une configuration valide.

Après application, ouvrez une nouvelle session et vérifiez le cas qui compte vraiment : le compte administrateur prévu, la clé prévue, le port prévu et l’adresse prévue. Ne vous contentez pas de voir le service actif, car un service peut tourner parfaitement tout en refusant le seul accès dont vous avez besoin pour la prochaine maintenance.

Surveiller les journaux après durcissement

Un serveur SSH sécurisé se surveille. Après durcissement, regardez les refus de connexion, les comptes ciblés, les adresses qui insistent et les erreurs d’authentification. Cette lecture permet de distinguer un bruit Internet normal d’un problème de configuration ou d’une tentative plus ciblée, surtout dans les premières heures qui suivent le changement.

Les journaux vous montrent aussi si une règle est trop stricte. Si un service d’automatisation ne passe plus, si un compte légitime échoue ou si une adresse d’administration est bloquée, vous le verrez vite. La preuve terrain se trouve dans les logs, pas seulement dans le fichier de configuration, parce qu’un fichier propre peut encore produire un comportement inattendu selon le réseau, le pare-feu, la distribution ou un ancien compte de service.

Sans vérification après coup, un durcissement reste une hypothèse technique, pas une mesure validée.

Automatisation, clés et comptes de service

Les comptes de service méritent une attention spéciale. Une clé utilisée par une sauvegarde, un déploiement ou une tâche CI/CD ne doit pas avoir les mêmes droits qu’un administrateur humain. Limitez la commande autorisée si c’est possible, réduisez les chemins accessibles et documentez le propriétaire du flux, car ces accès automatisés sont souvent les derniers à être supprimés quand l’architecture change et les premiers à être oubliés pendant un incident.

Évitez les clés privées stockées en clair dans des dépôts, des scripts ou des machines partagées. Une clé d’automatisation doit être remplaçable rapidement. Si personne ne sait à quoi elle sert, elle finira par rester active “au cas où”, ce qui est exactement le genre de dette qui fragilise SSH.

Deux contextes à distinguer

Le même serveur SSH peut servir des humains et des automatisations, mais les règles ne doivent pas être identiques.

Accès administrateur

Compte nominatif, clé personnelle, sudo contrôlé et journalisation lisible.

Compte de service

Droits minimaux, usage documenté, clé révocable et périmètre limité.

Checklist avant de fermer les accès faibles

Le durcissement final peut désactiver les mots de passe, restreindre root, limiter les utilisateurs et filtrer les IP. Mais ces décisions doivent être prises dans un ordre maîtrisé. Si vous fermez tout en même temps, vous ne saurez pas quelle règle a cassé l’accès.

La configuration de base recommandée

Une base saine combine plusieurs couches modestes : clés publiques, root direct limité, comptes autorisés, essais réduits, pare-feu, logs surveillés et sauvegarde de configuration. Aucun réglage isolé ne suffit. C’est leur accumulation qui rend une attaque automatisée moins efficace et une erreur humaine plus facile à récupérer.

Gardez le fichier lisible. Commentez vos choix importants, surtout le port, les groupes autorisés et les exceptions temporaires. Dans six mois, la documentation locale vous fera gagner plus de temps qu’une configuration sophistiquée mais incompréhensible.

Les erreurs qui fragilisent SSH

La première erreur consiste à durcir un serveur en production comme un exercice de laboratoire. Sur une machine distante, une directive mal comprise peut bloquer l’équipe, couper une sauvegarde ou empêcher un prestataire d’intervenir. Avant chaque changement, demandez-vous quel accès reste disponible si la nouvelle règle refuse votre connexion.

La deuxième erreur est de confondre durcissement et accumulation de paramètres. Une configuration longue, copiée depuis plusieurs tutoriels, peut être moins sûre qu’un fichier court et maîtrisé. Certaines directives deviennent obsolètes, d’autres dépendent de la version OpenSSH ou de la distribution. Le fichier réellement chargé doit rester votre référence, pas un modèle générique trouvé ailleurs, surtout si le serveur a déjà connu plusieurs administrateurs ou migrations et contient des exceptions historiques.

La troisième erreur est d’oublier les accès qui ne servent presque jamais. Anciennes clés d’un freelance, compte de déploiement inutilisé, port ouvert pour un test, groupe temporaire laissé actif : ce sont rarement les réglages spectaculaires qui posent problème. Ce sont les exceptions oubliées.

• À retirer : les comptes sans propriétaire clair.
• À revoir : les clés publiques anciennes ou partagées.
• À fermer : les ports ouverts pour un dépannage ponctuel.
• À documenter : les exceptions nécessaires aux sauvegardes et déploiements.

OpenSSH est robuste quand il reste contrôlé. Le bon durcissement ne cherche pas l’exotisme : il protège l’accès réel, limite les comptes, vérifie avant reload et surveille après changement. C’est cette discipline qui transforme SSH en outil fiable plutôt qu’en point faible permanent.