Installer un serveur SSH sans ouvrir une faille

Installer un serveur SSH paraît simple : un paquet à poser, un service à démarrer, puis une commande pour se connecter. En pratique, c’est l’un des gestes d’administration qui mérite le plus de méthode, parce qu’il ouvre une porte directe vers le serveur.

L’objectif n’est pas de tout durcir dès la première minute. Il faut d’abord obtenir une première connexion fiable, vérifier que l’accès fonctionne depuis le bon poste, puis réduire progressivement les risques : mots de passe, utilisateur root, pare-feu, clés, journalisation et retour arrière.

Clarifier ce que vous installez vraiment

SSH est le protocole qui permet d’administrer une machine distante avec un canal chiffré, tandis qu’OpenSSH est l’implémentation la plus courante sur les systèmes Linux, macOS, BSD et Windows récents. Cette distinction évite une confusion fréquente : installer un client SSH ne suffit pas à accepter des connexions entrantes. Sur un serveur, ce que vous activez vraiment, c’est un service qui écoute le réseau et doit donc être traité comme une porte d’administration.

Sur le serveur, il faut le composant OpenSSH Server, souvent fourni par le paquet openssh-server. Sur le poste d’administration, il faut un client, généralement déjà présent sous Linux et macOS, et disponible dans Windows via OpenSSH Client ou Windows Terminal. Une même machine peut évidemment jouer les deux rôles, mais il faut savoir lequel vous configurez avant de toucher au service.

Avant d’installer quoi que ce soit sur une machine de production, vérifiez aussi votre mode d’accès actuel. Si vous êtes connecté via une console cloud, une interface KVM, une session distante ou un panneau d’hébergement, gardez cet accès ouvert jusqu’à la fin. C’est votre plan de retour arrière.

Installer OpenSSH Server sur Linux

Sur Linux, gardez une procédure courte et vérifiable. Elle doit installer le paquet, confirmer le nom du service, puis activer le démarrage automatique seulement après contrôle.

1. Debian ou Ubuntu : mettre l’index à jour puis installer le serveur OpenSSH.

   sudo apt update
   sudo apt install openssh-server

2. Fedora, CentOS Stream, Rocky Linux ou AlmaLinux : installer le paquet avec le gestionnaire de la distribution.

   sudo dnf install openssh-server

3. Vérifier le service : tester ssh et sshd, car le nom dépend de la distribution.

   systemctl status ssh
   systemctl status sshd

4. Activer le démarrage automatique uniquement avec le nom confirmé.

   sudo systemctl enable --now ssh
   sudo systemctl enable --now sshd

Ce n’est pas encore une configuration sécurisée complète. C’est une base fonctionnelle, à tester localement ou depuis une IP d’administration avant toute exposition large. À ce stade, la priorité est de vérifier l’accès, pas de multiplier les options avancées.

Installer OpenSSH sur Windows quand le serveur n’est pas Linux

SSH ne concerne pas uniquement les serveurs Linux. Sur Windows Server ou sur un poste Windows utilisé comme machine d’administration, OpenSSH peut être installé comme fonctionnalité système. La logique reste la même : le client sert à se connecter, le serveur accepte les connexions entrantes. La différence principale se situe dans la gestion du service et du pare-feu : sous Windows, il faut vérifier l’installation d’OpenSSH Server, démarrer sshd, puis contrôler la règle qui autorise l’accès.

Dans une petite équipe, documentez clairement si Windows sert seulement de poste client SSH ou s’il devient lui-même un serveur administrable à distance.

Le même garde-fou s’applique : ne rendez pas un service SSH Windows accessible depuis Internet sans raison précise. Si l’objectif est d’administrer des machines internes, un VPN, un bastion ou une restriction d’IP sera souvent plus propre qu’un port ouvert largement.

Pour approfondir ce point, consultez activer compte administrateur windows 10, qui traite plus précisément de activer le compte administrateur windows 10 sans ouvrir une faille.

Vérifier le port et le pare-feu avant la première connexion

Le port SSH par défaut est le port 22. Le changer peut réduire le bruit des scans automatisés, mais ce n’est pas une vraie mesure de sécurité si le reste de la configuration est faible. Pour une première installation, il vaut mieux garder une configuration lisible, valider l’accès, puis décider ensuite si un port non standard a un intérêt opérationnel.

• Service local : vérifiez d’abord que SSH écoute réellement sur la machine.

  sudo ss -tulpn | grep ssh

• Pare-feu local : sur Ubuntu avec UFW, l’ouverture minimale doit rester cohérente avec vos règles réseau.

  sudo ufw allow OpenSSH
  sudo ufw status

• Pare-feu cloud : contrôlez aussi le groupe de sécurité, la règle fournisseur ou l’ACL réseau. Une règle locale correcte ne sert à rien si le trafic est bloqué avant le serveur.

Établir la première connexion sans brûler les étapes

Le premier test doit rester volontairement simple.

Depuis votre poste, la commande de base suit toujours la même logique : utilisateur, adresse du serveur, puis éventuellement port. Pour un serveur accessible sur le port 22, la forme minimale est la suivante ; elle suffit pour valider le chemin réseau avant d’ajouter des options.

ssh utilisateur@adresse-du-serveur

Lors de la première connexion, le client affiche l’empreinte de l’hôte. Cette étape n’est pas décorative : elle sert à vérifier que vous parlez au bon serveur. Dans une PME, notez l’empreinte depuis la console d’administration ou le fournisseur, puis comparez-la avant d’accepter. C’est une protection contre les erreurs de cible et certains scénarios d’interception, mais aussi une bonne habitude de documentation pour les futurs administrateurs.

