Configurer un service sous Linux, c'est toujours la même boucle : tu modifies son fichier dans /etc, tu fais vérifier la syntaxe, tu appliques avec systemctl, puis tu testes depuis une autre machine. Exemple sur un serveur Debian : pour interdire la connexion SSH directe en root, tu écris PermitRootLogin no dans /etc/ssh/sshd_config, tu lances sshd -t, puis systemctl reload ssh, et depuis le client, ssh [email protected] doit échouer. Suivent la méthode de dépannage et quatre exercices corrigés.
La boucle de configuration
Toutes les commandes de cette page se lancent en root, ou précédées de sudo. Les noms de paquets et de services sont ceux de Debian ; ils peuvent changer sur une autre distribution.
Étape 1 : Sauvegarder le fichier : cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak. Si tout casse, tu reviens en arrière en une commande.
Étape 2 : Modifier une chose à la fois, avec nano ou vim. Si le service tombe, tu sais quelle ligne accuser.
Étape 3 : Valider la syntaxe avec le testeur du service, s'il en a un : il relit les fichiers sans toucher au service en marche.
Étape 4 : Appliquer avec systemctl reload ou restart. Un service lit sa configuration quand il démarre : sans cette étape, il garde l'ancienne.
Étape 5 : Vérifier qu'il tourne, qu'il écoute sur le bon port et qu'il répond à un client.
Cette boucle est au cœur des ressources R2.02 et R2.03 (semestre 2) du programme national du BUT R&T : gérer les services et leurs journaux, puis installer, configurer et tester DHCP, DNS, HTTP, FTP, TFTP et NTP.
Valider avant d'appliquer
SSH, Apache et BIND ont chacun leur testeur de configuration. Il signale la ligne fautive avant qu'elle n'arrête le service.
| Service | Paquet | Fichiers à modifier | Test de syntaxe | Nom pour systemctl |
|---|---|---|---|---|
| SSH | openssh-server | /etc/ssh/sshd_config | sshd -t | ssh |
| Web (Apache) | apache2 | /etc/apache2/ports.conf, /etc/apache2/sites-available/ | apache2ctl configtest | apache2 |
| DNS (BIND) | bind9 | /etc/bind/named.conf.local et tes fichiers de zone | named-checkconf, named-checkzone | named |
Pour appliquer, reload demande au service de relire sa configuration sans s'arrêter, alors que restart l'arrête puis le relance. Préfère reload quand le service le permet. Sur Debian, systemctl reload ssh lance d'abord sshd -t : si le fichier est faux, rien n'est rechargé et sshd continue avec l'ancienne configuration. Le rechargement d'Apache teste lui aussi la configuration avant d'agir.
Piège classique : systemctl enable n'applique rien. Il inscrit le service au démarrage de la machine, sans le lancer ni lui faire relire son fichier. Pour le démarrer tout de suite et à chaque démarrage : systemctl enable --now apache2.
Quand le service ne répond pas
Ne teste pas tout en vrac : remonte la chaîne dans l'ordre, du service vers le client. Chaque contrôle élimine une cause.
D'abord systemctl status apache2. La ligne Loaded dit si le service est inscrit au démarrage (enabled) ou non (disabled). La ligne Active dit s'il tourne (active (running)) ou s'il a échoué (failed). Suivent les dix dernières lignes de son journal, où l'erreur apparaît souvent.
Pour tout le journal du service, placé directement à la fin : journalctl -u apache2 -e. Ajoute -b pour ne garder que les messages depuis le dernier démarrage.
Ensuite, vérifie qu'il écoute. ss -tlnp liste les ports TCP (-t) en écoute (-l), en chiffres plutôt qu'en noms (-n), avec le programme qui les tient (-p). Le DNS répond en UDP comme en TCP sur le port 53 : ajoute -u. Lis l'adresse locale : 127.0.0.1:8080 n'est joignable que depuis le serveur lui-même, alors que 0.0.0.0:22 accepte les connexions sur toutes ses adresses IPv4.
Enfin, teste depuis le client : un test lancé sur le serveur ne traverse pas le réseau. ping 192.168.10.2 vérifie que la machine est joignable, puis tu testes le service lui-même : curl http://192.168.10.2 pour le web, dig @192.168.10.2 www.tp.lan pour interroger ce serveur DNS précis, une connexion ssh pour SSH.
L'adresse du serveur : temporaire ou permanente
Un serveur a besoin d'une adresse fixe. La commande ip la pose tout de suite, dans la configuration que le noyau garde en mémoire : ip addr add 192.168.10.2/24 dev enp0s3 pour l'adresse, ip route add default via 192.168.10.1 pour la passerelle. Rien n'est écrit sur le disque, donc tout s'efface au redémarrage : parfait pour un essai, pas pour un serveur.
L'adresse durable s'écrit dans un fichier lu à chaque démarrage. Sur un serveur Debian sans interface graphique, c'est en général /etc/network/interfaces, lu par l'outil ifupdown (Cahier de l'administrateur Debian) :
auto enp0s3
iface enp0s3 inet static
address 192.168.10.2/24
gateway 192.168.10.1auto fait monter l'interface au démarrage, static annonce une adresse fixe. Le nom de l'interface change d'une machine à l'autre : lis-le avec ip link. Pour appliquer sans redémarrer : systemctl restart networking. Le serveur DNS que la machine interroge pour elle-même se règle à part, par une ligne nameserver 192.168.10.1 dans /etc/resolv.conf.
Piège classique : ne relance pas le réseau à travers une session SSH. Si la nouvelle configuration est fausse, la connexion tombe et tu perds la main sur le serveur. Fais-le depuis la console de la machine virtuelle.
Exercices corrigés
Du plus direct au plus proche d'un TP noté. Réseau fictif : serveur Debian en 192.168.10.2, passerelle en 192.168.10.1.
Exercice 1 : Apache tourne. Tu désactives le site par défaut avec a2dissite 000-default, tu crées /etc/apache2/sites-available/tp.conf, puis tu tapes systemctl enable apache2. Depuis le client, http://192.168.10.2 affiche toujours l'ancienne page. Quelles commandes manquent, dans quel ordre ?
Correction :
Rien n'a été appliqué : a2dissite n'a fait que retirer un lien dans sites-enabled, et enable ne règle que le démarrage de la machine. Apache tourne toujours avec la configuration lue à son lancement.
Il manque, dans l'ordre : a2ensite tp, qui crée le lien de ton site dans sites-enabled ; apache2ctl configtest, qui doit annoncer une syntaxe correcte ; systemctl reload apache2. Depuis le client, curl http://192.168.10.2 renvoie alors ta page.
Exercice 2 : Vendredi, tu as donné son adresse au serveur avec ip addr add, puis configuré BIND, qui répondait. Lundi, après un redémarrage du serveur, ping 192.168.10.2 et dig @192.168.10.2 www.tp.lan échouent depuis le client, alors que systemctl status named affiche active (running). Où est la panne, et comment la régler pour de bon ?
Correction :
BIND tourne, mais même ping échoue : la panne est sous le service, côté réseau. Sur le serveur, ip addr show enp0s3 le confirme : 192.168.10.2 a disparu, car ip ne l'avait posée qu'en mémoire.
Dans /etc/network/interfaces, donne à enp0s3 le bloc static de la partie précédente, puis applique depuis la console avec systemctl restart networking. Vérifie avec ss -tulnp que named écoute sur le port 53 de 192.168.10.2 (sinon, systemctl restart named), puis refais dig depuis le client.
Exercice 3 : Ton site doit répondre sur le port 8080. Dans /etc/apache2/ports.conf, tu as écrit Listen 127.0.0.1:8080. Depuis le client, curl http://192.168.10.2:8080 est refusé, alors que ssh passe. Sur le serveur, ss -tlnp montre sshd sur 0.0.0.0:22 et apache2 sur 127.0.0.1:8080. Explique, corrige et applique.
Correction :
Apache n'écoute que sur 127.0.0.1, l'adresse de bouclage, qui ne reçoit que les connexions nées sur le serveur. sshd écoute sur 0.0.0.0, donc sur toutes les adresses IPv4 : voilà pourquoi SSH passe.
Remplace la ligne par Listen 8080, lance apache2ctl configtest, puis systemctl restart apache2, pas reload. Au rechargement, Apache garde ses ports ouverts, et passer d'une écoute sur 127.0.0.1 à une écoute sur toutes les adresses, sur le même port, peut échouer : sa documentation demande un arrêt puis un démarrage, ce que fait restart. Contrôle : ss -tlnp ne montre plus 127.0.0.1:8080.
Exercice 4 : Connecté au serveur par SSH, tu ajoutes PermitRootLogn no (faute de frappe) dans sshd_config, puis tu tapes directement systemctl restart ssh. Que deviennent ta session et les nouvelles connexions ? Comment rattraper ?
Correction :
restart arrête sshd, puis le relance. Mais sur Debian, le démarrage passe d'abord par sshd -t, qui refuse ce mot clé inconnu : sshd ne repart pas, le service passe en failed et les nouvelles connexions sont refusées.
Ta session tient : Debian règle le service pour n'arrêter que le processus principal de sshd, pas les sessions ouvertes. Ne la ferme surtout pas. Corrige en PermitRootLogin no, relance sshd -t jusqu'à ce qu'il ne signale plus rien, puis systemctl start ssh, et teste une nouvelle connexion avant de fermer l'ancienne. Il fallait sshd -t avant, ou reload, qui n'aurait pas touché au sshd en marche.
À retenir
À retenir :
- La boucle : sauvegarder, modifier, valider, appliquer, vérifier depuis un client.
- Testeurs :
sshd -t,apache2ctl configtest,named-checkconfetnamed-checkzone. reloadrelit sans arrêter,restartarrête puis relance,enablene règle que le démarrage de la machine.- Dépannage dans l'ordre :
systemctl status,journalctl -u,ss -tulnp, puis le client. ipagit en mémoire et s'efface au redémarrage ; l'adresse durable va dans/etc/network/interfaces.
Sources
- Programme national du BUT Réseaux et télécommunications (annexe 22, ministère de l'Enseignement supérieur, 2022), ressources R2.02 et R2.03 : texte sur education.gouv.fr.
- Le cahier de l'administrateur Debian, section 8.2 « Configuration du réseau » : debian-handbook.info.
- Documentation du serveur HTTP Apache 2.4, « Écoute sélective » : httpd.apache.org.