Comment configurer un serveur Linux après l’installation ?

Configurer un serveur Linux consiste à préparer une machine physique ou virtuelle pour héberger des services de manière fiable, sécurisée et maintenable. Après l’installation du système, les étapes essentielles sont toujours les mêmes : se connecter en SSH, mettre à jour les paquets, créer un utilisateur non-root, sécuriser l’accès, configurer le pare-feu, installer les services nécessaires, activer les sauvegardes et vérifier les journaux.

Ce guide s’adresse surtout aux utilisateurs qui viennent de louer un VPS, d’installer Ubuntu Server, Debian, AlmaLinux ou Rocky Linux, ou de recevoir un serveur dédié à administrer. L’objectif n’est pas seulement de comprendre Linux, mais d’obtenir une méthode claire pour transformer un serveur fraîchement installé en serveur exploitable pour un site web, une application, une base de données ou un environnement de test.

La plupart des commandes ci-dessous sont adaptées à Ubuntu Server et Debian. Quand c’est utile, une alternative est aussi donnée pour les distributions de la famille Red Hat, comme AlmaLinux, Rocky Linux ou RHEL. Avant de copier une commande, remplacez toujours les valeurs d’exemple comme votre_ip, votre_utilisateur ou exemple.com par vos propres informations.

Pour configurer un serveur Linux, commencez par vous connecter en SSH, mettre à jour le système, créer un utilisateur avec sudo, désactiver la connexion root, activer un pare-feu, installer Fail2Ban, configurer l’heure, installer les services utiles, mettre en place des sauvegardes et vérifier les logs. Ces étapes constituent la base d’un serveur propre et administrable.

Qu’est-ce qu’un serveur Linux ?

Un serveur Linux est une machine qui utilise une distribution Linux pour fournir des services à d’autres utilisateurs ou applications. Il peut héberger un site web, une base de données, une API, des fichiers, des conteneurs ou un outil interne. Il est généralement administré à distance avec SSH et fonctionne souvent sans interface graphique.

Un serveur Linux peut être un serveur physique installé dans une entreprise, un serveur dédié loué chez un hébergeur ou un VPS, c’est-à-dire un serveur privé virtuel. Dans la majorité des cas, l’administrateur interagit avec lui depuis un terminal. Cette approche peut sembler austère au départ, mais elle offre un contrôle précis sur le système, les services, les permissions, les ressources et la sécurité.

Linux est très utilisé côté serveur parce qu’il est stable, flexible, largement documenté et compatible avec un grand nombre d’outils open source. Il est courant de l’utiliser pour héberger Nginx, Apache, MariaDB, PostgreSQL, Docker, Node.js, Python, PHP, WordPress ou des applications métiers. Pour un projet web, il devient souvent la base technique sur laquelle reposent les performances, la disponibilité et la sécurité du service.

La configuration d’un serveur Linux ne s’arrête donc pas à l’installation du système. Un serveur fraîchement livré par un hébergeur peut être fonctionnel, mais il n’est pas forcément prêt pour la production. Il faut vérifier les accès, limiter les privilèges, fermer les ports inutiles, surveiller les services et prévoir une stratégie de sauvegarde. C’est précisément le rôle de la configuration initiale.

Quelle distribution choisir pour un serveur Linux ?

Pour un serveur Linux, Ubuntu Server LTS et Debian Stable sont les choix les plus simples pour la majorité des projets web. Ubuntu LTS convient très bien aux débutants grâce à sa documentation et à son écosystème. Debian Stable privilégie la stabilité. Pour un environnement proche de Red Hat, choisissez plutôt AlmaLinux, Rocky Linux ou RHEL.

Le choix de la distribution dépend du niveau technique, du type de projet, du cycle de support souhaité et des outils à installer. Pour un site WordPress, une application PHP, un serveur Nginx ou une base MariaDB, Ubuntu Server LTS ou Debian Stable suffisent dans la majorité des cas. Pour une entreprise qui utilise déjà l’écosystème Red Hat, AlmaLinux, Rocky Linux ou RHEL seront plus cohérents.

En 2026, un choix raisonnable pour un projet web classique serait : Ubuntu Server LTS pour la simplicité, Debian Stable pour la sobriété, AlmaLinux ou Rocky Linux pour un usage RHEL-like. Le plus important est de choisir une distribution que vous pourrez maintenir, documenter et mettre à jour dans le temps.

Quels prérequis avant de configurer un serveur Linux ?

Avant de configurer un serveur Linux, préparez l’adresse IP, l’accès SSH, le mot de passe initial ou la clé privée, le nom de domaine, l’accès DNS, un snapshot de départ et la liste des services à installer. Cette préparation évite les blocages pendant la configuration et limite les risques de mauvaise manipulation.

