Sur Debian 12, l’accès distant se met en place avec le paquet OpenSSH Server, puis se vérifie avec le service nommé ssh. L’installation prend quelques commandes, mais le travail ne s’arrête pas au premier terminal qui s’ouvre : il faut aussi choisir les comptes autorisés, tester l’authentification et vérifier que le pare-feu laisse passer le trafic attendu.
SSH chiffre les échanges entre un client et un serveur. Il sert à administrer une machine, transférer des fichiers et automatiser certaines opérations, sans exposer les identifiants en clair sur le réseau. Dans un petit atelier ou une PME, un serveur Debian peut ainsi être administré depuis un poste Linux, macOS ou Windows. Le point à ne pas rater : modifier la configuration à distance sans garder une session de secours peut transformer une simple correction en déplacement physique jusqu’au serveur.
En bref : installer le serveur SSH sur Debian 12
- Installez le paquet openssh-server avec apt.
- Vérifiez le service avec systemctl status ssh.
- Autorisez le port 22 dans le pare-feu, si celui-ci est activé.
- Testez une connexion avec un compte ordinaire avant de durcir l’authentification.
- Préférez les clés SSH aux mots de passe pour l’administration régulière.
Préparer Debian 12 et installer OpenSSH
Avant l’installation, Debian 12 doit être opérationnel et connecté au réseau. Il faut aussi disposer d’un compte root ou d’un compte autorisé à utiliser sudo. Sur une machine virtuelle, vérifiez que l’interface réseau reçoit bien une adresse IP accessible depuis le poste client ; une installation réussie ne rend pas, à elle seule, la machine joignable depuis l’extérieur.
OpenSSH comprend plusieurs outils. Le client permet de se connecter à d’autres machines ; le serveur SSH accepte les connexions entrantes. Debian installe souvent le client par défaut, mais pas nécessairement le serveur. Pour vérifier la présence du client, lancez ssh -V. La commande affiche la version installée, tandis que scp et sftp servent respectivement à copier et à transférer des fichiers de façon interactive.
Actualisez l’index des paquets avant d’installer le service. Cette étape évite de travailler avec une liste de paquets périmée, notamment sur un système fraîchement déployé.
sudo apt update
sudo apt install openssh-server
Si apt indique que le paquet est introuvable, vérifiez la configuration des dépôts et la connectivité réseau avant de chercher un paquet téléchargé au hasard. Ce dépannage est détaillé dans le guide sur un paquet Debian introuvable. Pour un serveur de production, évitez aussi de mélanger des dépôts provenant de distributions différentes : cette pratique complique les mises à jour et peut introduire des versions incompatibles.
Vérifier le service après l’installation
Sur Debian, systemd gère le démon OpenSSH, mais son unité s’appelle ssh, et non sshd. Contrôlez son état avec sudo systemctl status ssh. Une ligne indiquant active (running) signifie que le processus fonctionne ; si le service est inactif, démarrez-le avec sudo systemctl start ssh.
Pour demander son lancement automatique au démarrage, utilisez sudo systemctl enable ssh. La commande enable ne démarre pas forcément le service dans la session courante : pour effectuer les deux actions ensemble, sudo systemctl enable –now ssh convient. Ce détail évite de croire qu’un service est actif simplement parce qu’il est configuré pour démarrer au prochain redémarrage.
Une fois cette première vérification faite, notez l’adresse IP du serveur avec ip address. Pour une machine destinée à rester accessible, une adresse stable ou une réservation DHCP évite de courir après une IP qui change après un redémarrage. Dans un laboratoire VirtualBox, vérifiez aussi le mode réseau choisi : un réseau NAT, un accès par pont et un réseau privé ne donnent pas les mêmes possibilités de connexion.
Activer l’accès distant et se connecter au serveur SSH
Le serveur OpenSSH écoute par défaut sur le port 22 en TCP. Il ne faut pas confondre le port d’écoute de la machine avec une règle de pare-feu : le service peut fonctionner correctement tout en restant inaccessible si le trafic entrant est bloqué. À l’inverse, ouvrir le port ne sert à rien si le démon n’est pas démarré ou si le client contacte la mauvaise adresse.
Depuis un poste Linux ou macOS, établissez une première connexion avec ssh nom_utilisateur@adresse_ip. Par exemple, ssh admin@192.168.1.40 demande une connexion au compte admin de la machine ayant cette adresse. Lors de la première connexion, le client affiche l’empreinte de la clé d’hôte du serveur. Il faut la comparer à une valeur obtenue par un canal fiable, surtout dans un environnement professionnel ; accepter sans vérifier peut masquer une interception.
Pour un port personnalisé, l’option correcte côté client est -p, suivie du numéro de port : ssh -p 2222 admin@192.168.1.40. Écrire le numéro de port après l’adresse sans l’option -p ne configure pas le port de connexion. Sur Windows, le client OpenSSH intégré à Windows Terminal ou à PowerShell permet d’utiliser la même syntaxe. PuTTY reste une autre possibilité, notamment pour les environnements où il est déjà déployé.
Contrôler le pare-feu sans s’enfermer dehors
UFW n’est pas obligatoirement installé ni activé sur Debian. Si c’est le pare-feu utilisé, vérifiez d’abord son état avec sudo ufw status. Lorsqu’il est actif, une règle peut autoriser SSH avec sudo ufw allow 22/tcp. Si le service écoute sur un autre port, la règle doit correspondre à ce port et être ajoutée avant de fermer la session existante.
Dans un environnement distant, gardez votre connexion actuelle ouverte pendant le test d’une nouvelle session. Une faute dans une règle réseau ou une directive OpenSSH peut couper l’accès après un redémarrage du service. Pour une machine hébergée chez un fournisseur cloud, le filtrage local peut coexister avec un pare-feu configuré dans le panneau de gestion : les deux doivent autoriser le flux.
Un port différent de 22 peut réduire le bruit des tentatives automatiques les plus simples, mais ce n’est pas une mesure de sécurité suffisante. Un scan de ports détecte généralement le service. Pour une administration exposée sur Internet, la priorité reste une authentification forte, une limitation des comptes autorisés et, si l’architecture le permet, un accès via VPN ou bastion.
Si la connexion échoue, séparez les vérifications : résolution de l’adresse, filtrage réseau, état de ssh, puis authentification. Les journaux système donnent souvent le motif exact. Pour surveiller un fichier de log en direct, les commandes de suivi présentées dans ce tutoriel sur la surveillance des journaux sous Linux peuvent aider à repérer une tentative refusée.
Régler sshd_config sans perdre l’accès
La configuration du serveur se trouve principalement dans /etc/ssh/sshd_config. Le fichier /etc/ssh/ssh_config concerne, lui, le comportement du client sur la machine locale. Modifier le mauvais fichier est une erreur fréquente : cela peut changer la façon dont Debian se connecte à d’autres serveurs sans modifier les connexions entrantes.
Avant toute modification, conservez une copie du fichier d’origine. Utilisez ensuite un éditeur de texte et changez uniquement les directives nécessaires. Certaines versions de Debian incluent également des fichiers de configuration complémentaires depuis le répertoire /etc/ssh/sshd_config.d/. Vérifiez les directives déjà présentes dans ces fichiers : une valeur définie plus tôt peut prendre le dessus sur une autre ajoutée plus bas.
Les options AllowUsers et DenyUsers permettent de limiter les comptes autorisés ou interdits. Pour une petite machine d’administration, une règle comme AllowUsers admin ops limite l’accès à ces comptes. Les noms doivent correspondre aux utilisateurs locaux et être séparés par des espaces. Cette restriction ne remplace pas la gestion des droits : un compte ne devrait disposer de privilèges sudo que si son rôle le justifie.
La connexion directe du compte root est à éviter. La directive PermitRootLogin no oblige l’administrateur à se connecter avec un compte nominatif, puis à utiliser sudo pour les opérations privilégiées. Cela fournit une meilleure traçabilité et évite de partager un identifiant puissant entre plusieurs personnes. Autoriser root avec un mot de passe, même pour « gagner du temps », est une mauvaise habitude à ne pas installer en production.
Valider les changements avant de relancer le service
Après une modification, ne redémarrez pas ssh à l’aveugle. Vérifiez d’abord la syntaxe avec sudo sshd -t. Si la commande ne renvoie rien, le fichier est syntaxiquement valide ; cela ne garantit pas que chaque choix soit adapté, mais élimine les erreurs de lecture les plus courantes. En cas de message d’erreur, corrigez le fichier avant de poursuivre.
Pour appliquer une modification, sudo systemctl reload ssh recharge généralement la configuration sans arrêter complètement le service. Si le rechargement n’est pas adapté au changement effectué, utilisez sudo systemctl restart ssh, mais seulement après avoir confirmé que le port reste autorisé et que la nouvelle session fonctionne. Garder une session administrative ouverte pendant ce test est une précaution simple qui évite bien des allers-retours.
| Directive | Rôle | Conseil de configuration |
|---|---|---|
| Port | Définit le port d’écoute du serveur | Conservez 22, sauf besoin réseau précis |
| PermitRootLogin | Contrôle la connexion SSH du compte root | Utilisez no et un compte nominatif |
| PasswordAuthentication | Autorise ou bloque les mots de passe | Désactivez après validation des clés |
| AllowUsers | Limite les comptes pouvant se connecter | Indiquez les comptes réellement nécessaires |
Changer le port par défaut ne compense ni un compte partagé ni un mot de passe faible. Une configuration raisonnable est lisible, documentée et testée avant fermeture de l’accès actuel ; une longue liste de directives copiées sans contexte rend souvent le dépannage plus difficile.
Utiliser des clés SSH et renforcer l’authentification
Les clés SSH remplacent la saisie répétée d’un mot de passe par une paire cryptographique. La clé privée reste sur le poste client ; la clé publique est déposée sur le serveur dans le fichier ~/.ssh/authorized_keys du compte concerné. La clé privée ne doit jamais être copiée sur le serveur ni envoyée par courriel. Si elle est exposée, toute personne qui la possède peut tenter de l’utiliser.
Sur le poste client, créez une paire avec ssh-keygen -t ed25519. La clé Ed25519 convient aux usages courants et produit des clés compactes. Acceptez un emplacement de stockage approprié et définissez une phrase secrète : elle protège la clé privée si le poste est perdu ou compromis. Pour les équipements anciens qui ne prennent pas en charge cet algorithme, vérifiez les algorithmes compatibles plutôt que de désactiver globalement les protections du serveur.
La commande ssh-copy-id admin@192.168.1.40 copie la clé publique sur le serveur après authentification. Si ssh-copy-id n’est pas disponible, la clé peut être installée manuellement dans ~/.ssh/authorized_keys, en respectant les permissions du répertoire .ssh et du fichier. Une permission trop ouverte peut conduire OpenSSH à refuser la clé, ce qui se voit dans les journaux et dans le message affiché par le client.
Testez ensuite une nouvelle connexion par clé dans un second terminal. Ne désactivez pas PasswordAuthentication avant d’avoir confirmé que la clé fonctionne pour chaque compte d’administration utile. Une erreur de chemin, un mauvais propriétaire de fichier ou une clé copiée sur le mauvais utilisateur suffit à couper l’accès par clé. En exploitation, cette vérification préalable vaut largement les quelques minutes qu’elle prend.
Réduire les possibilités d’accès inutiles
Quand toutes les clés nécessaires ont été testées, la directive PasswordAuthentication no peut désactiver l’authentification par mot de passe. Combinez ce réglage avec PermitRootLogin no et une liste AllowUsers limitée. Cette approche réduit les chemins d’accès, mais impose de conserver une procédure de récupération, par exemple une console distante fournie par l’hébergeur ou un accès physique contrôlé.
La sécurité réseau ne se résume pas au chiffrement de SSH. Limitez l’exposition du service aux adresses ou réseaux qui en ont besoin, surveillez les comptes et appliquez les mises à jour de sécurité de Debian. Pour automatiser des connexions, utilisez des comptes dédiés et des clés distinctes plutôt qu’une seule clé privée partagée par toute l’équipe.
Le transfert de fichiers utilise aussi les outils OpenSSH. scp permet une copie ponctuelle, tandis que sftp fournit une session de transfert interactive. Pour des sauvegardes régulières, vérifiez les permissions et le sens du transfert avant d’automatiser la tâche. La compression peut réduire le volume de certains fichiers, mais elle n’apporte pas toujours un gain sur des données déjà compressées ; le guide consacré à la commande gzip sous Linux explique les cas où cette étape est utile.
Diagnostiquer les erreurs courantes et garder un accès fiable
Une connexion refusée ne signifie pas automatiquement que le mot de passe est incorrect. Si le client affiche « Connection refused », le service peut être arrêté, écouter sur un autre port ou être rejeté par un pare-feu. Le message « Connection timed out » oriente plutôt vers un filtrage réseau, une adresse erronée ou un problème de routage. Ces messages ne remplacent pas le contrôle des journaux, mais ils aident à choisir la première vérification.
Consultez l’état du service avec sudo systemctl status ssh, puis les événements récents avec sudo journalctl -u ssh. Sur Debian, les tentatives d’authentification peuvent également apparaître dans les journaux système selon la configuration de rsyslog. Cherchez l’heure exacte de l’essai, le compte utilisé et le motif de refus. Évitez de publier ces journaux sans les nettoyer : ils peuvent révéler des noms de comptes, des adresses IP et des détails sur l’infrastructure.
Dans un scénario classique, une PME installe Debian sur une petite machine de sauvegarde et autorise SSH pour l’administrer depuis le bureau. Si l’adresse IP change après le redémarrage, les commandes de service restent correctes, mais le poste client continue de viser l’ancienne adresse. Une réservation DHCP ou une adresse fixe bien documentée règle ce type de panne plus proprement qu’une série de modifications du serveur SSH.
Autre piège : modifier le port d’écoute dans sshd_config, mais oublier de l’autoriser dans UFW ou dans le pare-feu du fournisseur. Le service démarre alors sur le nouveau port, mais les connexions extérieures n’arrivent jamais jusqu’à lui. Après toute modification, vérifiez le port réellement en écoute et testez depuis une autre machine, pas uniquement depuis le serveur lui-même.
Enfin, gardez une trace des changements : date, directives touchées, port utilisé et méthode de retour arrière. Les configurations SSH sont souvent modifiées lors d’une intervention urgente, puis oubliées pendant des mois. Une note courte dans la documentation d’exploitation évite qu’un collègue découvre un port non standard ou une règle AllowUsers sans savoir pourquoi elle existe.
Le serveur SSH est-il installé par défaut sur Debian 12 ?
Le client OpenSSH est fréquemment présent, mais le serveur ne l’est pas nécessairement. Installez openssh-server avec apt, puis contrôlez l’unité systemd ssh.
Comment autoriser SSH avec UFW ?
Si UFW est actif et que le serveur écoute sur le port standard, la commande sudo ufw allow 22/tcp autorise le trafic entrant. Vérifiez ensuite les règles avec sudo ufw status.
Comment se connecter à un port SSH différent de 22 ?
Utilisez l’option -p côté client, par exemple ssh -p 2222 utilisateur@adresse_ip. Le port doit aussi être configuré et autorisé dans les pare-feux concernés.
Peut-on désactiver l’authentification par mot de passe ?
Oui, après avoir installé et testé les clés SSH pour tous les comptes nécessaires. Configurez PasswordAuthentication no, validez avec sudo sshd -t et gardez une session de secours pendant le test.
