SSH en 2026 : durcir l’accès sans se compliquer la vie

Sur un serveur Linux exposé à Internet, SSH reste presque toujours l’un des premiers services visés. C’est logique : il donne un accès d’administration à distance, il est souvent ouvert en permanence, et il est simple à scanner automatiquement. La bonne nouvelle, c’est qu’il n’est pas nécessaire d’empiler des couches complexes pour améliorer nettement la sécurité. Quelques réglages bien choisis suffisent souvent à réduire fortement le risque, sans rendre l’exploitation pénible.

Dans cet article, l’objectif est volontairement pragmatique : durcir SSH avec des mesures simples, réversibles et faciles à maintenir. On va se concentrer sur ce qui compte vraiment en production : l’authentification par clé, la gestion de l’accès root, quelques options utiles dans sshd_config, l’intérêt réel d’un changement de port, l’usage de Fail2ban, et surtout la vérification avant de se couper l’accès.

Pourquoi SSH reste la première porte d’entrée à protéger

SSH est le point d’entrée naturel pour l’administration distante sur Linux. Sur un VPS, un serveur dédié, une VM cloud ou une machine hébergée en interne avec exposition réseau, le service écoute souvent sur le port 22/TCP. Cela le rend immédiatement visible par des robots qui balayent Internet à la recherche d’hôtes accessibles.

En pratique, les attaques les plus fréquentes ne sont pas sophistiquées : il s’agit surtout de tentatives massives d’authentification, de réutilisation de mots de passe faibles, ou d’essais sur des comptes classiques comme root, admin, ubuntu ou debian. Si l’authentification par mot de passe reste active sans protection complémentaire, le risque augmente vite.

Le bon réflexe n’est donc pas de chercher la configuration “parfaite” sur le papier, mais de mettre en place un socle de sécurité minimal, robuste et compréhensible. Sur un serveur standard, ce socle repose généralement sur quatre idées :

utiliser des clés SSH au lieu des mots de passe ;
réduire les comptes autorisés à se connecter ;
désactiver ou limiter l’accès direct de root ;
surveiller les journaux et bloquer les abus évidents.

Cette approche a un avantage important : elle reste compatible avec les usages quotidiens. Pas besoin d’infrastructure lourde, ni d’outils exotiques. OpenSSH est déjà présent sur la plupart des distributions, et des services comme Fail2ban ou journalctl s’intègrent naturellement dans un environnement Linux moderne.

Le socle de départ : mettre à jour, identifier le service et sauvegarder la configuration

Avant de modifier SSH, commencez par vérifier l’environnement réel du serveur. Selon la distribution, le service peut s’appeler ssh ou sshd. Sur Debian et Ubuntu, on rencontre souvent ssh. Sur d’autres systèmes, sshd est plus courant.

Pour identifier le service actif :

systemctl status ssh
ou
systemctl status sshd

Il faut aussi localiser le fichier principal de configuration. Dans la grande majorité des cas, il s’agit de /etc/ssh/sshd_config. Certaines distributions utilisent également un répertoire d’inclusions, par exemple /etc/ssh/sshd_config.d/. C’est souvent préférable pour garder une configuration claire et limiter les conflits lors des mises à jour.

Avant tout changement, faites une copie de sauvegarde :

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Et surtout, ne fermez jamais votre session SSH actuelle pendant les tests. C’est une règle simple, mais essentielle. Ouvrez une deuxième session pour valider les changements. Si la nouvelle configuration pose problème, vous pourrez revenir en arrière depuis la première session encore ouverte.

Enfin, assurez-vous que le système est à jour avec le gestionnaire de paquets de votre distribution. OpenSSH évolue régulièrement, et les distributions maintenues publient des correctifs de sécurité via leurs canaux habituels. Il est plus utile d’appliquer ces mises à jour que de multiplier des réglages défensifs secondaires.

Les réglages essentiels de sshd à appliquer sans casser l’accès

Le fichier sshd_config contient beaucoup d’options, mais peu sont réellement indispensables dans une stratégie de durcissement simple. Mieux vaut quelques directives bien comprises qu’une longue liste copiée sans contexte.

Désactiver l’authentification par mot de passe quand les clés sont prêtes