Avant de modifier la configuration du serveur, rassemblez les informations indispensables. Vous devez connaître l’adresse IP publique du serveur, l’utilisateur fourni par l’hébergeur, le mot de passe temporaire ou la clé SSH, le système installé et l’emplacement de la console de secours. Sur un VPS, la console web de l’hébergeur est utile si vous bloquez accidentellement SSH avec une mauvaise règle de pare-feu.

Préparez aussi le nom de domaine si le serveur doit héberger un site. Vous devrez créer ou modifier des enregistrements DNS, généralement un enregistrement A vers l’adresse IPv4 du serveur et parfois un enregistrement AAAA vers l’adresse IPv6. La propagation DNS peut prendre du temps, mais il est préférable de l’anticiper avant d’installer un certificat HTTPS.

Avant les changements importants, créez un snapshot si votre hébergeur le permet. Ce snapshot permet de revenir à l’état initial si une erreur bloque l’accès SSH ou casse un service critique. Ce n’est pas une stratégie de sauvegarde complète, mais c’est une sécurité très utile pendant la configuration initiale.

Enfin, définissez le rôle du serveur. Un serveur qui héberge seulement un site statique n’a pas besoin des mêmes services qu’un serveur WordPress, un serveur de base de données, un reverse proxy ou un nœud Docker. Moins vous installez de services inutiles, plus le serveur est simple à sécuriser.

Quelle architecture choisir pour son serveur Linux ?

L’architecture d’un serveur Linux dépend du projet à héberger. Pour un site simple, Nginx avec HTTPS suffit. Pour WordPress, il faut ajouter PHP et MariaDB. Pour une application Node.js, Nginx sert souvent de reverse proxy. Pour plusieurs services, Docker peut être utile, mais il demande plus de rigueur sur les volumes, les sauvegardes et le monitoring.

Avant d’installer des services, il faut définir le rôle exact du serveur. Un VPS utilisé pour héberger un site vitrine n’a pas besoin de la même architecture qu’un serveur WordPress, une API Node.js, une application Docker ou une base de données critique. Plus l’architecture est simple, plus elle est facile à sécuriser, maintenir et dépanner.

Pour un site statique, l’architecture la plus légère consiste à utiliser Nginx + HTTPS. Le serveur ne fait que servir des fichiers HTML, CSS, JavaScript et images. C’est rapide, peu coûteux en ressources et simple à sauvegarder.

Pour un site WordPress, l’architecture classique repose sur Nginx ou Apache + PHP-FPM + MariaDB. Nginx est souvent apprécié pour ses performances, tandis qu’Apache reste pratique dans certains environnements WordPress grâce à sa compatibilité avec les fichiers .htaccess. Dans tous les cas, il faut prévoir des sauvegardes régulières des fichiers et de la base de données.

Pour une application Node.js, Python ou Laravel, il est recommandé de placer Nginx en reverse proxy devant l’application. Nginx reçoit les requêtes HTTP/HTTPS, gère le certificat SSL, puis transmet le trafic vers l’application locale, par exemple sur le port 3000, 8000 ou 9000.

Pour un projet avec plusieurs services, Docker peut simplifier le déploiement. Il permet d’isoler Nginx, l’application, la base de données et les outils annexes dans des conteneurs. En revanche, Docker ajoute une couche de complexité : il faut gérer les volumes persistants, les réseaux, les variables d’environnement, les mises à jour d’images et les sauvegardes.

Le bon choix est donc celui que vous pouvez maintenir. Pour débuter, évitez les architectures trop ambitieuses. Un serveur simple, bien sécurisé et bien sauvegardé vaut mieux qu’une infrastructure complexe mal documentée.

Les 10 étapes pour configurer un serveur Linux

La configuration initiale d’un serveur Linux suit une séquence logique : connexion SSH, mise à jour, création d’un utilisateur non-root, configuration sudo, clés SSH, durcissement de SSH, pare-feu, Fail2Ban, fuseau horaire, puis test complet après redémarrage. Ces dix étapes créent une base propre avant l’installation des services web.

Cette section est le cœur du guide. Exécutez les étapes dans l’ordre. Ne fermez jamais votre première session SSH avant d’avoir testé une deuxième connexion, surtout après avoir modifié le pare-feu ou la configuration SSH.

Étape 1 : Se connecter au serveur en SSH

SSH permet d’administrer un serveur Linux à distance de manière chiffrée. Depuis macOS, Linux ou Windows avec PowerShell récent, ouvrez un terminal et tapez :

ssh root@votre_ip

Si l’hébergeur a fourni un autre utilisateur, utilisez-le :

ssh votre_utilisateur@votre_ip

Lors de la première connexion, SSH peut afficher une empreinte de clé et demander confirmation. Tapez yes si l’adresse IP correspond bien à votre serveur. Entrez ensuite le mot de passe temporaire ou utilisez la clé privée fournie.

Après connexion, vérifiez la distribution installée :

