Ouvrir un accès SSH mal configuré, c’est comme laisser les clés du datacenter sous le paillasson : un hacker qui passe peut entrer sans forcer. Pour un prestataire de service managé - MSP, chaque port 22 mal protégé devient une porte d’entrée vers une attaque, un ransomware ou une compromission massive de clients.
Heureusement, SSH (Secure Shell) n’est pas seulement un outil de connexion pratique : bien configuré, c’est un bouclier ultra-solide qui protège vos infrastructures. Fichiers ssh_config, sshd_config, gestion des clés publiques/privées, désactivation du root login : chaque paramètre compte pour sécuriser vos accès et renforcer vos services managés.
Dans cet article, on va plonger au cœur de la configuration SSH, côté client et côté serveur, avec des exemples concrets, des bonnes pratiques de sécurité, et même une checklist prête à l’emploi. Et comme on aime les choses funky chez BeMSP, vous allez voir que SSH peut être technique… sans être barbant.
Datto RMM, c’est votre chef d’orchestre pour aligner les configurations SSH : déploiement de clés, modification de sshd_config, automatisation par scripts… le tout sans interface SSH native, mais avec une puissance d’automatisation redoutable..
À retenir
Qu’est-ce que la configuration SSH et pourquoi elle est stratégique ?
SSH, ou Secure Shell, c’est un peu comme un passeport numérique pour voyager d’un serveur à l’autre en toute sécurité. Conçu à la fin des années 90 pour remplacer des protocoles dépassés comme Telnet ou rsh (qui envoyaient tout en clair, y compris les mots de passe…), SSH repose sur un chiffrement solide et une authentification robuste.
L’intérêt ?
Chaque échange entre un administrateur et un serveur est encapsulé dans un tunnel sécurisé.
Résultat : même si un attaquant intercepte le trafic, il ne verra qu’un amas de données illisibles.
La configuration SSH, c’est l’ensemble des réglages qui déterminent comment ce tunnel fonctionne. On distingue deux volets :
- Côté client : la machine qui initie la connexion. La configuration lui permet de se connecter plus vite, de gérer plusieurs serveurs avec des alias, et de stocker les paramètres d’authentification.
- Côté serveur : la machine qui reçoit la connexion. C’est ici que l’on fixe les règles de sécurité : quels utilisateurs peuvent se connecter, avec quel type de clé, depuis quelle adresse IP, et selon quelles restrictions.
Pour un infogérant, cette configuration est stratégique à double titre :
- Elle garantit une administration fluide et rapide des environnements clients.
- Elle joue un rôle central dans la cybersécurité, car une mauvaise configuration peut transformer SSH en point d’entrée pour une attaque (brute force, exploitation de comptes root, clés faibles…).
Bref, comprendre et maîtriser la configuration SSH, c’est allier productivité et sécurité : deux piliers du métier d’infogérance.
Les fichiers de configuration SSH : client vs serveur
Comme vu plus haut, la magie de SSH repose sur deux volets complémentaires : le client (celui qui initie la connexion) et le serveur (celui qui reçoit et contrôle la connexion). Chaque côté dispose de ses propres fichiers de configuration.
Côté client
- ~/.ssh/config : fichier propre à un utilisateur, idéal pour personnaliser ses connexions.
- /etc/ssh/ssh_config : fichier global qui s’applique à tous les utilisateurs d’une machine.
Ces fichiers permettent de simplifier la vie des administrateurs : au lieu de retenir une liste interminable d’IP, de ports et de clés privées, on définit des alias lisibles et des règles adaptées à chaque serveur. Un infogérant qui gère vingt environnements clients peut ainsi écrire ssh serveur-client1 plutôt qu’une commande complexe à rallonge.
Côté serveur
- /etc/ssh/sshd_config : le fichier central qui définit les règles de sécurité du service SSH.
- /etc/ssh/sshd_config.d/ : un répertoire introduit pour organiser la configuration en plusieurs fichiers plus courts et modulaires. Cette approche évite les fichiers “usines à gaz” de plusieurs centaines de lignes, difficiles à maintenir.
L’objectif côté serveur est clair : définir précisément qui peut entrer, comment et avec quel niveau de privilège. On peut restreindre l’accès à certains utilisateurs, imposer les clés publiques, limiter les tentatives de connexion ou encore interdire l’accès direct au compte root.
💡Petit rappel utile : le service qui gère les connexions s’appelle sshd (le “d” pour daemon). C’est lui qui écoute sur le port 22 (ou un port personnalisé) et applique les règles définies dans la configuration.
Configurer le client SSH (ssh_config)
Le fichier ssh_config est un peu comme un carnet d’adresses numérique dopé aux stéroïdes. Sans lui, chaque connexion nécessite de taper une commande interminable du type : ssh admin@192.168.10.25 -p 2200 -i ~/.ssh/id_rsa
Avec un fichier de configuration bien pensé, on gagne en lisibilité et en confort.
Exemple simple :
- Host serveur-client
HostName 192.168.10.25
User admin
Port 2200
IdentityFile ~/.ssh/id_rsa
- Dès lors, une seule commande suffit : ssh serveur-client
- Gain de temps pour les MSP : quand on jongle avec plusieurs dizaines de serveurs clients, c’est la garantie de réduire les erreurs et d’accélérer les interventions.
Fonctions avancées du client SSH
Multiplexage
- Activez ControlMaster et ControlPath pour réutiliser une connexion existante en arrière-plan. Résultat : les connexions suivantes sont quasi instantanées. Parfait lorsqu’on doit exécuter plusieurs commandes successives sur un même serveur client.
ProxyJump
- Directive incontournable dans les environnements cloisonnés. Exemple : passer par un bastion pour accéder à un serveur interne d’un client.
- Host serveur-interne
- HostName 10.0.0.5
- ProxyJump bastion.example.com
ForwardAgent
Permet de relayer votre agent SSH local vers un serveur intermédiaire. Ainsi, vous pouvez rebondir de machine en machine sans copier votre clé privée partout — un must en termes de sécurité.
ServerAliveInterval
Envoie régulièrement un signal pour maintenir la connexion ouverte. Indispensable si vous travaillez derrière un firewall client qui coupe les connexions inactives.
Compression
Active la compression des données (Compression yes) pour gagner en performance, notamment sur des liaisons lentes (ex. intervention via 4G de secours).
Cas pratique pour les infogérants et MSP
Un infogérant ou un MSP gérant des dizaines de serveurs clients peut utiliser un fichier ssh_config bien structuré pour éviter les confusions et réduire drastiquement le risque d’erreur (comme se connecter au mauvais serveur avec le mauvais compte).
Configurer les paramètres essentiels de sshd_config
Côté serveur, la configuration est beaucoup plus sensible : c’est ici que se joue la sécurité. Un fichier /etc/ssh/sshd_config minimaliste pourrait ressembler à ceci :
Port 2200
Protocol 2
PermitRootLogin no
PasswordAuthentication no
AllowUsers admin support
- Changer le port : éviter le port 22 réduit les attaques automatisées de bots.
- Protocol 2 : toujours activer la version 2, plus sécurisée que la version 1 obsolète.
- PermitRootLogin no : interdire la connexion directe au compte root, pour limiter l’impact d’un piratage.
- PasswordAuthentication no : bloquer l’authentification par mot de passe et imposer les clés publiques.
- AllowUsers / AllowGroups : restreindre l’accès uniquement aux utilisateurs ou groupes autorisés.
Renforcer la sécurité SSH avec des paramètres avancés
Une fois les bases posées, il est recommandé d’aller plus loin pour renforcer la défense :
- Bannière légale : via la directive Banner, afficher un message de sécurité (“Accès réservé – toute intrusion sera poursuivie”). Utile pour la conformité légale.
- Limiter les tentatives de connexion : avec MaxAuthTries 3 et un outil comme Fail2ban qui bannit automatiquement les IP suspectes.
- Contrôle du temps de connexion : LoginGraceTime 60 limite le temps qu’un utilisateur a pour s’authentifier.
- Surveillance des sessions actives : grâce aux directives ClientAliveInterval et ClientAliveCountMax, on coupe les connexions inactives.
- Journalisation : configurer SyslogFacility AUTH et LogLevel VERBOSE pour garder une trace précise des connexions et anomalies.
Mettre en place une politique de sécurité SSH pour les MSP
Au-delà des paramètres techniques, une politique claire d’utilisation de SSH s’impose :
- Authentification par clés uniquement : fini les mots de passe réutilisés ou trop faibles.
- Clés protégées par passphrase : une clé privée volée sans passphrase est une faille ouverte.
- Surveillance proactive des logs : via /var/log/auth.log, ou mieux, intégrée dans un SIEM pour corréler les événements.
- Blocage automatique des IP suspectes : via Fail2ban ou des règles de firewall.
- MFA pour SSH : solutions comme CyberQP ou ThreatLocker permettent d’ajouter une authentification multi-facteurs pour renforcer encore l’accès aux environnements critiques.
Générer et utiliser des clés SSH
La base de toute configuration sécurisée, c’est la paire clé publique / clé privée. La clé privée reste toujours stockée sur votre poste ou dans un coffre-fort numérique, tandis que la clé publique est déployée sur les serveurs que vous administrez. Découvrez également notre article sur les meilleurs logiciels de cybersecurité.
Génération d’une clé SSH
La commande la plus courante est : ssh-keygen -t rsa -b 4096 -C "admin@infogerant.fr"
- -t rsa : spécifie l’algorithme.
- -b 4096 : longueur de la clé (plus elle est longue, plus elle est robuste).
- -C : commentaire pour identifier la clé (souvent l’adresse email pro).
💡 Astuce pour les msp : privilégiez désormais ED25519 lorsqu’il est disponible, plus léger et plus sécurisé que RSA, tout en étant plus rapide.
Déploiement de la clé publique sur le serveur
Avec : ssh-copy-id admin@serveur-client.fr
Cette commande ajoute automatiquement la clé publique dans le fichier ~/.ssh/authorized_keys du serveur cible. Dès lors, seule votre clé privée correspondante pourra ouvrir la porte.
👉 Pour gérer des dizaines de serveurs clients, il est judicieux d’automatiser le déploiement avec un outil RMM comme Datto RMM, en s’appuyant sur des scripts ou des composants pour pousser les clés, plutôt que de les installer manuellement..
Bonnes pratiques de gestion des clés SSH
- Utiliser un algorithme fiable : RSA 4096 ou ED25519.
- Toujours protéger la clé privée par une passphrase : si elle est volée, elle reste inutilisable sans ce mot de passe supplémentaire.
- Sauvegarder les clés dans un coffre-fort sécurisé (ex. Keeper ou autre gestionnaire de mots de passe).
- Renouveler périodiquement les clés pour limiter le risque de compromission à long terme.
- Révoquer immédiatement une clé compromise en la supprimant du fichier authorized_keys.
Commandes pratiques pour les connexions SSH
Quelques indispensables à garder sous le coude :
- Connexion simple : ssh user@host
- Copie de fichiers avec SCP : scp fichier.txt user@host:/chemin/
- Synchronisation avec rsync (plus performant que SCP pour les gros volumes) : rsync -avz -e ssh dossier/ user@host:/chemin/
- Tunnel SSH local (accéder à une base distante via localhost) : ssh -L 3306:localhost:3306 user@host
💡 Exemple concret pour un MSP : sécuriser l’accès à une base MySQL d’un client sans exposer le port 3306 sur Internet. On établit un tunnel SSH et on se connecte en local comme si la base était sur notre poste.
Modularité et gestion évolutive
Un serveur bien configuré aujourd’hui… peut devenir un cauchemar demain si rien n’est documenté. C’est là que la modularité et la standardisation entrent en jeu.
- Découper les fichiers : utiliser /etc/ssh/sshd_config.d/ pour séparer les configurations (ex. un fichier pour la sécurité, un autre pour les utilisateurs autorisés).
- Documenter systématiquement : noter chaque directive et sa justification dans une base centralisée comme IT Glue. Cela évite les “configurations fantômes” qu’on oublie avec le temps.
- Automatiser le déploiement : avec un RMM (ex. Datto RMM), on pousse les configs SSH sur tous les serveurs clients de façon homogène.
- Vérifier régulièrement : comparer la configuration réelle avec le modèle standard pour détecter les dérives.
👉 Un prestataire de services managés gagne ainsi en maintenabilité et peut scaler son activité sans perdre le contrôle de ses environnements.
Checklist pratique de configuration SSH
À titre indicatif
Cette checklist peut être utilisée comme base standardisée dans un processus interne MSP. Chaque étape est actionnable, mesurable et liée à un outil BeMSP adapté.
Conclusion
La configuration SSH est bien plus qu’un simple détail technique : c’est une brique essentielle de la cybersécurité pour les infogérants. Un paramétrage précis permet de réduire les risques, de gagner du temps sur la gestion quotidienne et de garantir une conformité aux standards de sécurité.
En combinant les bonnes pratiques (clés SSH, pas de root, port personnalisé, journalisation) avec des solutions avancées comme ThreatLocker, vous renforcez drastiquement la sécurité de vos accès IT. Réservez dès maintenant un RDV de démo avec BeMSP
et découvrez comment simplifier et sécuriser vos environnements SSH.
FAQ
Comment configurer une clé SSH ?
La configuration d’une clé SSH se fait en deux étapes : la génération et le déploiement.
- Sur votre machine locale, vous générez une paire clé publique/clé privée avec :
ssh-keygen -t rsa -b 4096 -C "admin@infogerant.fr"
- Vous pouvez aussi choisir -t ed25519 pour un algorithme plus moderne et plus rapide.
- Le système vous propose ensuite d’ajouter une passphrase : elle agit comme un mot de passe supplémentaire qui protège la clé privée.
- Ensuite, il faut installer la clé publique sur le serveur avec : ssh-copy-id admin@serveur-client.fr
- Cela ajoute automatiquement la clé publique au fichier ~/.ssh/authorized_keys du serveur.
- Bonnes pratiques pour les infogérants : stocker la clé privée dans un gestionnaire de secrets (Keeper par exemple), documenter le déploiement dans IT Glue et révoquer rapidement toute clé compromise.
Qu’est-ce que ~/.ssh/config ?
Il s’agit d’un fichier de configuration spécifique à chaque utilisateur. Son rôle : simplifier et personnaliser les connexions SSH.
Au lieu de taper une commande longue avec l’IP, le port et la clé privée, vous définissez un alias lisible. Exemple :
- Host serveur-client
- HostName 192.168.1.10
- User admin
- Port 2222
- IdentityFile ~/.ssh/id_rsa
Ensuite, une simple commande suffit : ssh serveur-client
Pour les infogérants, c’est un gain énorme en productivité et en fiabilité, surtout quand on gère plusieurs environnements.
Où trouver SSH config ?
La localisation dépend du rôle :
Côté client :
~/.ssh/config pour un utilisateur précis.
/etc/ssh/ssh_config pour tous les utilisateurs de la machine.
Côté serveur :
/etc/ssh/sshd_config pour la configuration principale.
/etc/ssh/sshd_config.d/ pour modulariser et mieux organiser la configuration.
Vérifiez toujours les permissions de ces fichiers : un ~/.ssh/config lisible par tout le monde peut exposer des chemins sensibles (clés, alias).
Quel est le but de l’utilisation de SSH ?
SSH est avant tout un protocole de connexion sécurisée. Il permet de :
- Administrer des serveurs à distance avec une communication chiffrée.
- Transférer des fichiers en toute sécurité (via scp ou rsync).
- Créer des tunnels chiffrés pour accéder à des services internes sans les exposer à Internet.
Pour un infogérant, SSH est l’outil incontournable : il évite les déplacements inutiles, permet de gérer plusieurs dizaines de serveurs clients depuis un poste central et garantit un haut niveau de sécurité des échanges.
Comment activer SSH sur mon ordinateur ?
Linux : installez le paquet openssh-server (souvent déjà présent par défaut). Activez et démarrez le service :
- sudo apt install openssh-server
- sudo systemctl enable ssh
- sudo systemctl start ssh
Windows 10/11 : SSH est intégré. Il suffit d’activer OpenSSH Client et OpenSSH Server dans les fonctionnalités Windows. Vous pouvez ensuite utiliser ssh directement depuis PowerShell.
macOS : le client SSH est inclus par défaut. Pour activer le serveur, rendez-vous dans Préférences Système > Partage > Accès à distance.
Pour les prestataires de services managés : documentez la procédure d’installation/activation dans un guide interne afin d’uniformiser vos pratiques entre techniciens.
