Quand on parle de sécurité WordPress, on pense souvent à la partie applicative: mises à jour, durcissement du thème et des plugins, gestion des droits, sauvegardes. Pourtant, il existe une autre porte d’entrée qui, si elle est mal protégée, peut transformer un site “correct” en cible sérieuse: l’accès SSH au serveur.
SSH n’est pas un risque en soi. C’est un outil d’administration, utile, parfois indispensable. Le problème vient presque toujours du même scénario: un accès trop ouvert, trop facile à deviner, ou exposé inutilement. Et une fois qu’un attaquant a la main via SSH, le reste devient souvent une question de temps.
Je vous propose une approche pragmatique, pensée pour des environnements WordPress réels: une méthode pour réduire la surface d’attaque, limiter les tentatives, éviter certaines erreurs courantes, et garder un équilibre acceptable entre sécurité et exploitation.
Comprendre ce que “sécuriser SSH” signifie vraiment
Sécuriser SSH, ce n’est pas simplement changer un mot de passe ou ajouter une règle de pare-feu. C’est un ensemble cohérent de décisions:
- réduire la probabilité qu’un attaquant “tombe” sur un accès valide, réduire l’impact si une identité est compromise, limiter ce que l’accès permet de faire, surveiller pour détecter rapidement ce qui sort du normal.
Sur un serveur qui héberge WordPress, SSH sert souvent à mettre à jour, redémarrer des services, corriger des permissions, gérer des logs, et intervenir sur la base de données via des commandes. Autrement dit, l’accès SSH peut être utilisé pour exécuter des actions qui dépassent largement l’application WordPress elle-même.
C’est pour cela que la sécurité WordPress commence aussi côté système. Sans SSH maîtrisé, la protection “WordPress” peut devenir un vernis.
Le premier levier: limiter l’exposition réseau
La plupart des serveurs WordPress exposent SSH à Internet uniquement parce que c’est pratique. Pratique ne veut pas dire nécessaire. Si votre architecture le permet, l’objectif est clair: ne pas exposer SSH partout, à tout moment.
Si vous avez le contrôle de la couche réseau (pare-feu, security group cloud, règles du fournisseur), commencez par vérifier deux choses simples:
1) SSH est-il accessible depuis des adresses dont vous avez le contrôle (vos IP fixes, un bastion, un VPN) ?
2) Sinon, pouvez-vous le restreindre sans casser l’exploitation ?Dans beaucoup de cas, la meilleure décision est de ne laisser SSH accessible qu’à un réseau d’administration, via VPN ou via un bastion. Ce n’est pas “élégant”, mais c’est efficace. Et c’est souvent moins coûteux en incidents qu’une stratégie basée uniquement sur des protections applicatives.
Si vous ne pouvez pas restreindre l’accès, vous pouvez au moins réduire le bruit. Par exemple, placer SSH derrière des règles filtrantes qui empêchent les pays ou plages d’IP non pertinentes peut aider. Attention à ne pas vous piéger vous-même en cas de mobilité ou de changement d’IP chez l’équipe. Dans l’administration, la continuité d’accès compte autant que le contrôle.
Identifiants: privilégier les clés, et limiter la portée des comptes
Le point le plus visible, mais aussi celui qui est le plus souvent mal fait, concerne l’authentification.
Si votre configuration SSH accepte encore des mots de passe, et en plus depuis Internet, vous augmentez fortement le risque. Les attaques par brute force et par listes de mots de passe ont perdu en “taux de réussite” par rapport à certains achats de botnets anciens, mais elles restent réalistes. Elles combinent souvent plusieurs angles: volume, distribution de tentatives, et variété de comptes.
Passer sur des clés SSH change la donne. Une clé bien protégée, avec une phrase de passe, est bien plus résistante. Et surtout, vous pouvez retirer proprement les mots de passe, ce qui supprime une classe d’attaques.
Ensuite, regardez vos comptes système.
Sur un serveur WordPress, on voit parfois des habitudes dangereuses: se connecter en tant que root par commodité, ou utiliser un même compte pour tout le monde. Le résultat n’est pas seulement un risque. C’est aussi un problème d’audit. Quand tout le monde partage le même identifiant, les journaux deviennent moins exploitables.
Une approche saine consiste à:
- utiliser un compte utilisateur dédié pour chaque admin ou chaque équipe, limiter les actions sensibles via sudo selon des règles strictes, maintenir une séparation claire entre l’accès au système et l’exploitation WordPress.
Cela réduit la portée d’une compromission. Si une clé est volée, la question devient: que peut faire la session, concrètement, sans escalade?
Désactiver la connexion root, mais sans casser vos automatismes
Le réflexe “ne jamais se connecter en root” a une raison pratique: si vous vous connectez en root, toute faiblesse d’identité devient immédiatement catastrophe. La plupart des serveurs modernes permettent une connexion utilisateur puis une élévation via sudo.
Dans la pratique, désactiver la connexion root dans SSH (via la configuration) est presque toujours une bonne idée. Le piège arrive quand il existe des scripts, des automatisations, ou des cron distants qui se connectent en root. On croit sécuriser, puis on découvre au moment critique que “ça ne fonctionne plus”.
Avant de changer quoi que ce soit, vérifiez:
- quels scripts s’authentifient sur SSH, quels outils (déploiement, monitoring, tâches d’infrastructure) utilisent root, si vous avez des “sauvegardes” et des procédures d’accès d’urgence.
Ce n’est pas un détail. Une panne d’accès peut vous mettre en situation où vous finissez par rouvrir trop vite des portes pour rétablir le service.
Réduire les tentatives: rate limiting et délais
Même avec des clés SSH, garder le contrôle des tentatives compte. Et même si vous désactivez totalement les mots de passe, la configuration d’accueil doit rester robuste face au bruit réseau.
Des mécanismes de limitation de tentatives côté serveur (via l’outil de gestion du firewall ou via des options SSH) peuvent réduire fortement l’impact de tentatives répétées. Certaines distributions proposent des modules ou intégrations, par exemple avec fail2ban pour bannir temporairement une IP après un certain nombre d’échecs. L’idée n’est pas de “tout bannir”, mais de rendre les attaques coûteuses et lentes.
Le point délicat, c’est l’ergonomie opérationnelle: si vous bannez trop agressivement, vous risquez de bloquer un admin en cas de réseau instable, ou d’ouvrir la porte à des faux positifs lors de changements IP (VPN, télétravail, NAT).
Mon conseil est simple: commencez avec des seuils raisonnables, observez les journaux, puis ajustez. Dans l’exploitation, on “cale” souvent ce paramètre plutôt que de le viser parfait du premier coup.
Le bon niveau de verrouillage SSH: configration prudente
La configuration SSH est un terrain où l’on peut améliorer beaucoup de choses, mais où on peut aussi rendre le service inutilisable si on pousse trop loin. L’objectif est de trouver le compromis qui vous protège sans vous enfermer.
Par exemple, autoriser uniquement certains algorithmes cryptographiques et désactiver ceux considérés faibles est utile. Mais selon votre infrastructure, certains clients anciens peuvent ne plus se connecter. Dans un environnement moderne, ce risque est souvent faible. Dans une organisation hétérogène, il existe.
Pareil pour l’activation ou la désactivation de features: les options doivent être cohérentes avec vos usages (tunnels, forwarding, scripts de déploiement).
Voici quelques axes de durcissement typiques, à adapter à votre environnement.
Paramètres utiles à considérer
- Désactiver l’authentification par mot de passe et forcer l’usage des clés. Désactiver l’accès direct root. Limiter l’accès à certains utilisateurs ou groupes. Restreindre le forwarding si vous n’en avez pas besoin. Configurer des limites de tentatives et délais (pour réduire la pression brute force).
Ces points peuvent se traduire par des options dans sshd_config, et parfois par des réglages additionnels au niveau du firewall ou du service d’infrastructure. Le détail exact dépend de la distribution (Debian, Ubuntu, CentOS, etc.) Et de la version OpenSSH.
Si vous https://gardewp.fr/securite-wordpress/ voulez un repère concret, une pratique très utile consiste à “durer un changement” en deux étapes: vous déployez d’abord une configuration qui améliore sans bloquer l’accès (par exemple, forcer les clés mais garder temporairement un plan de secours), puis vous durcissez ensuite quand vous êtes sûr que tout le monde peut se connecter.
Plan de secours: l’endroit où la sécurité rencontre la réalité
Les incidents SSH ne viennent pas seulement d’attaques. Ils viennent aussi d’erreurs de configuration, de mises à jour, de clés supprimées par accident, de permissions de répertoire qui changent, ou de mauvais mapping de comptes.
Un plan de secours évite de transformer une petite erreur en grosse crise. Concrètement, il peut s’agir de:
- une deuxième session d’accès maintenue pendant que vous testez la nouvelle config, un accès console via le panneau du fournisseur (si votre hébergement le permet), une procédure de récupération écrite à l’avance, pas juste “dans la tête” de quelqu’un, un compte d’urgence avec droits adaptés et une clé conservée en lieu sûr.
Ce plan n’a pas besoin d’être compliqué, mais il doit être testé. Un plan qui n’a jamais été testé est un scénario, pas une sécurité.
Limiter ce que SSH permet: droits, permissions et sudo
Même avec une bonne authentification, le risque reste entier si les comptes ont des droits excessifs.
Sur un serveur WordPress, un compte SSH peut servir à faire des actions comme:
- modifier fichiers applicatifs, changer des permissions, redémarrer services web, interagir avec la base via outils de ligne de commande, lire des fichiers de configuration qui contiennent des secrets.
Vous ne pouvez pas empêcher l’accès aux secrets si les outils nécessaires reposent sur des fichiers lisibles depuis le compte. Mais vous pouvez limiter les actions inutiles.
Sur beaucoup d’hébergements, WordPress tourne sous un utilisateur dédié (souvent www-data, nginx, ou un utilisateur applicatif). Les admins SSH n’ont pas besoin d’être cet utilisateur, sauf dans des scénarios spécifiques. Ils peuvent administrer via sudo avec des commandes autorisées.
Cette séparation aide beaucoup lors d’un incident. Si une clé est compromise, l’attaquant ne devrait pas pouvoir exécuter n’importe quelle commande système.
Le piège fréquent ici est le “sudo wildcard”. Un sudoers trop permissif annule tout l’intérêt. Et pire, il rend la journalisation moins claire.
Surveiller les journaux: repérer avant d’être “en retard”
SSH produit des événements. La clé, c’est de les utiliser.
Sans surveillance, vous découvrez les tentatives trop tard, souvent au moment où l’intégrité du serveur a déjà bougé. Le bon réflexe consiste à vérifier régulièrement:
- les échecs d’authentification, les tentatives vers des utilisateurs non autorisés, les pics d’activité, les connexions réussies à des heures anormales.
À titre d’exemple, j’ai déjà vu un cas où la désactivation des mots de passe avait été faite, mais où des clés inconnues tentaient encore des logins. Les logs montraient des erreurs répétées sur un utilisateur “obscur”. L’équipe pensait que “SSH est sécurisé car plus de mot de passe”. Pourtant, le problème n’était pas le mot de passe, c’était la posture globale (clé déposée ou fichier de configuration partagé). Un simple examen des journaux a permis de corriger avant qu’un accès ne réussisse.
La surveillance n’est pas seulement “ouvrir un fichier”. C’est aussi définir une routine: quand regarder, quoi noter, comment réagir.
Interdire l’accès inutilisé aux services voisins
Un serveur WordPress peut exposer d’autres services, parfois par défaut (panel, base de données, interfaces d’administration, FTP, etc.). Sécuriser SSH ne remplace pas la réduction globale de surface.
Le scénario typique: SSH est mieux protégé, mais l’attaquant trouve une autre entrée plus faible, puis utilise SSH pour naviguer à l’intérieur. Si vous avez d’autres points exposés, verrouillez-les aussi, sinon vous gagnerez de la sécurité sur un axe, tout en laissant une brèche ailleurs.
Je le dis sans dramatiser: sur des environnements gérés “à l’arrache”, on trouve souvent des ports oubliés. Une vérification périodique des services exposés aide à garder une vision honnête de l’attaque possible.
Cas particulier WordPress: ne confondez pas SSH et accès applicatif
WordPress peut être administré via l’interface web, via des API, via des scripts de déploiement, et via des plugins. La sécurité WordPress dépend de ces couches. Mais SSH concerne surtout la couche système.
Cela implique une conséquence importante: sécuriser SSH ne remplace pas la gestion des comptes WordPress.
Si un attaquant obtient SSH, il peut potentiellement modifier des fichiers WordPress, insérer du code, ou extraire des secrets de configuration, ce qui peut ensuite mener à des accès WordPress persistants. À l’inverse, si vous sécurisez WordPress mais laissez SSH trop ouvert, vous donnez une voie d’accès plus directe, souvent plus simple pour un attaquant motivé.
Donc la meilleure posture est une défense en profondeur, pas une “solution unique”.
Vérifications rapides avant de toucher à SSH
Quand on applique des changements sur SSH, l’erreur la plus coûteuse, c’est de déployer une config sans valider l’accès de manière contrôlée.
Voici une petite routine de vérification, utile avant toute modification. Elle ne remplace pas un examen complet, mais elle évite les “gros incidents” fréquents.
- Valider vos IP d’administration, et idéalement restreindre SSH au réseau/VPN si possible. Confirmer que vous pouvez vous reconnecter après changement, en gardant une session ouverte pendant les tests. Désactiver l’accès root uniquement si vos scripts et automatisations n’en ont pas besoin. Forcer l’usage des clés et préparer une clé de secours conservée en lieu sûr. Surveiller les logs d’authentification après déploiement, jusqu’à stabilisation.
Edge cases qui surprennent (et comment les gérer)
Certains cas reviennent souvent sur les serveurs WordPress, surtout quand il y a de la maintenance externalisée ou des équipes qui changent.
Premier cas: les clients SSH intégrés dans des outils. Certaines plateformes d’automatisation, ou certains scripts de déploiement, utilisent des options spécifiques, comme le forwarding ou des algorithmes particuliers. Si vous durcissez trop vite, vous cassez la CI/CD. Le remède est d’identifier ces clients avant de durcir, puis de tester sur un environnement proche.
Deuxième cas: les permissions sur les répertoires et fichiers de clés. Les erreurs de type “permission denied” côté SSH viennent parfois de changements système indépendants de votre volonté. J’ai déjà vu une rotation de clés accompagnée d’une modification de propriétaires sur /home/.../.ssh, ce qui a bloqué des accès. La sécurité est fragile quand elle dépend de conventions implicites. Documenter les attentes de permissions réduit ces incidents.
Troisième cas: des règles de firewall trop strictes qui bloquent le déploiement en pleine fenêtre de maintenance. La solution n’est pas “relâcher”. La solution, c’est planifier une procédure d’accès temporaire, idéalement encadrée, et documentée.
Quatrième cas: la tentation de “désactiver SSH partout” sur un serveur qui en a besoin. Si vos équipes ne peuvent administrer que via SSH, le remplacer par une autre voie sans alternative solide revient à créer une dette. Parfois, le meilleur compromis est de garder SSH mais de le fermer au réseau, et de le rendre difficile à attaquer plutôt que de l’effacer.
Maintenir la sécurité dans le temps
Sécuriser SSH une fois ne suffit pas. WordPress évolue, la configuration système aussi, les fournisseurs migrent, et les équipes changent.
Un bon entretien ressemble à ceci, sans devenir lourd:
- Revoir régulièrement les règles d’accès réseau. Vérifier les comptes système autorisés à se connecter. Contrôler que l’authentification par mot de passe est bien désactivée (ou strictement encadrée). Suivre les mises à jour OpenSSH de votre distribution. Consulter les journaux d’authentification, même quand “il ne se passe rien”.
Cette routine est moins visible qu’une “mesure choc”, mais elle réduit la dérive silencieuse. Et la dérive silencieuse, c’est souvent là que les incidents commencent.
Ce que j’éviterais, même si c’est tentant
Pour rester concret, voici quelques erreurs typiques que j’ai vues, et qui aggravent plus qu’elles n’améliorent.
Retirer l’accès SSH de façon brutale sans plan de récupération, puis rouvrir en urgence avec une configuration plus faible. C’est exactement le moment où on fait les concessions les moins réfléchies.
Changer uniquement le mot de passe sans vérifier la configuration d’authentification. Si les mécanismes de brute force restent possibles, le mot de passe devient un détail.
Multiplier les comptes et réutiliser des clés entre personnes. La sécurité diminue parce que l’audit devient presque inutile. Si tout le monde a la même clé, vous ne saurez pas qui a fait quoi.
Oublier de tester la configuration après déploiement. Une petite erreur de paramètre peut suffire à vous mettre à l’arrêt. Et quand vous êtes à l’arrêt, vous ouvrez souvent des portes pour sortir du problème.
Synthèse opérationnelle pour une sécurité WordPress solide
Pour résumer sans faire de slogan, sécuriser l’accès SSH sur un serveur WordPress, c’est mettre une couche fiable entre Internet et votre système. Le plus rentable, en général, reste la combinaison:
- accès réseau restreint (VPN ou IP d’administration quand c’est possible), authentification par clés plutôt que par mots de passe, suppression de l’accès root direct, limitation de ce que les comptes peuvent faire, surveillance des journaux et ajustements raisonnés.
Cette approche renforce la sécurité WordPress parce qu’elle protège ce qui se cache sous l’application. Tant que SSH reste sous contrôle, les autres mesures (WordPress, plugins, mises à jour, durcissement applicatif) gagnent en efficacité, car vous ne donnez pas une voie d’accès secondaire facile.
Si vous me décrivez votre configuration (hébergement, système, méthode d’accès actuelle, usage de sudo, présence de VPN ou bastion, et si vous utilisez des clés), je peux proposer un durcissement SSH plus ciblé, avec les compromis à anticiper.