cat /etc/os-release

Vérifiez aussi le nom d’hôte et le noyau :

hostnamectl

uname -a

Ces informations seront utiles si vous devez demander de l’aide ou diagnostiquer un problème.

Étape 2 : Mettre à jour le système

Un serveur neuf peut déjà avoir des paquets en retard. La première bonne pratique consiste à appliquer les mises à jour avant d’installer vos propres services.

Sur Ubuntu ou Debian :

apt update

apt full-upgrade -y

apt autoremove -y

Sur AlmaLinux, Rocky Linux ou RHEL :

dnf upgrade --refresh-y

Redémarrez si le noyau ou des bibliothèques système importantes ont été mises à jour :

reboot

Reconnectez-vous ensuite en SSH. Cette étape paraît simple, mais elle évite de construire un serveur de production sur une base déjà obsolète. Elle permet aussi de vérifier que le redémarrage fonctionne avant d’installer des services critiques.

Étape 3 : Créer un utilisateur non-root

Le compte root possède tous les droits. Il est pratique pour l’installation initiale, mais risqué au quotidien. Créez un utilisateur dédié à l’administration.

Sur Ubuntu ou Debian :

adduser joseph

usermod -aGsudo joseph

Sur AlmaLinux, Rocky Linux ou RHEL :

adduser joseph

passwd joseph

usermod -aG wheel joseph

Remplacez joseph par le nom d’utilisateur souhaité. Connectez-vous ensuite avec ce compte :

ssh joseph@votre_ip

Testez les privilèges administrateur :

sudo whoami

Si la commande renvoie root, l’utilisateur peut administrer le serveur avec sudo. À partir de maintenant, utilisez ce compte pour vos tâches courantes.

Étape 4 : Configurer sudo proprement

sudo permet d’exécuter une commande avec des privilèges élevés sans rester connecté en root. C’est une pratique plus sûre, car chaque action importante est volontaire et peut être journalisée.

Pour vérifier les groupes de l’utilisateur :

groups joseph

Sur Ubuntu ou Debian, le groupe attendu est souvent sudo. Sur les distributions RHEL-like, le groupe attendu est généralement wheel.

Si vous devez modifier les permissions sudo, utilisez toujours visudo au lieu d’éditer directement le fichier :

sudo visudo

visudo vérifie la syntaxe avant d’enregistrer. Cela évite de casser l’accès administrateur à cause d’une erreur dans le fichier sudoers.

Étape 5 : Activer l’authentification par clé SSH

L’authentification par clé SSH est plus robuste qu’un simple mot de passe. Sur votre ordinateur local, générez une clé si vous n’en avez pas :

ssh-keygen -t ed25519 -C"serveur-linux"

Copiez ensuite la clé publique vers le serveur :

ssh-copy-id joseph@votre_ip

Si ssh-copy-id n’est pas disponible, affichez votre clé publique locale :

cat ~/.ssh/id_ed25519.pub

Puis collez son contenu sur le serveur dans :

mkdir-p ~/.ssh

nano ~/.ssh/authorized_keys

chmod700 ~/.ssh

chmod600 ~/.ssh/authorized_keys

Ouvrez une nouvelle fenêtre de terminal et testez la connexion sans fermer l’ancienne :

ssh joseph@votre_ip

Si la connexion fonctionne sans mot de passe, vous pouvez passer à l’étape suivante.

Étape 6 : Désactiver la connexion root et limiter SSH

Avant de modifier SSH, gardez une session ouverte. Une erreur de configuration peut bloquer l’accès au serveur.

Ouvrez le fichier de configuration :

sudo nano /etc/ssh/sshd_config

Vérifiez ou ajoutez ces lignes :

PermitRootLogin no

PubkeyAuthentication yes

PasswordAuthentication no

Sur certains serveurs cloud, la directive PasswordAuthentication peut aussi être définie dans un fichier du dossier /etc/ssh/sshd_config.d/. Vérifiez donc les fichiers inclus si votre modification ne semble pas prise en compte.

Testez la configuration SSH avant de recharger :

sudo sshd -t

Si aucune erreur n’apparaît, rechargez SSH :

sudo systemctl reload ssh

Sur certaines distributions, le service s’appelle sshd :

sudo systemctl reload sshd

Ouvrez une nouvelle session et confirmez que l’utilisateur non-root peut se connecter. Ne fermez l’ancienne session qu’après ce test.

Étape 7 : Configurer le pare-feu

Le pare-feu limite les connexions entrantes aux services nécessaires. Sur un serveur web classique, vous aurez généralement besoin de SSH, HTTP et HTTPS.

Sur Ubuntu ou Debian avec UFW :

sudo apt install ufw -y

sudo ufw default deny incoming

sudo ufw default allow outgoing

sudo ufw allow OpenSSH

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw enable

sudo ufw status verbose

