[UPDATE 2026] Configuration d’un serveur dédié
Nouveau serveur dédié : Debian 12, clé SSH (PuTTY), Docker
Retour d’expérience + checklist de configuration : une base propre, sécurisée et maintenable pour héberger vos services Docker sur une seule machine.
Ce guide utilise des placeholders (entre doubles accolades) que vous devez
remplacer par vos propres valeurs. Si vous utilisez une IA pour adapter ce document,
fournissez-lui le tableau ci-dessous avec vos paramètres — elle générera
automatiquement une version personnalisée.
| Placeholder | Description | Exemple |
|---|---|---|
{{PORT_SSH}} |
Port SSH personnalisé (éviter 22) | 38592 |
{{USER_SSH}} |
Utilisateur SSH principal (non-root) | debian |
{{IP_SERVEUR}} |
Adresse IP publique du serveur | 203.0.113.10 |
1) Installation : Debian 12 sur OVHcloud
L’objectif est simple : partir sur une installation propre, sécuriser l’accès dès le début (clé SSH),
puis préparer la suite (Docker, migration progressive des services).
On part sur Debian 12 (Bookworm) : stable, moderne, et très compatible avec une stack Docker propre.
Côté partitionnement, on garde volontairement un schéma minimal pour laisser le maximum d’espace aux données :
/boot: 1024 MiO (1 Gio)swap: 4096 MiO par disque → 2 × 4 Gio = 8 Gio total/: le reste (taille restante)
L’installation se fait depuis le manager OVHcloud : choix de l’OS, personnalisation des partitions, et ajout de la clé SSH publique directement dans le formulaire d’installation.
2) Accès SSH sécurisé (PuTTY)
Connexion avec PuTTY via clé SSH (ED25519) + passphrase : on évite le « mot de passe seul » et on réduit les risques.
À faire juste après : installer les outils de base.
|
1 2 |
sudo apt update sudo apt install -y htop curl ca-certificates gnupg git |
3) Docker (installation fiable sur Debian 12)
Objectif : avoir Docker + Compose de manière reproductible.
Sur Debian, il y a deux voies : les paquets Debian (simple), ou le dépôt officiel Docker (plus « standard » et souvent plus à jour).
Installation Docker (paquets Debian)
Pour rester 100 % Debian :
|
1 2 3 |
sudo apt update sudo apt install -y docker.io docker-compose sudo systemctl enable --now docker |
Vérifier :
|
1 2 3 |
docker --version docker-compose --version sudo systemctl status docker --no-pager |
Si tu vois Failed to restart docker.service: Unit docker.service not found. : Docker n’est tout simplement pas installé (ou l’install a échoué).
Vérifie avec dpkg -l | grep -E 'docker|containerd', puis relance l’installation (après sudo apt update).
Option B — Dépôt officiel Docker (recommandé si paquets manquants)
Si tu as Unable to locate package docker-compose-plugin : ça arrive quand les dépôts ne sont pas complets,
ou quand on veut Compose v2 (plugin) plutôt que l’ancien binaire docker-compose.
La voie la plus robuste est d’installer via le dépôt officiel Docker.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
# 1) Nettoyage (si tu as déjà tenté des installs) sudo apt remove -y docker.io docker-compose docker-compose-plugin || true # 2) Prérequis sudo apt update sudo apt install -y ca-certificates curl gnupg # 3) Clé + dépôt Docker (Debian) sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \ https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 4) Installation Docker Engine + plugins sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 5) Service sudo systemctl enable --now docker |
Vérifier :
|
1 2 3 |
docker --version docker compose version sudo systemctl status docker --no-pager |
Ne pas exécuter Docker en root (optionnel)
|
1 2 |
sudo usermod -aG docker $USER newgrp docker |
Attention : ajouter un utilisateur au groupe docker lui donne un accès équivalent à root
sur la machine (il peut monter n’importe quel répertoire système dans un conteneur).
Sur un serveur mono-administrateur, c’est acceptable. Ne jamais ajouter un utilisateur non fiable à ce groupe.
Limiter les logs Docker (important)
Sur une partition unique, la règle : limiter les logs Docker pour éviter de remplir le disque.
|
1 2 |
sudo mkdir -p /etc/docker sudo nano /etc/docker/daemon.json |
|
1 2 3 4 5 6 7 |
{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } } |
|
1 |
sudo systemctl restart docker |
4) Checklist « première connexion » + sécurité
Pour construire une base propre, on s’appuie sur les bonnes pratiques Debian 12 + Docker.
L’idée : faire le minimum utile, mais le faire bien.
4.1 Première connexion : hygiène système
|
1 2 3 4 |
# Mise à jour de base sudo apt update sudo apt upgrade -y sudo apt autoremove -y |
|
1 2 |
# Outils pratiques (à adapter) sudo apt install -y nano htop curl ca-certificates gnupg git net-tools |
Sur certains guides, on conseille de mettre la langue du serveur en anglais et d’avoir une SWAP « raisonnable »
dès l’installation (ex : 4 Go) — pratique pour éviter les mauvaises surprises. Si tu as déjà mis de la swap via l’installateur OVH, c’est OK.
4.2 Mises à jour de sécurité automatiques
Sur un serveur de production qui héberge plusieurs services, tu ne vas pas te connecter tous les jours pour faire apt upgrade.
La solution : unattended-upgrades, qui applique automatiquement les patchs de sécurité Debian (uniquement debian-security, pas les mises à jour normales).
|
1 2 |
sudo apt install -y unattended-upgrades apt-listchanges sudo dpkg-reconfigure -plow unattended-upgrades |
Répondre Oui à la question. Vérifier que c’est actif :
|
1 |
cat /etc/apt/apt.conf.d/20auto-upgrades |
Tu dois voir :
|
1 2 |
APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; |
Les mises à jour automatiques ne concernent que les correctifs de sécurité. Les montées de version majeures de paquets restent manuelles — c’est le comportement souhaité.
4.3 Sécurité SSH : réduire la surface d’attaque
Minimum vital : clé SSH, changer le port, et empêcher le login root direct.
|
1 |
sudo nano /etc/ssh/sshd_config |
|
1 2 3 4 5 6 |
# Exemple Port {{PORT_SSH}} PermitRootLogin no PasswordAuthentication no # (optionnel) n'autoriser qu'un utilisateur AllowUsers {{USER_SSH}} |
|
1 |
sudo systemctl restart ssh |
Procédure pour changer le port SSH sans se verrouiller :
- Modifier
sshd_configavec le nouveau port (ex :{{PORT_SSH}}) - Redémarrer SSH :
sudo systemctl restart ssh - Sans fermer la session actuelle, ouvrir un 2e PuTTY sur le port
{{PORT_SSH}} - Si ça marche → fermer l’ancienne session
- Si ça ne marche pas → corriger depuis la session encore ouverte
4.4 Protection anti-bruteforce (Fail2ban)
|
1 |
sudo apt install -y fail2ban |
Installer Fail2ban ne suffit pas : il faut configurer une jail SSH.
On crée jail.local (ne jamais modifier jail.conf, il est écrasé à chaque mise à jour) :
|
1 |
sudo nano /etc/fail2ban/jail.local |
|
1 2 3 4 5 6 7 |
[sshd] enabled = true port = {{PORT_SSH}} maxretry = 3 findtime = 600 bantime = 3600 backend = systemd |
- 3 tentatives en 10 minutes → IP bannie pendant 1 heure
- On précise le port custom (sinon Fail2ban surveille le port 22 par défaut)
backend = systemd: indispensable sur Debian 12, qui utilise journald par défaut (pas de/var/log/auth.log)
|
1 2 |
sudo systemctl enable --now fail2ban sudo systemctl restart fail2ban |
Vérifier que la jail est active :
|
1 |
sudo fail2ban-client status sshd |
4.4.1 Audit de durcissement avec Lynis (optionnel)
Lynis analyse la configuration globale du serveur (SSH, permissions, kernel, services…) et donne un score de durcissement avec des recommandations concrètes. Plus utile qu’un simple scanner de rootkits.
|
1 2 |
sudo apt install -y lynis sudo lynis audit system |
Le rapport s’affiche directement dans le terminal. Les suggestions sont classées par priorité. Pas besoin de le lancer régulièrement — une fois après la configuration initiale, puis après des changements majeurs.
4.5 2FA sur SSH (TOTP via PAM) — pour aller plus loin
Avant de commencer : vérifie que tu as accès à la console KVM/IPMI d’OVH (dans le manager).
C’est ton filet de sécurité si tu te verrouilles. Garde aussi une session SSH ouverte pendant toute la configuration.
Tu peux ajouter une 2FA (code TOTP) sur SSH. Le schéma le plus pratique : clé SSH + TOTP (sans mot de passe).
Étape 1 : Installer et générer le secret TOTP
|
1 2 3 4 |
sudo apt install -y libpam-google-authenticator # Générer un secret TOTP pour ton utilisateur google-authenticator |
Réponds aux questions. À la fin, tu obtiens un QR code à scanner avec ton appli (Google Authenticator, Authy, etc.)
et des codes de secours.
Les codes de secours sont critiques. Sauvegarde-les hors du serveur (gestionnaire de mots de passe, coffre-fort).
Si tu perds ton téléphone et tes codes de secours, tu es verrouillé.
Étape 2 : Configurer PAM
|
1 |
sudo nano /etc/pam.d/sshd |
Ajouter en haut (ou près des autres règles auth) :
|
1 |
auth required pam_google_authenticator.so |
Pour éviter que PAM demande aussi le mot de passe (on veut clé SSH + TOTP uniquement), commenter la ligne suivante si elle est présente :
|
1 |
#@include common-auth |
Étape 3 : Configurer SSH
|
1 |
sudo nano /etc/ssh/sshd_config |
Vérifier / ajouter :
|
1 2 3 4 5 6 |
PasswordAuthentication no UsePAM yes KbdInteractiveAuthentication yes # Exiger 2 facteurs : clé + OTP AuthenticationMethods publickey,keyboard-interactive |
|
1 |
sudo systemctl restart ssh |
Étape 4 : Tester (sans fermer ta session !)
Ouvre un 2e terminal et teste :
|
1 |
ssh -p {{PORT_SSH}} {{USER_SSH}}@{{IP_SERVEUR}} |
Tu dois voir :
- Authentification par clé (automatique)
- Demande du code TOTP (« Verification code: »)
- Connexion réussie
Si ça ne fonctionne pas, corrige depuis ta session encore ouverte. En dernier recours, utilise la console KVM/IPMI d’OVH.
Conseil : tu peux d’abord activer le TOTP sur un seul utilisateur via un bloc Match User dans sshd_config, puis élargir une fois que tout fonctionne.
4.6 Problème de perte de connexion sur un OVH Kimsufi
Retour d’expérience : sur certains Kimsufi, le serveur peut perdre la connexion toutes les ~15 minutes,
comme s’il se mettait en veille (plus de ping).
Le diagnostic OVH indique que le serveur se met en « veille prolongée » après quelques minutes.
|
1 2 |
Diagnostic software Le serveur se met en veille prolongée après quelques minutes de fonctionnement et arrête de pinguer. |
Solution : désactiver la suspension/hibernation (inutile sur un serveur dédié) :
|
1 |
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target |
Pour réactiver la mise en veille (en pratique, rarement utile sur un dédié) :
|
1 |
sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target |
4.7 Limiter l’exécution de apt/dpkg (optionnel)
Sur un serveur multi-utilisateurs, on peut limiter l’exécution de apt/apt-get et dpkg à un groupe d’admins.
Attention : si tu ne maîtrises pas, évite — ça peut surprendre certains scripts/outils.
|
1 2 3 4 5 6 7 |
# Créer un groupe "pkgadmin" et y ajouter ton utilisateur sudo groupadd -f pkgadmin sudo usermod -aG pkgadmin $USER # Restreindre l'exécution aux membres du groupe (root reste OK) sudo chgrp pkgadmin /usr/bin/apt /usr/bin/apt-get /usr/bin/dpkg sudo chmod 750 /usr/bin/apt /usr/bin/apt-get /usr/bin/dpkg |
Si tu utilises Docker/CI ou des scripts d’automatisation, teste avant de généraliser. Et garde toujours une session SSH ouverte pendant les changements.
À suivre
La base est en place : Debian 12, accès SSH sécurisé, Docker prêt, et une checklist de durcissement appliquée.
Dans les prochains articles, on verra :
- Firewall et panel d’administration (VestaCP / HestiaCP)
- Sauvegardes : stratégie, outils et automatisation
- Migration des services Docker vers le nouveau serveur
0 commentaire