Si tous les comptes d’administration utilisent déjà des clés SSH valides, la mesure la plus efficace consiste à désactiver les mots de passe pour SSH :

PasswordAuthentication no

C’est l’un des changements qui réduisent le plus fortement les attaques opportunistes. En revanche, ne l’activez pas tant que vous n’avez pas testé une connexion par clé avec un compte non root autorisé.

Selon le contexte, vous pouvez aussi vérifier l’authentification interactive PAM si vous souhaitez un verrouillage plus strict, mais cela dépend de la distribution et de l’intégration locale. Si vous n’êtes pas certain de l’impact, mieux vaut ne pas toucher à plusieurs paramètres d’authentification en même temps.

Limiter les utilisateurs autorisés

Sur un serveur simple, il est souvent utile de préciser quels comptes peuvent se connecter en SSH :

AllowUsers julien deploy

Cette directive évite qu’un compte système ou un utilisateur oublié puisse être utilisé pour une connexion distante. C’est particulièrement utile sur des serveurs où plusieurs comptes existent pour des services, des scripts ou des usages applicatifs.

Si vous gérez l’accès par groupe, AllowGroups peut être plus pratique. L’idée reste la même : réduire la surface d’accès.

Réduire certaines possibilités inutiles

Selon l’usage du serveur, plusieurs options peuvent être désactivées pour limiter les fonctionnalités non nécessaires :

X11Forwarding no si vous n’utilisez pas de transfert X11 ;
PermitEmptyPasswords no pour interdire explicitement les mots de passe vides ;
MaxAuthTries pour limiter le nombre d’essais par connexion ;
LoginGraceTime pour réduire le temps accordé avant authentification.

Il faut rester mesuré. Par exemple, réduire trop agressivement certains délais peut gêner des usages légitimes sur des connexions lentes ou avec des agents SSH chargés de nombreuses clés. Le but n’est pas de rendre SSH capricieux, mais de supprimer l’inutile.

Clés SSH : la mesure la plus rentable en sécurité

Si vous ne deviez retenir qu’une seule amélioration, ce serait celle-ci : passer aux clés SSH. Une authentification par clé correctement déployée est à la fois plus sûre et plus confortable qu’un mot de passe saisi à chaque connexion.

Avec OpenSSH, la commande la plus courante pour générer une clé moderne est :

ssh-keygen -t ed25519

Le type ed25519 est largement recommandé dans les usages actuels pour sa simplicité et ses bonnes propriétés de sécurité. La commande crée en général une clé privée dans ~/.ssh/ et une clé publique associée. La clé publique doit être copiée sur le serveur dans ~/.ssh/authorized_keys du compte concerné.

Pour simplifier le déploiement, ssh-copy-id est très pratique lorsqu’il est disponible :

ssh-copy-id utilisateur@serveur

Quelques bonnes pratiques concrètes méritent d’être rappelées :

protéger la clé privée avec une phrase de passe si possible ;
ne jamais copier une clé privée sur le serveur ;
utiliser un compte nominatif plutôt qu’un compte partagé ;
supprimer les clés obsolètes dans authorized_keys ;
documenter à qui appartient chaque clé.

Dans une petite équipe, on voit souvent des fichiers authorized_keys s’accumuler au fil des années. Ce n’est pas un détail. Une clé oubliée d’un ancien poste ou d’un ancien prestataire reste un accès potentiel tant qu’elle n’est pas retirée.

Si vous utilisez déjà un agent SSH local, l’expérience reste fluide au quotidien. Vous gagnez en sécurité sans ajouter de friction inutile, ce qui correspond exactement à une politique de durcissement réaliste.

Faut-il interdire l’accès root en SSH ?

Dans la plupart des cas, oui, il est préférable d’éviter la connexion directe de root. La directive courante est :

PermitRootLogin no

L’idée est simple : on se connecte avec un compte utilisateur nominatif, puis on élève les privilèges avec sudo si nécessaire. Cela améliore la traçabilité et réduit l’exposition du compte le plus sensible du système.

Sur certaines machines, notamment lors d’un provisioning initial ou dans des contextes d’hébergement spécifiques, l’accès root par clé peut être temporairement utilisé. Si c’est votre cas, il faut au minimum éviter l’authentification root par mot de passe et prévoir une bascule rapide vers un compte d’administration standard avec sudo.