Si SSH utilise un port personnalisé, autorisez ce port avant d’activer UFW :

sudo ufw allow 2222/tcp

Sur AlmaLinux, Rocky Linux ou RHEL avec firewalld :

sudo dnf install firewalld -y

sudo systemctl enable --now firewalld

sudo firewall-cmd --permanent--add-service=ssh

sudo firewall-cmd --permanent--add-service=http

sudo firewall-cmd --permanent--add-service=https

sudo firewall-cmd --reload

sudo firewall-cmd --list-all

Le principe est simple : tout ce qui n’est pas nécessaire doit rester fermé.

Étape 8 : Installer Fail2Ban

Fail2Ban surveille les logs et bloque temporairement les adresses IP qui multiplient les tentatives de connexion échouées. Il ne remplace pas les clés SSH, mais ajoute une protection utile contre les attaques automatisées.

Sur Ubuntu ou Debian :

sudo apt install fail2ban -y

Créez une configuration dédiée à SSH :

sudo nano /etc/fail2ban/jail.d/sshd.local

Ajoutez :

[sshd]

enabled = true

port = ssh

maxretry = 5

findtime = 10m

bantime = 1h

Activez et vérifiez le service :

sudo systemctl enable --now fail2ban

sudo fail2ban-client status

sudo fail2ban-client status sshd

Si vous utilisez un port SSH personnalisé, remplacez port = ssh par le numéro du port.

Étape 9 : Régler le fuseau horaire, NTP et le nom d’hôte

Un serveur doit avoir une heure correcte. Les logs, certificats, sauvegardes et tâches planifiées dépendent de l’horloge système.

Afficher l’état actuel :

timedatectl

Définir le fuseau horaire, par exemple Paris :

sudo timedatectl set-timezone Europe/Paris

Activer la synchronisation de l’heure :

sudo timedatectl set-ntp true

Définir un nom d’hôte clair :

sudo hostnamectl set-hostname vps-web-01

Éditez ensuite /etc/hosts si nécessaire :

sudo nano /etc/hosts

Un nom d’hôte explicite facilite l’administration quand vous gérez plusieurs serveurs.

Étape 10 : Redémarrer et tester la configuration

Une fois les bases appliquées, redémarrez le serveur :

sudo reboot

Reconnectez-vous avec l’utilisateur non-root :

ssh joseph@votre_ip

Vérifiez les services principaux :

sudo systemctl status ssh

sudo ufw status verbose

sudo fail2ban-client status

Sur les distributions RHEL-like :

sudo systemctl status sshd

sudo firewall-cmd --list-all

sudo systemctl status fail2ban

À ce stade, le serveur dispose d’une base plus saine : compte administrateur non-root, accès SSH par clé, pare-feu actif, protection contre les tentatives répétées et système à jour.

Installer un serveur web sur Linux

Pour héberger un site, installez Nginx ou Apache, ouvrez les ports 80 et 443, créez un dossier web, configurez un hôte virtuel, testez la configuration puis ajoutez un certificat HTTPS. Nginx est souvent choisi pour ses performances et son rôle de reverse proxy, tandis qu’Apache reste très compatible avec les environnements PHP et WordPress.

Un serveur Linux devient souvent utile quand il héberge un site ou une application. Deux serveurs web dominent les usages courants : Nginx et Apache. Nginx est apprécié pour sa légèreté, ses performances et sa capacité à fonctionner comme reverse proxy. Apache reste très répandu, notamment pour les projets qui s’appuient sur .htaccess.

Installer Nginx

Sur Ubuntu ou Debian :

sudo apt install nginx -y

sudo systemctl enable --now nginx

sudo systemctl status nginx

Autorisez le trafic web si ce n’est pas déjà fait :

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

Créez un dossier pour le site :

sudomkdir-p /var/www/exemple.com/public

sudochown-R$USER:www-data /var/www/exemple.com

sudochmod-R755 /var/www/exemple.com

Ajoutez une page de test :

echo"Serveur Linux opérationnel" | sudotee /var/www/exemple.com/public/index.html

Créez un bloc serveur Nginx :

sudo nano /etc/nginx/sites-available/exemple.com

Collez :

server {

listen 80;

listen [::]:80;

server_name exemple.com www.exemple.com;

root /var/www/exemple.com/public;

index index.html index.htm;

location / {

try_files $uri $uri/ =404;

}

}

Activez le site et testez :

sudoln-s /etc/nginx/sites-available/exemple.com /etc/nginx/sites-enabled/

sudo nginx -t

sudo systemctl reload nginx

Si le DNS pointe déjà vers le serveur, ouvrez http://exemple.com dans un navigateur.

Installer Apache

Si vous préférez Apache :

sudo apt install apache2 -y

sudo systemctl enable --now apache2

sudo systemctl status apache2

