Configurer un accès distant SSH sécurisé pour vos serveurs

Le protocole SSH crée un canal chiffré entre un poste d’administration et un serveur, ce qui remplace les liaisons directes aux interfaces de gestion. Correctement configuré, il combine l’authentification, le chiffrement des échanges et le contrôle des commandes exécutées. Son adoption reste toutefois liée à des choix de sécurité : identité des personnes, droits accordés, périmètre réseau, traçabilité et capacité à révoquer une session.

Pour une organisation qui exploite des applications web, des intranet ou des services internes, cette mise en place doit s’intégrer aux procédures existantes. LM Gestion, société française de logiciels fondée en 1996, associe le développement d’outils comme Genedit à la maintenance technique, au conseil et à la mise à disposition de profils spécialisés. Cette expérience de terrain rappelle qu’un serveur accessible ne doit pas être administré comme un simple poste de travail : il exige une politique cohérente, testée et suivie dans le temps.

Cartographier les accès et réduire leur périmètre

Avant toute ouverture, un inventaire distingue les serveurs réellement administrés à distance de ceux qui ne le sont pas. Pour chaque machine, il faut recenser le responsable, les comptes autorisés, les applications hébergées, les contraintes de disponibilité et le plan de reprise. Cette cartographie évite de créer des accès génériques, puis de les oublier après une migration, un changement d’équipe ou le départ d’un administrateur.

Le périmètre réseau doit également être explicite. L’administration peut transiter par un VPN, un hôte bastion ou une plateforme d’accès centralisée, selon le niveau de criticité et la taille de l’infrastructure. Un pare-feu peut alors n’accepter le trafic SSH que depuis le réseau d’administration ou des adresses autorisées. La passerelle elle-même peut exiger une authentification à plusieurs facteurs, sans remplacer la validation de la clé SSH. Les interfaces de gestion des autres serveurs ne sont plus exposées directement à Internet.

Les postes utilisés pour ces connexions méritent la même attention que les serveurs. Les clés privées restent sur un matériel protégé, avec un profil utilisateur distinct et une politique empêchant leur usage pour des tâches sans rapport. Sur un poste d’administration, la consultation de contenus tiers doit rester séparée de la session de gestion : des pages de casino comme cette ressource promotionnelle n’ont aucune raison d’être ouvertes depuis l’environnement contenant les secrets d’accès. Cette séparation réduit l’exposition sans remplacer les contrôles SSH.

Renforcer l’authentification avec des clés SSH

La méthode la plus solide repose sur une paire de clés asymétriques par identité : une clé privée conservée par son titulaire, une clé publique déposée sur les serveurs autorisés. L’algorithme Ed25519 constitue un bon choix pour les environnements actuels. La génération se fait avec une phrase de passe forte, par exemple via ssh-keygen -t ed25519 -a 100 -C "cle-administration-web". Une clé distincte par personne évite de deviner quel collaborateur dispose du même secret.

La phrase de passe protège la clé si le fichier est volé, mais ne dispense pas de son chiffrement sur le poste. Pour les tâches répétitives, un agent SSH peut déverrouiller une clé en mémoire sans que celle-ci soit enregistrée en clair. Un jeton matériel compatible SSH apporte une protection supplémentaire contre la simple copie du fichier. Pour l’automatisation, les certificats à durée courte et les secrets gérés dans un coffre dédié limitent la circulation des clés à longue durée de vie.

Sur le serveur, sshd_config désactive l’authentification par mot de passe et l’accès direct de root, tout en autorisant un groupe dédié. Sur une version récente d’OpenSSH, le socle peut ressembler à ceci :

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowGroups ssh-admins
X11Forwarding no
AllowAgentForwarding no

Ces directives doivent être confrontées aux besoins réels : un accès SSH valide peut être nécessaire à la supervision, mais la redirection X11 ou le transfert d’agent sont rarement justifiés. Avant de recharger le service, l’administrateur valide la configuration avec sshd -t et conserve une seconde session ouverte. Les entrées known_hosts ne sont ajoutées qu’après contrôle de l’empreinte du serveur sur un canal fiable, jamais automatiquement.

Limiter les droits et isoler les applications

Une authentification solide ne donne pas automatiquement le droit d’exécuter n’importe quelle commande. Chaque personne reçoit un compte nominatif, associé au strict minimum nécessaire. Les privilèges supplémentaires sont délégués avec sudo pour des actions précises, dans un cadre journalisé. Les comptes de service, souvent partagés entre outils, sont à éviter pour l’interactivité : un incident doit pouvoir être rattaché à une identité précise.