En production, cette organisation apporte plusieurs bénéfices concrets :

les actions d’administration sont rattachées à un utilisateur identifiable ;
les journaux sont plus lisibles ;
la suppression d’un accès est plus simple quand une personne quitte l’équipe ;
on évite de banaliser l’usage direct de root.

Si vous devez conserver un accès d’urgence, faites-le de manière documentée et contrôlée, pas comme une habitude permanente.

Changer le port SSH : utile, mais à remettre à sa juste place

Le changement de port SSH fait partie des recommandations les plus connues. Concrètement, il consiste à remplacer le port 22 par un autre port TCP avec la directive :

Port 2222

Ce n’est pas une protection forte à lui seul. Un scan complet détectera rapidement le nouveau port. En revanche, ce changement peut réduire une partie du bruit automatisé qui cible uniquement le port 22. Résultat : moins de tentatives triviales dans les journaux, parfois moins de charge parasite, et une lecture plus propre des événements.

Il faut donc voir ce réglage comme une mesure de réduction du bruit, pas comme un mécanisme de sécurité principal. Si vous gardez les mots de passe actifs et un compte root accessible, changer de port ne règlera pas le problème de fond.

Si vous modifiez le port :

ouvrez le nouveau port dans le pare-feu avant de recharger SSH ;
mettez à jour les règles de sécurité réseau côté cloud ou hébergeur si nécessaire ;
testez la connexion sur le nouveau port dans une seconde session ;
adaptez aussi la configuration de Fail2ban si elle dépend du service surveillé.

Sur un serveur protégé par ufw, nftables ou des règles spécifiques chez un fournisseur cloud, oublier ce point est une manière classique de se bloquer soi-même.

Fail2ban : une protection utile contre les abus répétitifs

Fail2ban surveille les journaux et bannit temporairement des adresses IP après un certain nombre d’échecs. Ce n’est pas un remplacement d’une bonne authentification, mais c’est un complément pratique, surtout si vous laissez encore le mot de passe actif pendant une phase de transition.

Le principe est simple : un filtre repère des échecs de connexion dans les logs SSH, puis une action applique un bannissement via le pare-feu. Selon la distribution et la version installée, la configuration peut s’appuyer sur iptables, nftables ou d’autres mécanismes compatibles.

Pour SSH, la “jail” par défaut est souvent suffisante après adaptation de quelques paramètres :

le nombre maximal d’échecs avant bannissement ;
la durée du bannissement ;
la fenêtre temporelle d’observation ;
la liste d’IP à ne jamais bannir, par exemple un bastion ou une adresse d’administration fixe.

En production, deux erreurs sont fréquentes :

configurer des seuils trop agressifs et se bannir soi-même lors d’un test ou d’un changement de clé ;
penser que Fail2ban suffit à sécuriser un SSH encore basé sur des mots de passe faibles.

La bonne approche consiste à l’utiliser comme filet de protection, pas comme fondation. Si les clés SSH sont en place et les mots de passe désactivés, Fail2ban reste utile pour absorber le bruit et documenter les tentatives répétées, mais le risque principal est déjà mieux traité en amont.

Journaliser et vérifier ce qui se passe réellement

Durcir SSH sans regarder les journaux revient à travailler à l’aveugle. Pour comprendre les connexions, les refus, les erreurs de clé ou les tentatives répétées, il faut consulter les logs système.

Sur les distributions avec systemd, journalctl est l’outil naturel. Vous pouvez par exemple suivre les événements du service SSH en temps réel :

journalctl -u ssh -f
ou
journalctl -u sshd -f

Selon les systèmes, les événements peuvent aussi apparaître dans des fichiers comme /var/log/auth.log sur Debian et Ubuntu, ou /var/log/secure sur d’autres distributions. L’emplacement exact dépend de la pile de journalisation utilisée.

Ce qu’il faut surveiller concrètement :

les échecs d’authentification répétés ;
les connexions réussies depuis des IP inhabituelles ;
les erreurs liées aux permissions de .ssh ou de authorized_keys ;
les refus provoqués par une directive trop restrictive dans sshd_config ;
les bannissements et dé-bannissements Fail2ban.