Apache est souvent pratique pour WordPress et certains hébergements historiques. Nginx peut être plus simple pour servir un site statique, agir comme reverse proxy ou gérer de nombreux fichiers avec peu de ressources. Le choix dépend donc du projet, pas d’une règle absolue.

Ajouter HTTPS avec Certbot

Pour obtenir un certificat TLS gratuit avec Let’s Encrypt, installez Certbot. Avec Nginx :

sudo apt install certbot python3-certbot-nginx -y

sudo certbot --nginx-d exemple.com -d www.exemple.com

Testez le renouvellement automatique :

sudo certbot renew --dry-run

Avec Apache :

sudo apt install certbot python3-certbot-apache -y

sudo certbot --apache-d exemple.com -d www.exemple.com

HTTPS est indispensable pour un site moderne. Il protège les échanges, évite les alertes navigateur et permet d’utiliser correctement de nombreuses fonctionnalités web récentes.

Gérer les services et les processus

Sur les distributions Linux modernes, la gestion des services passe principalement par systemctl. Vous pouvez démarrer, arrêter, redémarrer, activer ou diagnostiquer un service avec quelques commandes. Pour les logs, journalctl permet de consulter les événements système et les erreurs liées à un service précis.

Quand un serveur héberge Nginx, Apache, MariaDB, PostgreSQL, Redis ou Docker, il faut savoir vérifier l’état de chaque service. La commande la plus utile est systemctl.

• Afficher l’état d’un service :

sudo systemctl status nginx

• Démarrer un service :

sudo systemctl start nginx

• Arrêter un service :

sudo systemctl stop nginx

• Redémarrer un service :

sudo systemctl restart nginx

• Recharger une configuration sans arrêt complet :

sudo systemctl reload nginx

• Activer le service au démarrage :

sudo systemctl enable nginx

• Désactiver le démarrage automatique :

sudo systemctl disable nginx

• Pour lire les logs d’un service :

sudo journalctl -u nginx

• Pour suivre les logs en direct :

sudo journalctl -u nginx -f

• Pour afficher les erreurs récentes du système :

sudo journalctl -xe

Ces commandes doivent devenir des réflexes. Quand un site ne répond plus, commencez par vérifier si le service tourne, si sa configuration est valide et si les logs indiquent une erreur précise.

Automatiser des tâches avec cron

cron permet d’exécuter automatiquement des commandes à des horaires définis. Pour éditer les tâches de l’utilisateur courant :

crontab -e

Exemple : exécuter un script de sauvegarde tous les jours à 2 h 30 :

30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Les tâches automatisées sont utiles pour les sauvegardes, la maintenance, le nettoyage de fichiers temporaires ou l’envoi de rapports. Documentez-les toujours, car une tâche cron oubliée peut provoquer des effets difficiles à diagnostiquer.

Installer une base de données sur le serveur

Installez une base de données uniquement si le serveur en a besoin. Pour WordPress et de nombreux projets PHP, MariaDB est un choix courant. Pour des applications plus complexes, PostgreSQL peut être préférable. Dans tous les cas, limitez l’accès réseau, créez un utilisateur dédié et sauvegardez régulièrement les données.

Un serveur web n’a pas toujours besoin d’une base de données. Un site statique peut fonctionner sans MySQL, MariaDB ou PostgreSQL. En revanche, WordPress, WooCommerce, de nombreux CMS et la plupart des applications web dynamiques en ont besoin.

Installer MariaDB

Sur Ubuntu ou Debian :

sudo apt install mariadb-server -y

sudo systemctl enable --now mariadb

sudo systemctl status mariadb

Lancez ensuite l’assistant de sécurisation :

sudo mysql_secure_installation

Connectez-vous à MariaDB :

sudo mariadb

Créez une base et un utilisateur :

CREATE DATABASE site_db CHARACTERSET utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATEUSER'site_user'@'localhost' IDENTIFIED BY'mot_de_passe_solide';

GRANTALLPRIVILEGESON site_db.* TO'site_user'@'localhost';

FLUSH PRIVILEGES;

EXIT;

Pour un serveur simple, gardez la base accessible uniquement en local. Évitez d’exposer MySQL ou MariaDB publiquement sur Internet sauf nécessité précise et configuration avancée.

Installer PostgreSQL

PostgreSQL convient très bien aux applications qui demandent un moteur relationnel robuste et avancé :

sudo apt install postgresql postgresql-contrib -y

sudo systemctl enable --now postgresql

Créer un utilisateur et une base dépendra de votre application. Là encore, le principe de base reste le même : un utilisateur par application, un mot de passe fort, des permissions limitées et des sauvegardes testées.

Mettre en place sauvegardes, logs et monitoring

Un serveur Linux n’est pas prêt pour la production tant que les sauvegardes, les logs et la surveillance ne sont pas organisés. Il faut sauvegarder les fichiers et les bases, tester la restauration, surveiller le disque, la mémoire, le CPU, les services critiques et configurer une rotation des journaux pour éviter la saturation.