L’isolement complète ces restrictions. Les tâches à risque peuvent s’exécuter dans un conteneur ou une machine dédiée, avec ses propres limites de ressources et un système de fichiers distinct. Pour les transferts SFTP, un compte sans shell réduit la surface d’attaque. Les tunnels restent désactivés par défaut ou limités à des destinations autorisées, car ils peuvent contourner les séparations prévues entre les zones.

La gouvernance doit associer ces règles à un cycle de vie. Une revue trimestrielle vérifie les comptes actifs, les groupes SSH, les accès d’urgence et les correspondances avec l’inventaire. Le cadrage peut s’appuyer sur le recrutement d’un chef de projet technique, à condition d’intégrer les contrôles d’accès et la reprise d’activité aux critères d’acceptation. Les procédures décrivent qui accorde une exception, qui la contrôle et pendant combien de temps elle demeure valide.

Filtrer le réseau et surveiller les connexions

Le filtrage réseau réduit la surface d’exposition. Si les serveurs ne sont administrés que par une équipe interne, l’accès traverse une passerelle centralisée, avec authentification et journalisation propres. Les règles du pare-feu limitent les sources autorisées à l’adresse IP du bastion et aux réseaux de gestion. Modifier le port d’écoute peut compliquer les scans automatiques, mais ne constitue pas une protection suffisante : il faut surtout empêcher les connexions non légitimes.

La détection des échecs complète le dispositif. Un mécanisme comme fail2ban peut bannir temporairement une adresse après plusieurs tentatives invalides, avec des seuils adaptés pour éviter de verrouiller un agent légitime. Cette réponse automatique s’accompagne d’une journalisation complète des authentifications, des élévations sudo et des changements de configuration. Les événements sont centralisés dans un système de supervision afin d’être corrélés et conservés.

En cas d’utilisation abusive d’une clé, la réponse doit être préparée. L’administrateur révoque la clé ou désactive le compte, bloque l’adresse fautive et analyse les traces liées à la connexion. Les journaux conservés sur un serveur distinct évitent qu’un attaquant supprime ses propres indices. Une sauvegarde vérifiée ne remplace pas ces traces, mais elle permet de restaurer un service propre pendant que l’investigation se poursuit.

Tester, documenter et maintenir le service

La mise en production se fait par étapes, jamais en remplaçant tous les accès d’un coup. Un serveur pilote reçoit la nouvelle configuration, tandis que l’ancien canal demeure disponible jusqu’à la validation des authentifications, des commandes et du retour d’un niveau de service normal. Les tests incluent le comportement en cas de droits insuffisants, la reconnexion après mise à jour et l’accès depuis le site de secours. Ce protocole limite les interruptions et facilite le retour à la configuration précédente.

La continuité repose ensuite sur des opérations régulières. Les correctifs du système d’exploitation et ceux d’OpenSSH sont appliqués après tests, car une mise à jour peut modifier la syntaxe ou le comportement de l’authentification. Les clés et certificats expirent selon une politique définie, et chaque départ ou changement de fonction déclenche une révision des droits. Les sauvegardes sont testées par restauration, avec une définition claire du délai objectif de reprise et des données sauvegardées.

Des contrôles périodiques mesurent la conformité et s’appuient sur les retours du support. Cette vérification peut être transmise au support LM Gestion par un canal indépendant du serveur diagnostiqué. Les indicateurs suivis comprennent le nombre de connexions, les échecs d’authentification, les comptes privilégiés actifs et les délais de rotation. Les exercices de simulation d’incident vérifient que l’équipe sait révoquer une clé sans interrompre inutilement les opérations critiques.

Une configuration SSH fiable repose donc sur une combinaison de contrôles : identité nominative, clé protégée, droits restreints, passerelle maîtrisée et journaux exploitables. Ces éléments doivent être documentés dans des procédures courtes, associés à des responsables identifiés et vérifiés à intervalles réguliers. Ils s’intègrent aussi aux autres dispositifs de sécurité de l’organisation, notamment la gestion des secrets, la supervision et les plans de continuité.

La règle pratique à retenir est simple : un accès distant ne doit être ouvert que pour une identité précise, avec une clé contrôlée, des permissions limitées et une trace vérifiable de chaque connexion.