Cette lecture a une valeur très pratique. Par exemple, si une clé publique semble correcte mais que l’accès échoue, les journaux indiquent souvent si le problème vient d’un fichier mal placé, de droits trop ouverts, d’un utilisateur non autorisé par AllowUsers, ou d’un mode d’authentification désactivé.

Pour aller plus loin, vous pouvez aussi consulter la documentation officielle d’OpenSSH, notamment la page de manuel de sshd_config disponible sur OpenBSD, qui fait référence pour de nombreuses options du projet.

Tester la configuration avant rechargement : l’étape qui évite les coupures

C’est probablement l’étape la plus importante de tout le processus : tester avant d’appliquer. OpenSSH fournit un moyen simple de vérifier la syntaxe de la configuration :

sshd -t

Si la commande ne renvoie pas d’erreur, la syntaxe est en principe valide. Cela ne garantit pas que votre politique d’accès est correcte, mais cela évite déjà les fautes de configuration les plus évidentes.

Ensuite, rechargez le service plutôt que de redémarrer brutalement quand c’est possible :

systemctl reload ssh
ou
systemctl reload sshd

Puis testez immédiatement dans une nouvelle session :

connexion avec le compte utilisateur prévu ;
authentification par clé ;
usage du bon port si vous l’avez modifié ;
élévation via sudo si root direct est désactivé.

Si vous administrez un serveur distant critique, une précaution supplémentaire consiste à disposer d’un accès de secours hors SSH quand c’est possible : console chez l’hébergeur, accès série, interface cloud, KVM distant. Sur un VPS, les consoles web proposées par les fournisseurs peuvent être très utiles en cas d’erreur de configuration.

Une méthode simple et sûre consiste à appliquer les changements dans cet ordre :

ajouter et tester la clé d’un compte utilisateur standard ;
vérifier sudo ;
désactiver l’accès root direct si ce n’est pas déjà fait ;
désactiver l’authentification par mot de passe ;
ajouter Fail2ban et ajuster les seuils ;
éventuellement changer le port si cela a du sens pour votre contexte.

Cet enchaînement limite les risques de verrouillage tout en gardant une progression facile à contrôler.

Une configuration minimale et cohérente pour la plupart des serveurs

Pour un serveur Linux classique administré par une petite équipe, une base de durcissement cohérente ressemble souvent à ceci :

OpenSSH à jour via les paquets de la distribution ;
connexion avec clés SSH uniquement ;
PermitRootLogin no ;
PasswordAuthentication no après validation des clés ;
AllowUsers ou AllowGroups pour limiter les comptes autorisés ;
désactivation des fonctions non utilisées comme X11Forwarding ;
surveillance des journaux avec journalctl ;
Fail2ban comme protection complémentaire ;
pare-feu correctement aligné avec le port réellement utilisé.

Ce n’est pas une “checklist magique”, mais c’est un ensemble de mesures simples, compréhensibles et efficaces dans la majorité des déploiements. Surtout, elles restent maintenables dans le temps, ce qui est souvent le vrai critère de qualité d’une configuration de sécurité.

À l’inverse, une configuration trop complexe finit souvent par être mal comprise, mal documentée, puis contournée en urgence au premier incident. En sécurité système, la sobriété bien exécutée vaut généralement mieux qu’un durcissement théorique impossible à exploiter sereinement.

Conclusion

En 2026 comme avant, sécuriser SSH ne demande pas forcément une usine à gaz. Les gains les plus nets viennent de quelques décisions simples : utiliser des clés, limiter les comptes autorisés, éviter l’accès root direct, surveiller les journaux et ajouter une protection comme Fail2ban pour absorber les tentatives répétées.

Le point clé est de procéder avec méthode : sauvegarder la configuration, tester chaque changement dans une seconde session, valider les logs, puis seulement durcir davantage. C’est cette discipline qui évite les coupures inutiles et transforme une bonne intention en configuration fiable.

Si vous voulez aller plus loin dans le même esprit, vous pouvez aussi explorer les autres guides de Prompt Bash sur Linux, systemd, les logs et l’administration serveur, pour construire un socle d’exploitation propre, utile et durable.