Si la connexion échoue, évitez de modifier trois paramètres d’un coup. Testez dans l’ordre : service actif, port ouvert localement, pare-feu cloud, bon utilisateur, bonne adresse IP, puis droits du compte. Cette progression évite de transformer un problème simple en configuration illisible, et elle laisse une trace claire de ce qui a déjà été vérifié.

Passer aux clés SSH sans se verrouiller dehors

L’authentification par clé repose sur une paire : une clé privée qui reste sur votre poste, et une clé publique copiée sur le serveur. La clé privée ne doit pas être envoyée, partagée dans un ticket, déposée dans un dossier commun ou copiée dans un dépôt Git.

Sur un poste Linux, macOS ou Windows récent, vous pouvez générer une clé moderne avec la commande suivante. Protégez la clé privée par une phrase de passe si le poste peut sortir de votre contrôle.

ssh-keygen -t ed25519 -C "admin@entreprise"

Copiez ensuite la clé publique vers le serveur. Selon le poste, ssh-copy-id peut simplifier l’opération, à condition de viser le bon utilisateur et le bon répertoire personnel.

ssh-copy-id utilisateur@adresse-du-serveur

Le test doit se faire avant de désactiver les mots de passe. Ouvrez une nouvelle session SSH avec la clé, vérifiez que la connexion fonctionne, puis gardez cette session ouverte. Seulement après ce test, vous pouvez envisager de modifier /etc/ssh/sshd_config.

Dans le fichier de configuration, les directives sensibles sont notamment PasswordAuthentication, PermitRootLogin, PubkeyAuthentication et parfois AllowUsers. Ne copiez pas une configuration trouvée au hasard : adaptez-la à votre distribution, à votre version OpenSSH et à votre mode d’exploitation.

Durcir la configuration sans casser l’administration

Le durcissement minimal consiste à réduire ce qui n’est pas nécessaire. L’accès root direct est rarement justifié ; mieux vaut se connecter avec un utilisateur nommé, puis utiliser sudo. L’authentification par mot de passe peut être désactivée quand les clés sont testées, sauvegardées et connues de l’équipe.

Avant de redémarrer SSH, validez la syntaxe de configuration. C’est une étape courte, mais elle évite de casser le service pour une directive mal écrite.

sudo sshd -t

Cette commande est un réflexe à prendre. Elle ne garantit pas que votre stratégie est parfaite, mais elle détecte les erreurs de configuration qui empêcheraient le service de repartir correctement. Ensuite, rechargez ou redémarrez le service selon la distribution :

sudo systemctl reload ssh
sudo systemctl restart ssh

Le bon test final se fait dans une nouvelle fenêtre, pas dans la session actuelle. Si la nouvelle connexion réussit, vous pouvez fermer progressivement les accès de secours. Si elle échoue, vous avez encore une session active pour corriger.

Documenter la configuration pour l’équipe

Un serveur SSH fiable n’est pas seulement sécurisé techniquement. Il doit aussi être compréhensible par la personne qui interviendra dans six mois. Notez le port utilisé, les comptes autorisés, l’emplacement des clés publiques, la règle de pare-feu, le mode d’accès de secours et la procédure de rotation d’une clé compromise. Cette trace évite qu’une bonne configuration devienne un piège le jour où l’équipe change.

La documentation doit rester courte.

Elle évite deux mauvaises habitudes : garder un accès root parce que “tout le monde connaît le mot de passe”, ou empiler des directives dans sshd_config sans savoir laquelle est réellement utile. Une configuration courte, commentée et testée vaut mieux qu’un fichier durci en apparence mais impossible à maintenir.

Prévoyez aussi une routine simple. Elle ne demande pas d’outil complexe et réduit déjà une grande partie du risque opérationnel, surtout quand plusieurs prestataires ou administrateurs interviennent sur le même périmètre.

1. Vérifier les journaux après une modification.
2. Retirer les clés des anciens collaborateurs ou prestataires.
3. Contrôler les comptes qui ont accès à sudo.
4. Tester la connexion depuis un poste autorisé après chaque changement.

Lire les journaux quand la connexion échoue

Quand SSH refuse une connexion, les journaux d’authentification sont plus utiles qu’une longue série d’essais. Sur beaucoup de distributions avec systemd, commencez par ces commandes et gardez l’heure du test sous les yeux.

sudo journalctl -u ssh -n 80
sudo journalctl -u sshd -n 80

Sur certains systèmes, les traces apparaissent aussi dans /var/log/auth.log ou /var/log/secure. Cherchez les messages autour de l’heure exacte du test. Une erreur de droits sur ~/.ssh/authorized_keys, un utilisateur refusé, une clé non acceptée ou un port bloqué se diagnostiquent souvent en quelques lignes. Si le journal reste silencieux, le trafic n’atteint probablement pas le service : regardez alors le pare-feu, le NAT, le groupe de sécurité cloud ou l’adresse utilisée.

Pour une PME, le bon standard n’est pas une configuration héroïque. C’est une configuration compréhensible, documentée, reproductible et testée après chaque changement. SSH doit rester un outil d’administration, pas une zone grise que personne n’ose modifier. Cette sobriété facilite aussi les audits : on sait qui peut entrer, par où, avec quel mécanisme et comment couper l’accès si un poste est perdu.

La priorité après l’installation

Après la première connexion réussie, la prochaine action claire est de passer à une authentification par clé pour les comptes administrateurs, puis de limiter l’exposition réseau. Ce duo apporte plus de valeur qu’un changement de port isolé ou qu’une longue liste de directives copiées sans contexte.

Gardez enfin une règle simple : chaque modification SSH doit être réversible tant qu’elle n’a pas été testée dans une nouvelle session. C’est cette discipline qui protège le serveur, l’administrateur et la continuité d’exploitation.