La configuration initiale protège l’accès au serveur. Les sauvegardes protègent le projet. Beaucoup d’incidents deviennent graves non pas parce qu’un service tombe en panne, mais parce qu’aucune restauration propre n’a été prévue.

Sauvegarder les fichiers avec rsync

Exemple de sauvegarde vers un autre serveur :

rsync -aAX--delete /var/www/ backup@serveur-backup:/backups/vps-web-01/www/

Cette commande synchronise le dossier /var/www/ vers un serveur distant. L’option --delete supprime côté destination les fichiers supprimés côté source. Elle doit donc être utilisée avec prudence.

Sauvegarder une base MariaDB

Exemple avec mysqldump :

mysqldump -u site_user -p site_db > site_db_$(date +%F).sql

Compressez ensuite le fichier :

gzip site_db_$(date +%F).sql

Pour un vrai serveur de production, automatisez la sauvegarde, stockez-la hors du serveur principal et testez régulièrement la restauration. Une sauvegarde non testée est seulement une hypothèse.

Surveiller les ressources

Commandes utiles :

uptime

free -h

df -h

lsblk

top

Si htop est installé :

htop

Pour voir les ports en écoute :

sudo ss -tulpn

Pour identifier les gros dossiers :

sudo du -sh /* 2>/dev/null

sudo du -sh /var/* 2>/dev/null

Ces commandes permettent de diagnostiquer rapidement les problèmes de RAM, de CPU, de disque plein ou de service exposé par erreur.

Gérer la rotation des logs

Les logs sont indispensables, mais ils peuvent remplir un disque si rien n’est prévu. Linux utilise généralement logrotate pour compresser, archiver et supprimer les anciens journaux.

Vérifier la présence de logrotate :

logrotate --version

Consulter les configurations :

ls /etc/logrotate.d/

Pour les journaux systemd, vous pouvez réduire l’espace utilisé :

sudo journalctl --disk-usage

sudo journalctl --vacuum-time=14d

Ne supprimez pas les logs au hasard. Ils sont souvent votre meilleure source d’information après une panne, une tentative d’intrusion ou une erreur applicative.

Sécuriser davantage un serveur Linux

Après la configuration de base, améliorez la sécurité avec les mises à jour automatiques, des permissions strictes, des services minimaux, des sauvegardes hors serveur, une surveillance des connexions et une documentation claire. La sécurité d’un serveur Linux repose moins sur un outil unique que sur l’accumulation de bonnes pratiques simples.

Une fois SSH, le pare-feu et Fail2Ban configurés, vous pouvez renforcer le serveur avec quelques mesures complémentaires.

Activer les mises à jour de sécurité automatiques

Sur Ubuntu ou Debian :

sudo apt install unattended-upgrades -y

sudo dpkg-reconfigure unattended-upgrades

Cette configuration permet d’installer automatiquement certaines mises à jour de sécurité. Pour un serveur critique, surveillez tout de même les changements et prévoyez des fenêtres de maintenance.

Sur AlmaLinux, Rocky Linux ou RHEL, l’équivalent peut passer par dnf-automatic :

sudo dnf install dnf-automatic -y

sudo systemctl enable --now dnf-automatic.timer

Supprimer les services inutiles

Listez les services actifs :

systemctl --type=service--state=running

Si un service n’est pas nécessaire, désactivez-le au lieu de le laisser exposé. Moins un serveur exécute de services, plus il est simple à auditer.

Vérifier les comptes utilisateurs

Afficher les utilisateurs ayant un shell interactif :

awk-F: '$7 ~ /(bash|sh|zsh)$/ {print $1, $7}' /etc/passwd

Vérifiez régulièrement que seuls les comptes attendus peuvent se connecter. Supprimez ou verrouillez les comptes inutilisés.

Protéger les permissions

Pour un site web, évitez de donner des droits d’écriture globaux. Les commandes comme chmod 777 doivent être considérées comme des solutions dangereuses, sauf cas temporaire et parfaitement compris.

Exemple de droits raisonnables pour un dossier web statique :

sudochown-R www-data:www-data /var/www/exemple.com

sudofind /var/www/exemple.com -type d -execchmod755 {} \;

sudofind /var/www/exemple.com -type f -execchmod644 {} \;

Adaptez ces droits selon votre stack, notamment si une application doit écrire dans certains dossiers.

Dépanner un serveur Linux

Pour dépanner un serveur Linux, vérifiez dans l’ordre la connectivité, le pare-feu, l’état des services, les ports ouverts, les logs, l’espace disque, la mémoire et la charge CPU. Les commandes clés sont systemctl status, journalctl, ss -tulpn, df -h, free -h, top et curl -I.

Le dépannage doit suivre une méthode. Ne modifiez pas dix paramètres en même temps. Vérifiez une hypothèse, observez le résultat, puis passez à l’étape suivante.

Problème : impossible de se connecter en SSH

Depuis votre ordinateur local :

ssh-vvv joseph@votre_ip

Cette commande affiche le détail de la connexion. Vérifiez ensuite, via la console de l’hébergeur si nécessaire :

sudo systemctl status ssh

sudo systemctl status sshd

sudo ufw status verbose

sudo journalctl -ussh-n100

Causes fréquentes : mauvaise clé privée, utilisateur incorrect, pare-feu trop strict, service SSH arrêté, port SSH modifié, règle cloud firewall oubliée chez l’hébergeur.

Problème : le site est inaccessible

Commencez par vérifier le DNS :

dig +short exemple.com

Puis testez le serveur web :

curl-I http://exemple.com

sudo systemctl status nginx

sudo nginx -t

sudo ss -tulpn | grep':80\|:443'

Si Nginx est actif mais que le navigateur ne répond pas, vérifiez le pare-feu local et le firewall de l’hébergeur. Beaucoup de VPS ont deux niveaux de filtrage : celui de Linux et celui du panneau cloud.

Problème : un service ne démarre pas

Utilisez :

sudo systemctl status nom-du-service

sudo journalctl -u nom-du-service -n100

Le message d’erreur indique souvent un fichier de configuration invalide, un port déjà utilisé, une permission incorrecte ou une dépendance manquante.

Problème : le disque est plein

Vérifiez l’espace :

df -h

Cherchez les gros dossiers :

sudo du -h--max-depth=1 /var | sort-h

sudo du -h--max-depth=1 /var/log | sort-h

Nettoyez les anciens paquets sur Ubuntu/Debian :

sudo apt autoremove -y

sudo apt clean

Réduisez les journaux systemd si nécessaire :

sudo journalctl --vacuum-time=7d

Ne supprimez jamais un fichier système sans comprendre son rôle. Si les logs grossissent trop vite, corrigez la cause au lieu de seulement supprimer le symptôme.

Problème : CPU ou RAM trop élevés

Affichez la charge :

uptime

top

free -h

Avec htop, vous pourrez trier les processus par CPU ou mémoire. Si un service consomme trop, consultez ses logs et vérifiez s’il reçoit un trafic anormal, s’il boucle sur une erreur ou s’il manque de ressources.

Quelles erreurs éviter quand on configure un serveur Linux ?

Les erreurs les plus fréquentes sont de garder root accessible en SSH, ouvrir trop de ports, utiliser chmod 777, installer des services inutiles, oublier les sauvegardes et ne pas tester le redémarrage. Ces erreurs peuvent provoquer une panne, une faille de sécurité ou une perte de données évitable.

• La première erreur consiste à garder la connexion root active. Le compte root possède tous les droits ; il doit être remplacé par un utilisateur non-root avec sudo, puis désactivé pour les connexions SSH directes.

• La deuxième erreur est d’ouvrir trop de ports. Un serveur web classique a souvent besoin de SSH, HTTP et HTTPS. Tout le reste doit être fermé tant qu’un service précis ne le justifie pas.

• Une autre erreur fréquente est d’utiliser chmod 777 pour résoudre un problème de permission. Cette commande donne tous les droits à tout le monde. Elle peut exposer des fichiers sensibles ou permettre à une application compromise d’écrire partout.

Il faut aussi éviter d’installer trop de services. Chaque service actif augmente la surface d’attaque et complique la maintenance. Installez uniquement ce qui est nécessaire au projet.

Enfin, ne confondez pas snapshot et sauvegarde. Un snapshot aide à revenir à un état précédent, mais une vraie sauvegarde doit être externalisée, automatisée et testée. Avant de considérer un serveur comme prêt, redémarrez-le et vérifiez que SSH, le pare-feu, le site, la base de données et les certificats fonctionnent toujours.

Checklist finale de configuration

Un serveur Linux est correctement préparé quand l’accès root direct est désactivé, l’utilisateur sudo fonctionne, SSH par clé est testé, le pare-feu limite les ports, Fail2Ban est actif, les services nécessaires démarrent automatiquement, HTTPS fonctionne, les sauvegardes sont externalisées et les logs sont surveillés.

Avant de considérer le serveur comme prêt, vérifiez cette checklist :

• Le système est à jour.
• Un utilisateur non-root avec sudo existe.
• La connexion SSH par clé fonctionne.
• La connexion root directe est désactivée.
• L’authentification par mot de passe est désactivée si les clés SSH sont opérationnelles.
• Le pare-feu est actif.
• Seuls les ports nécessaires sont ouverts.
• Fail2Ban protège SSH.
• Le fuseau horaire est correct.
• Le nom d’hôte est clair.
• Nginx ou Apache fonctionne si le serveur héberge un site.
• HTTPS est installé et le renouvellement du certificat est testé.
• Les services utiles sont activés au démarrage.
• Les sauvegardes existent hors du serveur principal.
• Une restauration de test a été effectuée.
• Les logs sont consultables et leur rotation est configurée.
• Les ressources disque, RAM et CPU sont surveillées.
• Les accès utilisateurs sont documentés.
• Les commandes critiques sont notées dans une documentation interne.

Cette checklist peut être reprise après chaque nouveau VPS ou après une migration. Elle évite les oublis classiques qui provoquent des incidents quelques semaines plus tard.

FAQ

Quel serveur Linux choisir pour débuter ?

Ubuntu Server LTS est généralement le meilleur choix pour débuter. Il bénéficie d’un support long, d’une documentation abondante et d’une excellente compatibilité avec les guides d’hébergement web. Debian Stable est aussi un très bon choix si vous voulez un système sobre et stable.

Quelle est la première chose à faire après l’installation ?

La première étape consiste à se connecter en SSH, vérifier la distribution, mettre à jour le système puis créer un utilisateur non-root avec sudo. Ensuite, configurez les clés SSH, le pare-feu et Fail2Ban avant d’installer des services exposés sur Internet.

Faut-il encore utiliser CentOS pour un nouveau serveur ?

CentOS Linux classique n’est plus recommandé pour un nouveau serveur. CentOS Linux 7 est arrivé en fin de vie le 30 juin 2024. Pour une alternative compatible avec l’écosystème Red Hat, utilisez plutôt AlmaLinux, Rocky Linux ou RHEL.

UFW ou firewalld : lequel choisir ?

UFW est le choix le plus simple sur Ubuntu et Debian. Firewalld est plus courant sur les distributions de la famille Red Hat comme AlmaLinux, Rocky Linux et RHEL. Les deux outils servent à contrôler les ports ouverts et à limiter les connexions entrantes.

Faut-il désactiver la connexion root ?

Oui, sur un serveur exposé à Internet, il est préférable de désactiver la connexion SSH directe au compte root. Utilisez un utilisateur non-root avec sudo. Cette approche réduit les risques liés aux attaques automatisées et aux erreurs d’administration.

Comment savoir si un service fonctionne ?

Utilisez systemctl status nom-du-service pour vérifier son état. Si le service ne démarre pas, consultez les logs avec journalctl -u nom-du-service. Pour un serveur web, testez aussi la configuration avec nginx -t ou apachectl configtest selon le logiciel utilisé.

Comment sécuriser rapidement un VPS Linux ?

Mettez le système à jour, créez un utilisateur sudo, activez les clés SSH, désactivez root, configurez UFW ou firewalld, installez Fail2Ban, ouvrez uniquement les ports nécessaires, activez HTTPS et prévoyez des sauvegardes hors serveur.

Quelle commande utiliser pour voir les ports ouverts ?

La commande la plus utile est :

sudo ss -tulpn

Elle affiche les ports TCP et UDP en écoute ainsi que les processus associés. C’est indispensable pour vérifier qu’un service écoute bien sur le bon port ou qu’un port sensible n’est pas exposé par erreur.

Quelle différence entre un VPS et un serveur dédié ?

Un VPS est une machine virtuelle hébergée sur un serveur physique partagé avec d’autres clients. Un serveur dédié est une machine physique réservée à un seul client. Le VPS est souvent moins cher et plus flexible, tandis que le dédié offre plus d’isolation et de ressources garanties.

Faut-il installer une interface graphique sur un serveur Linux ?

Dans la majorité des cas, non. Une interface graphique consomme des ressources et augmente la surface d’attaque. Pour un serveur web, une administration en ligne de commande via SSH est généralement plus légère, plus rapide et plus adaptée.

Conclusion

Configurer un serveur Linux demande de la méthode plus que de la magie. La bonne approche consiste à sécuriser l’accès, limiter les privilèges, mettre à jour le système, n’ouvrir que les ports nécessaires, installer les services avec sobriété, surveiller les logs et prévoir des sauvegardes testées.

Si vous débutez, commencez avec Ubuntu Server LTS ou Debian Stable sur un VPS de test. Reproduisez les dix étapes de configuration, cassez volontairement quelques configurations en environnement non critique, puis apprenez à les réparer avec systemctl, journalctl, ss, df, free et top. Cette pratique vous rendra beaucoup plus autonome qu’une simple lecture théorique.

Pour un site web, le chemin le plus courant est clair : serveur à jour, utilisateur sudo, SSH par clé, pare-feu, Fail2Ban, Nginx ou Apache, HTTPS, sauvegardes et monitoring. Une fois cette base maîtrisée, vous pourrez aller plus loin avec Docker, un reverse proxy, un CDN, une base de données séparée, de la supervision avancée ou une architecture multi-serveurs.