isUnknown d0a243509d Refonte complète des guides VPS et ajout guides Kirby/CI-CD

- Restructuration VPS : guides rapide et complet séparés
- Nouveau guide Vim essentiel pour administration serveur
- Guide déploiement Kirby (VirtualHost, multi-sites, permissions)
- Guide CI/CD Kirby (GitLab CI, Forgejo Actions, Docker)
- Anonymisation complète (sécurité pour publication publique)
- Priorité aux solutions libres (Forgejo, GitLab)
- README général et navigation améliorée

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

2026-02-13 14:58:13 +01:00

38 KiB

Raw Blame History

Mettre en place un serveur VPS

Guide complet pour configurer et sécuriser un serveur VPS depuis zéro.

📋 Table des matières

Prérequis
Première connexion
Sécurisation de base
Installation d'un serveur web
Déploiement
Maintenance
Ressources

Prérequis

Ce dont vous avez besoin

Un VPS chez un hébergeur (OVH, Hetzner, DigitalOcean, Infomaniak, etc.)
Une adresse IP publique (fournie par l'hébergeur)
Un terminal (macOS/Linux)
1h-2h devant vous

📝 Note sur Vim : Ce guide utilise vim pour éditer les fichiers de configuration. Vim est l'éditeur standard présent sur tous les serveurs Linux.

Débutant avec Vim ? → Consultez vim-guide-essentiel.md (15 min de lecture)

Commandes minimales pour suivre ce guide :

i : Passer en mode édition
Esc : Sortir du mode édition
:wq : Sauvegarder et quitter
:q! : Quitter sans sauvegarder

Informations à noter

Avant de commencer, notez ces informations fournies par votre hébergeur :

IP du VPS : _______________
Utilisateur initial : _______ (root, ubuntu, admin, ou autre)
Mot de passe/clé SSH : _______________
Distribution : Debian / Ubuntu (recommandé)

⚠️ Deux types d'accès VPS

Votre configuration initiale dépend de votre hébergeur :

Type A - Accès root direct (OVH, Hetzner, DigitalOcean)

Connexion : ssh root@IP
Vous devez créer vous-même un utilisateur non-root
Suivez toutes les étapes ci-dessous

Type B - Utilisateur sudo pré-configuré (Infomaniak, hébergeurs managed)

Connexion : ssh ubuntu@IP (ou autre utilisateur fourni)
L'utilisateur a déjà les droits sudo
Sautez l'étape 3 (création d'utilisateur)
Pour les commandes root, utilisez sudo devant chaque commande

Première connexion

Étape 1 : Se connecter au VPS

Pourquoi ? Établir la première connexion sécurisée à votre serveur et vérifier que tout fonctionne.

Type A - Connexion root :

ssh root@<adresse-IP>
# Entrez le mot de passe fourni par l'hébergeur

Type B - Connexion utilisateur sudo (Infomaniak, etc.) :

ssh ubuntu@<adresse-IP>
# Ou : ssh admin@<adresse-IP>
# Selon l'utilisateur fourni par votre hébergeur

Première connexion :

# Le serveur vous demande de confirmer son empreinte SSH
The authenticity of host 'xxx.xxx.xxx.xxx' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no)?

# Tapez "yes" et Entrée
# Ceci enregistre le serveur comme connu et évite les attaques MITM

Si vous êtes connecté en root (Type A), changez le mot de passe :

passwd
# Entrez un mot de passe FORT (20+ caractères, complexe)
# Pourquoi ? Le mot de passe initial est souvent simple ou envoyé par email (non sécurisé)

Si vous avez un utilisateur sudo (Type B), vérifiez vos droits :

sudo -v
# Doit répondre sans erreur
# Si demandé, entrez le mot de passe sudo fourni par l'hébergeur

Étape 2 : Mettre à jour le système

Pourquoi ? Les images serveur contiennent souvent des paquets obsolètes avec des failles de sécurité. La première chose à faire est de tout mettre à jour.

Type A (root) :

# Mettre à jour la liste des paquets disponibles
apt update

# Installer toutes les mises à jour de sécurité et correctifs
apt upgrade -y

# Supprimer les paquets obsolètes qui ne sont plus nécessaires
apt autoremove -y

Type B (sudo) :

# Même chose mais avec sudo devant chaque commande
sudo apt update
sudo apt upgrade -y
sudo apt autoremove -y

💡 Astuce : Combinez les commandes pour gagner du temps :

sudo apt update && sudo apt upgrade -y && sudo apt autoremove -y

Sécurisation de base

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

⚠️ Type B (Infomaniak, etc.) : SAUTEZ CETTE ÉTAPE - vous avez déjà un utilisateur sudo

Type A uniquement (accès root direct) :

Pourquoi ? Le compte root a tous les privilèges sans restriction. Une simple erreur de commande (ex: rm -rf /) peut détruire tout le système. Un utilisateur non-root avec sudo est plus sûr :

Vous devez taper sudo avant chaque commande sensible (temps de réflexion)
Les logs montrent qui a fait quoi (traçabilité)
Les scripts ne peuvent pas accidentellement tout casser

Création de l'utilisateur :

# Créer un utilisateur (remplacez "monuser" par votre nom)
adduser monuser

# Le système vous demande :
# - Un mot de passe (FORT, 20+ caractères)
# - Des infos optionnelles (nom complet, etc.) - appuyez sur Entrée pour ignorer

# Ajouter l'utilisateur au groupe sudo (droits administrateur)
usermod -aG sudo monuser

# Vérifier que l'utilisateur est bien dans le groupe sudo
groups monuser
# Sortie attendue : monuser : monuser sudo

💡 Note : Choisissez un nom d'utilisateur :

Simple et court (ex: votre prénom)
Pas "admin" ou "user" (trop prévisible pour les attaquants)
Sans caractères spéciaux

Étape 4 : Configurer l'authentification par clé SSH

Pourquoi ? Les mots de passe peuvent être :

Devinés par force brute (des milliers de tentatives par jour)
Interceptés sur un réseau compromis
Oubliés ou réutilisés

Les clés SSH sont :

Mathématiquement impossibles à deviner (256 bits d'entropie)
Jamais transmises sur le réseau (seule une signature l'est)
Uniques par machine (pas de réutilisation)

⚠️ Si votre hébergeur (Type B) a déjà configuré une clé SSH à la création du VPS, SAUTEZ CETTE ÉTAPE

1️⃣ Sur votre machine locale (pas le VPS) : Créer ou vérifier votre clé SSH

# Vérifier si vous avez déjà une clé SSH
ls -la ~/.ssh/id_*.pub

# Si vous voyez "id_ed25519.pub" ou "id_rsa.pub", vous avez déjà une clé ✅
# Sinon, créez-en une :

ssh-keygen -t ed25519 -C "votre-email@example.com"

# Questions posées :
# "Enter file in which to save the key" → Appuyez sur Entrée (emplacement par défaut)
# "Enter passphrase" → Appuyez sur Entrée (pas de passphrase, ou tapez-en une si vous voulez plus de sécurité)
# "Enter same passphrase again" → Appuyez sur Entrée

# Afficher votre clé publique
cat ~/.ssh/id_ed25519.pub
# Copiez TOUTE la ligne (commence par "ssh-ed25519 AAAA..." et finit par votre email)

💡 Passphrase ou pas ?

Sans passphrase : Connexion automatique (pratique pour scripts)
Avec passphrase : Protection supplémentaire si quelqu'un vole votre ordinateur

2️⃣ Sur le VPS : Ajouter votre clé publique

Type A (connecté en root) :

# Passer à votre utilisateur
su - monuser

# Créer le dossier .ssh avec les bons droits
mkdir -p ~/.ssh
chmod 700 ~/.ssh

# Créer le fichier authorized_keys
vim ~/.ssh/authorized_keys
# Appuyez sur 'i' pour passer en mode insertion
# Collez votre clé publique (Cmd+V ou Ctrl+Shift+V)
# Appuyez sur Esc puis tapez :wq et Entrée pour sauvegarder et quitter

# Définir les bons droits (important pour la sécurité SSH)
chmod 600 ~/.ssh/authorized_keys

# Retour à root
exit

Type B (connecté avec votre utilisateur sudo) :

# Vous êtes déjà votre utilisateur, pas besoin de su -

# Créer le dossier .ssh avec les bons droits
mkdir -p ~/.ssh
chmod 700 ~/.ssh

# Créer le fichier authorized_keys
vim ~/.ssh/authorized_keys
# Appuyez sur 'i' pour passer en mode insertion
# Collez votre clé publique (Cmd+V ou Ctrl+Shift+V)
# Appuyez sur Esc puis tapez :wq et Entrée pour sauvegarder et quitter

# Définir les bons droits
chmod 600 ~/.ssh/authorized_keys

3️⃣ Tester la connexion par clé SSH

# Depuis votre machine locale (ouvrez un NOUVEAU terminal)
ssh monuser@<adresse-IP>
# Ou : ssh ubuntu@<adresse-IP> (selon votre utilisateur)

# ✅ Vous devriez être connecté SANS taper de mot de passe
# ❌ Si on vous demande un mot de passe, vérifiez :
#    - Les droits : chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
#    - Que la clé publique est bien copiée (une seule ligne, pas de retour à la ligne)

💡 Astuce : Gardez votre ancienne session SSH ouverte au cas où quelque chose ne fonctionne pas !

Étape 5 : Sécuriser SSH

Pourquoi ? Par défaut, SSH accepte :

Les connexions root (cible n°1 des attaquants)
Les mots de passe (vulnérables aux attaques par force brute)
Le port 22 (scanné en permanence par des bots)

En durcissant SSH, vous bloquez 99% des attaques automatisées.

1️⃣ Éditer la configuration SSH

# Type A (root)
vim /etc/ssh/sshd_config

# Type B (sudo)
sudo vim /etc/ssh/sshd_config

2️⃣ Modifications à faire

Cherchez ces lignes dans le fichier (Ctrl+W pour chercher) et modifiez-les :

# Désactiver la connexion root par SSH
PermitRootLogin no
# Pourquoi ? 'root' est le seul nom d'utilisateur connu de tous les attaquants

# Désactiver l'authentification par mot de passe
PasswordAuthentication no
# Pourquoi ? Les bots tentent des milliers de mots de passe par jour

# Désactiver l'authentification par défi-réponse
ChallengeResponseAuthentication no
# Pourquoi ? Autre méthode d'authentification par mot de passe à désactiver

# S'assurer que l'authentification par clé est activée
PubkeyAuthentication yes
# Pourquoi ? C'est la seule méthode sûre que nous autorisons

# (Optionnel) Changer le port SSH
# Port 2222
# Pourquoi ? Les bots scannent le port 22 en priorité
# ⚠️ Si vous faites ça, pensez à autoriser le nouveau port dans le pare-feu !

💡 Conseil : Ne changez le port SSH que si vous comprenez bien ce que vous faites. C'est plus contraignant qu'utile pour un VPS personnel.

Type B uniquement - Si vous voulez désactiver le mot de passe mais garder root pour sudo :

# Gardez root activé mais seulement sans mot de passe
PermitRootLogin prohibit-password

3️⃣ Redémarrer SSH

# Type A (root)
systemctl restart sshd
systemctl status sshd

# Type B (sudo)
sudo systemctl restart sshd
sudo systemctl status sshd

4️⃣ ⚠️ TESTER AVANT DE FERMER LA SESSION

CRITIQUE : Si vous fermez votre session SSH actuelle avant de tester, vous risquez de vous enfermer dehors !

# GARDEZ votre session SSH actuelle OUVERTE
# Ouvrez un NOUVEAU terminal et testez :

ssh monuser@<adresse-IP>
# Ou : ssh ubuntu@<adresse-IP>
# Si port modifié : ssh -p 2222 monuser@<adresse-IP>

# ✅ Connexion OK ? Vous pouvez fermer l'ancienne session
# ❌ Connexion refuse ? Retournez dans l'ancienne session et corrigez

Si vous êtes bloqué :

La plupart des hébergeurs ont une "console VNC" dans leur interface web
Connectez-vous via la console et corrigez /etc/ssh/sshd_config

Étape 6 : Installer et configurer le pare-feu (UFW)

Pourquoi ? Sans pare-feu, tous les ports de votre serveur sont exposés à Internet. N'importe qui peut :

Scanner vos services (base de données, admin panels)
Exploiter des vulnérabilités
Accéder à des services non sécurisés

UFW (Uncomplicated Firewall) = pare-feu simple qui bloque tout sauf ce que vous autorisez explicitement.

1️⃣ Installer UFW

# Type A (root)
apt install ufw -y

# Type B (sudo)
sudo apt install ufw -y

2️⃣ Configurer les règles (IMPORTANT : dans cet ordre !)

# Ajouter sudo si Type B

# Définir la politique par défaut : TOUT BLOQUER
ufw default deny incoming
# Pourquoi ? Principe de sécurité : interdire par défaut, autoriser au cas par cas

# Autoriser les connexions sortantes (pour apt, wget, etc.)
ufw default allow outgoing
# Pourquoi ? Votre serveur doit pouvoir se connecter à Internet (mises à jour, APIs)

# ⚠️ CRITIQUE : Autoriser SSH AVANT d'activer UFW
ufw allow 22/tcp
# Si vous avez changé le port SSH (étape 5) :
# ufw allow 2222/tcp
# 🚨 Si vous oubliez ça, vous serez bloqué dehors !

# Autoriser HTTP et HTTPS (si vous installez un serveur web)
ufw allow 80/tcp
ufw allow 443/tcp
# Pourquoi ? Les visiteurs doivent pouvoir accéder à votre site

# Afficher les règles avant activation (vérification)
ufw show added

3️⃣ Activer le pare-feu

# Activer UFW
ufw enable
# Il vous demande confirmation (la connexion SSH peut être interrompue)
# Tapez 'y' puis Entrée

# Vérifier que tout fonctionne
ufw status verbose

# Résultat attendu :
# Status: active
# To                         Action      From
# --                         ------      ----
# 22/tcp                     ALLOW       Anywhere
# 80/tcp                     ALLOW       Anywhere
# 443/tcp                    ALLOW       Anywhere

✅ Si vous voyez ce résultat, c'est bon ! ❌ Si votre connexion SSH se coupe, vous avez oublié ufw allow 22/tcp

4️⃣ Commandes utiles UFW

# Voir les règles numérotées
sudo ufw status numbered

# Supprimer une règle (ex: règle n°3)
sudo ufw delete 3

# Autoriser un port spécifique (ex: pour une app Node.js)
sudo ufw allow 8080/tcp

# Autoriser une IP spécifique (ex: votre IP fixe pour un service admin)
sudo ufw allow from 203.0.113.0/24 to any port 3306
# Utile pour restreindre l'accès à MySQL/PostgreSQL

# Désactiver temporairement UFW
sudo ufw disable

# Réactiver
sudo ufw enable

# Réinitialiser (supprime toutes les règles)
sudo ufw reset

💡 Bonne pratique : N'ouvrez que les ports dont vous avez besoin. Si vous installez un nouveau service plus tard, ajoutez la règle à ce moment-là.

Étape 7 : Installer Fail2ban

Pourquoi ? Même avec SSH sécurisé, des bots vont :

Scanner votre serveur 24/7
Tenter des milliers de connexions SSH
Essayer des mots de passe courants
Saturer vos logs et ralentir le serveur

Fail2ban surveille les logs et bannit automatiquement les IP malveillantes.

Exemple concret :

2026-02-13 10:23:45 Failed password for root from 185.220.101.23
2026-02-13 10:23:47 Failed password for root from 185.220.101.23
2026-02-13 10:23:49 Failed password for root from 185.220.101.23
→ Fail2ban bannit 185.220.101.23 pendant 10 minutes (ou plus)

1️⃣ Installer Fail2ban

# Type A (root)
apt install fail2ban -y

# Type B (sudo)
sudo apt install fail2ban -y

2️⃣ Créer une configuration personnalisée

Pourquoi jail.local et pas jail.conf ?

jail.conf = fichier par défaut (écrasé lors des mises à jour)
jail.local = votre config personnalisée (prioritaire, jamais écrasé)

# Copier le fichier par défaut
# Type A
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Type B
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Éditer votre configuration
# Type A
vim /etc/fail2ban/jail.local

# Type B
sudo vim /etc/fail2ban/jail.local

3️⃣ Configuration recommandée

Cherchez et modifiez ces sections dans jail.local :

[DEFAULT]
# Durée de bannissement (10 minutes = 600 secondes)
bantime  = 600
# Augmentez à 3600 (1h) ou 86400 (24h) pour être plus strict

# Période d'observation (10 minutes)
findtime  = 600
# Sur 10 min, si on dépasse maxretry → ban

# Nombre de tentatives autorisées avant ban
maxretry = 5
# Réduisez à 3 pour être plus strict

# Email de notification (optionnel - nécessite un serveur mail configuré)
# destemail = votre-email@example.com
# sendername = Fail2ban-VPS
# action = %(action_mwl)s

[sshd]
enabled = true
port = 22
# Si vous avez changé le port SSH :
# port = 2222

# Par défaut, Fail2ban surveille déjà les tentatives SSH
# Pas besoin d'ajouter d'autres paramètres

💡 Explication des paramètres :

bantime = 600 : Bloquer l'IP pendant 10 minutes
findtime = 600 : Observer sur les 10 dernières minutes
maxretry = 5 : Si 5 échecs en 10 min → ban 10 min

4️⃣ Démarrer Fail2ban

# Type A (root)
systemctl start fail2ban
systemctl enable fail2ban
systemctl status fail2ban

# Type B (sudo)
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
sudo systemctl status fail2ban

# Vérifier que Fail2ban fonctionne
# Type A
fail2ban-client status

# Type B
sudo fail2ban-client status

# Résultat attendu :
# Status
# |- Number of jail:      1
# `- Jail list:   sshd

# Voir les détails de la jail SSH
sudo fail2ban-client status sshd
# Affiche : nombre d'IPs bannies, liste des IPs bannies

5️⃣ Commandes utiles Fail2ban

# Voir toutes les jails actives
sudo fail2ban-client status

# Voir les IPs bannies pour SSH
sudo fail2ban-client status sshd

# Débannir manuellement une IP (si vous vous êtes bloqué)
sudo fail2ban-client set sshd unbanip 203.0.113.45

# Bannir manuellement une IP
sudo fail2ban-client set sshd banip 185.220.101.23

# Recharger la configuration après modifications
sudo fail2ban-client reload

# Voir les logs Fail2ban en temps réel
sudo tail -f /var/log/fail2ban.log

🎯 Résultat : Vous verrez les attaques en temps réel dans les logs, et Fail2ban les bloquera automatiquement !

Étape 8 : Configurer les mises à jour automatiques

Pourquoi ? En 2026, des dizaines de nouvelles vulnérabilités sont découvertes chaque mois :

Failles zero-day dans le noyau Linux
Bugs critiques dans OpenSSH, Apache, etc.
Exploits rendus publics (CVE)

Sans mises à jour régulières, votre serveur devient vulnérable en quelques semaines.

Avec unattended-upgrades :

Les correctifs de sécurité s'installent automatiquement
Vous dormez tranquille
Redémarrage automatique aux heures creuses si nécessaire

1️⃣ Installer unattended-upgrades

# Type A (root)
apt install unattended-upgrades -y

# Type B (sudo)
sudo apt install unattended-upgrades -y

2️⃣ Activer la configuration automatique

# Type A
dpkg-reconfigure -plow unattended-upgrades

# Type B
sudo dpkg-reconfigure -plow unattended-upgrades

# Interface graphique → Sélectionnez "Oui" avec les flèches puis Entrée

3️⃣ Personnaliser la configuration (optionnel mais recommandé)

# Type A
vim /etc/apt/apt.conf.d/50unattended-upgrades

# Type B
sudo vim /etc/apt/apt.conf.d/50unattended-upgrades

Configuration recommandée :

# Quelles mises à jour installer automatiquement ?
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    # Ne mettre à jour QUE les paquets de sécurité (recommandé)

    # Décommentez pour installer TOUTES les mises à jour (moins prudent) :
    # "${distro_id}:${distro_codename}-updates";
};

# Redémarrer automatiquement si une mise à jour le nécessite ?
Unattended-Upgrade::Automatic-Reboot "true";
# Pourquoi ? Certaines mises à jour du noyau nécessitent un reboot

# Heure du redémarrage automatique
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
# 3h du matin = heure creuse (peu de visiteurs)
# Changez selon votre fuseau horaire et trafic

# Notifications par email (nécessite un serveur mail configuré)
# Unattended-Upgrade::Mail "votre-email@example.com";
# Unattended-Upgrade::MailReport "on-change";
# Utile pour être notifié des mises à jour importantes

# Supprimer automatiquement les paquets inutilisés
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
# Libère de l'espace disque automatiquement

4️⃣ Tester la configuration

# Simulation (ne fait rien, juste un test)
# Type A
unattended-upgrades --dry-run --debug

# Type B
sudo unattended-upgrades --dry-run --debug

# Affiche ce qui SERAIT mis à jour
# Vérifiez qu'il n'y a pas d'erreurs

💡 Fréquence des vérifications :

Par défaut : vérifie chaque jour
Installe automatiquement les mises à jour de sécurité
Redémarre si nécessaire à 3h du matin

⚠️ Important pour les sites critiques : Si vous avez un site haute disponibilité, configurez plutôt Automatic-Reboot "false" et faites les redémarrages manuellement pendant les maintenances planifiées.

Installation d'un serveur web

Étape 9 : Installer Apache

Pourquoi Apache ?

Robuste : Utilisé depuis 1995, tourne sur 30% des sites web mondiaux
Mature : Énormément de documentation et tutoriels
Compatible : .htaccess, mod_rewrite, intégration PHP native
Flexible : Modules pour tout (SSL, compression, cache, proxy)

Alternative : Nginx est plus performant pour du contenu statique et proxy inverse, mais Apache est plus simple pour débuter.

1️⃣ Installer Apache

# Type A (root)
apt install apache2 -y

# Type B (sudo)
sudo apt install apache2 -y

2️⃣ Démarrer et activer Apache

# Type A
systemctl start apache2      # Démarre Apache maintenant
systemctl enable apache2     # Active au démarrage du serveur
systemctl status apache2     # Vérifie que tout fonctionne

# Type B
sudo systemctl start apache2
sudo systemctl enable apache2
sudo systemctl status apache2

# Résultat attendu :
# ● apache2.service - The Apache HTTP Server
#    Loaded: loaded
#    Active: active (running)

3️⃣ Tester Apache

Depuis votre navigateur :

Allez sur http://<adresse-IP-du-VPS>
Vous devriez voir la page "Apache2 Debian Default Page"

✅ Ça fonctionne ? Parfait, Apache écoute sur le port 80 !

❌ Erreur de connexion ? Vérifiez :

# Le pare-feu autorise-t-il le port 80 ?
sudo ufw status | grep 80

# Apache est-il bien démarré ?
sudo systemctl status apache2

# Apache écoute-t-il sur le port 80 ?
sudo netstat -tlnp | grep :80

Étape 10 : Configurer un nom de domaine

Pourquoi ? Une adresse IP (185.123.45.67) c'est difficile à retenir et peu professionnel. Un nom de domaine (monsite.com) :

Est mémorable pour vos visiteurs
Permet d'obtenir un certificat SSL
Donne une image professionnelle
Facilite les migrations de serveur (changez l'IP sans changer l'URL)

Prérequis : Avoir acheté un nom de domaine chez un registrar (OVH, Infomaniak, Namecheap, Gandi, etc.)

1️⃣ Configurer les DNS chez votre registrar

Connectez-vous à votre registrar et créez ces enregistrements DNS :

Type    Nom    Valeur                TTL
A       @      <adresse-IP-du-VPS>   3600
A       www    <adresse-IP-du-VPS>   3600

Explications :

Type A : Associe un nom de domaine à une adresse IPv4
@ : Représente le domaine racine (example.com)
www : Sous-domaine (www.example.com)
TTL : Durée de cache (3600 = 1 heure)

💡 Astuce : Certains registrars proposent un enregistrement CNAME pour www qui pointe vers @. Ça fonctionne aussi !

2️⃣ Attendre la propagation DNS

Pourquoi attendre ? Les DNS sont distribués mondialement. Votre modification doit :

Se propager aux serveurs DNS racine
Se propager aux serveurs DNS de votre FAI
Se propager aux DNS publics (Google, Cloudflare, etc.)

Durée : 5 minutes à 24 heures (généralement 30 min)

Vérifier la propagation depuis votre machine locale :

# Vérifier que le domaine pointe vers votre VPS
nslookup example.com

# Résultat attendu :
# Address: <IP-de-votre-VPS>

# Alternative avec dig (plus détaillé)
dig example.com +short
# Doit afficher : <IP-de-votre-VPS>

# Vérifier www aussi
nslookup www.example.com

✅ Ça affiche votre IP ? Vous pouvez passer à l'étape suivante ❌ Ça affiche une autre IP ou rien ? Attendez encore un peu ou vérifiez votre configuration DNS

Étape 11 : Configurer un site avec Apache

Pourquoi un VirtualHost ? Apache peut héberger plusieurs sites sur le même serveur. Chaque site a son propre VirtualHost (configuration séparée). C'est comme avoir plusieurs appartements dans un immeuble.

1️⃣ Créer le dossier du site

# Type A (root)
mkdir -p /var/www/monsite
chown -R monuser:monuser /var/www/monsite
echo "<h1>Mon site fonctionne !</h1>" > /var/www/monsite/index.html

# Type B (sudo) - Remplacez "ubuntu" par votre utilisateur
sudo mkdir -p /var/www/monsite
sudo chown -R ubuntu:ubuntu /var/www/monsite
echo "<h1>Mon site fonctionne !</h1>" > /var/www/monsite/index.html

Pourquoi chown ? Par défaut, les fichiers créés par root appartiennent à root. chown change le propriétaire pour que VOTRE utilisateur puisse modifier les fichiers sans sudo.

2️⃣ Créer la configuration Apache (VirtualHost)

# Type A
vim /etc/apache2/sites-available/monsite.conf

# Type B
sudo vim /etc/apache2/sites-available/monsite.conf

Copiez-collez cette configuration :

<VirtualHost *:80>
    # Nom de domaine principal
    ServerName example.com

    # Alias (www.example.com pointe vers le même site)
    ServerAlias www.example.com

    # Dossier racine du site
    DocumentRoot /var/www/monsite

    # Configuration du dossier
    <Directory /var/www/monsite>
        # Options :
        # -Indexes : NE PAS lister les fichiers si pas d'index.html (sécurité)
        # +FollowSymLinks : Autoriser les liens symboliques
        Options -Indexes +FollowSymLinks

        # AllowOverride All : Permet l'utilisation de fichiers .htaccess
        # (utile pour WordPress, Laravel, etc.)
        AllowOverride All

        # Require all granted : Autoriser l'accès public
        Require all granted
    </Directory>

    # Fichiers de logs séparés par site (facilite le debug)
    ErrorLog ${APACHE_LOG_DIR}/monsite-error.log
    CustomLog ${APACHE_LOG_DIR}/monsite-access.log combined
</VirtualHost>

Esc puis :wq et Entrée pour sauvegarder et quitter.

3️⃣ Activer le site et les modules nécessaires

# Activer le module rewrite (URL propres : /article/titre au lieu de /index.php?page=article&id=123)
# Type A
a2enmod rewrite

# Type B
sudo a2enmod rewrite

# Activer votre site
# Type A
a2ensite monsite.conf

# Type B
sudo a2ensite monsite.conf

# Désactiver le site par défaut d'Apache (page "Apache2 Debian Default Page")
# Type A
a2dissite 000-default.conf

# Type B
sudo a2dissite 000-default.conf

# Tester la configuration (vérifie les erreurs de syntaxe)
# Type A
apache2ctl configtest

# Type B
sudo apache2ctl configtest

# Résultat attendu : "Syntax OK"

# Recharger Apache pour appliquer les changements
# Type A
systemctl reload apache2

# Type B
sudo systemctl reload apache2

4️⃣ Tester votre site

Depuis votre navigateur :

Allez sur http://example.com
Vous devriez voir "Mon site fonctionne !"

✅ Ça fonctionne ? Parfait, passez à l'étape suivante pour sécuriser avec HTTPS !

❌ Erreur 404 ou 403 ?

# Vérifier les droits du dossier
ls -la /var/www/monsite

# Vérifier les logs d'erreur
sudo tail -20 /var/log/apache2/monsite-error.log

# Vérifier que le VirtualHost est bien activé
ls -la /etc/apache2/sites-enabled/

Étape 12 : Installer un certificat SSL (HTTPS)

Pourquoi HTTPS est obligatoire en 2026 ?

Sécurité : Chiffre les données entre le visiteur et le serveur (mots de passe, infos personnelles)
SEO : Google pénalise les sites en HTTP depuis 2014
Confiance : Les navigateurs affichent "Non sécurisé" sur les sites HTTP
Standards : La plupart des APIs modernes nécessitent HTTPS
Gratuit : Let's Encrypt offre des certificats SSL gratuits à vie

Sans HTTPS : ❌ "Non sécurisé" - Visiteurs méfiants - Mauvais SEO Avec HTTPS : ✅ 🔒 Cadenas vert - Confiance - Bon référencement

1️⃣ Installer Certbot

# Type A
apt install certbot python3-certbot-apache -y

# Type B
sudo apt install certbot python3-certbot-apache -y

Certbot = outil officiel Let's Encrypt qui :

Génère automatiquement le certificat SSL
Configure Apache pour HTTPS
Renouvelle automatiquement le certificat tous les 90 jours

2️⃣ Obtenir le certificat SSL

# Type A
certbot --apache -d example.com -d www.example.com

# Type B
sudo certbot --apache -d example.com -d www.example.com

Certbot vous pose des questions :

Enter email address : Votre email (pour les alertes d'expiration)
```
votre-email@example.com
```
Terms of Service : Acceptez les conditions (A)
```
(A)gree/(C)ancel: A
```
Share email with EFF : Newsletter (optionnel)
```
(Y)es/(N)o: N
```

Redirect HTTP to HTTPS ? : TOUJOURS choisir Redirect

1: No redirect - Make no further changes
2: Redirect - Make all requests redirect to HTTPS
Select: 2

Pourquoi "Redirect" ?

Force tous les visiteurs en HTTPS
Améliore le SEO (évite le duplicate content)
Meilleure sécurité

Résultat attendu :

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/example.com/privkey.pem

3️⃣ Vérifier le renouvellement automatique

Pourquoi ? Les certificats Let's Encrypt expirent après 90 jours. Certbot installe automatiquement une tâche qui les renouvelle.

# Test de renouvellement (simulation, ne fait rien)
# Type A
certbot renew --dry-run

# Type B
sudo certbot renew --dry-run

# Résultat attendu :
# Congratulations, all simulated renewals succeeded

# Vérifier que la tâche automatique est bien programmée
systemctl list-timers | grep certbot

# Résultat attendu :
# certbot.timer ... left ... certbot.service

💡 Fonctionnement : Certbot vérifie 2 fois par jour si le certificat expire dans moins de 30 jours, et le renouvelle automatiquement si nécessaire.

4️⃣ Tester HTTPS

Depuis votre navigateur :

Allez sur http://example.com → Devrait automatiquement rediriger vers https://example.com ✅
Vérifiez le cadenas 🔒 dans la barre d'adresse → Cliquez dessus : "Connection is secure"
Testez aussi https://www.example.com → Doit afficher le même site avec le cadenas

Tester la qualité du certificat :

Allez sur SSL Labs
Entrez votre domaine
Attendez l'analyse (2-3 min)
Objectif : Note A ou A+

❌ Erreur "Your connection is not private" ?

Vérifiez que le DNS pointe bien vers votre VPS : nslookup example.com
Attendez quelques minutes (Let's Encrypt vérifie le domaine)
Vérifiez les logs : sudo tail -50 /var/log/letsencrypt/letsencrypt.log

🎉 Félicitations ! Votre site est maintenant sécurisé en HTTPS avec un certificat SSL qui se renouvelle automatiquement !

Déploiement

Étape 13 : Déployer avec rsync

rsync = outil de synchronisation efficace (ne transfère que les modifications).

Depuis votre machine locale :

# Synchroniser un dossier local vers le VPS
rsync -avhP ./mon-site-local/ monuser@<adresse-IP>:/var/www/monsite/

# Options expliquées :
# -a : mode archive (préserve permissions, timestamps, etc.)
# -v : mode verbeux (affiche les fichiers transférés)
# -h : tailles lisibles (Ko, Mo, etc.)
# -P : affiche la progression + reprend les transferts interrompus

# Avec suppression des fichiers distants en trop
rsync -avhP --delete ./mon-site-local/ monuser@<adresse-IP>:/var/www/monsite/

Script de déploiement automatique :

# Créer un fichier deploy.sh
vim deploy.sh

#!/bin/bash

# Configuration
LOCAL_DIR="./dist/"
REMOTE_USER="monuser"
REMOTE_HOST="123.45.67.89"
REMOTE_DIR="/var/www/monsite/"

# Déploiement
echo "🚀 Déploiement en cours..."
rsync -avhP --delete \
  --exclude 'node_modules' \
  --exclude '.git' \
  --exclude '.env' \
  "$LOCAL_DIR" "$REMOTE_USER@$REMOTE_HOST:$REMOTE_DIR"

echo "✅ Déploiement terminé !"

# Recharger Apache (optionnel)
ssh "$REMOTE_USER@$REMOTE_HOST" "sudo systemctl reload apache2"

# Rendre le script exécutable
chmod +x deploy.sh

# Utiliser le script
./deploy.sh

Étape 14 : Déployer avec Git

Alternative à rsync : déployer directement depuis un dépôt Git.

Sur le VPS :

# Installer Git
apt install git -y

# Aller dans le dossier du site
cd /var/www/monsite

# Cloner le dépôt
git clone https://github.com/votre-user/votre-repo.git .

# Ou initialiser Git
git init
git remote add origin https://github.com/votre-user/votre-repo.git
git pull origin main

Script de déploiement :

vim /home/monuser/deploy.sh

#!/bin/bash

cd /var/www/monsite

# Récupérer les dernières modifications
git pull origin main

# Si projet Node.js / SvelteKit
# npm install
# npm run build

# Recharger Apache
sudo systemctl reload apache2

echo "✅ Déploiement terminé !"

Déployer depuis votre machine locale :

ssh monuser@<adresse-IP> 'bash /home/monuser/deploy.sh'

Maintenance

Commandes utiles

Surveiller l'espace disque :

df -h                                   # Vue globale
du -sh /var/www/*                       # Taille des sites

Surveiller les logs Apache :

tail -f /var/log/apache2/access.log     # Logs d'accès en temps réel
tail -f /var/log/apache2/error.log      # Logs d'erreur

Surveiller les tentatives SSH :

fail2ban-client status sshd             # IPs bannies
journalctl -u sshd -n 50                # Dernières connexions SSH

Mettre à jour le système :

apt update && apt upgrade -y
apt autoremove -y

Redémarrer les services :

systemctl restart apache2
systemctl restart fail2ban
systemctl reboot                        # Redémarrer le serveur

Tâches régulières

Hebdomadaire :

Vérifier l'espace disque : df -h
Vérifier les logs d'erreur : tail -50 /var/log/apache2/error.log

Mensuel :

Vérifier les IPs bannies : fail2ban-client status
Vérifier les mises à jour manuelles : apt list --upgradable

Annuel :

Renouveler le certificat SSL (automatique avec Certbot)
Auditer les règles du pare-feu : ufw status verbose

Ressources

Documentation officielle

OVH VPS : Débuter avec un VPS
OVH Sécurité : Sécuriser un VPS
Apache : Documentation officielle
Let's Encrypt : Certbot
UFW : Documentation Ubuntu
Fail2ban : Documentation officielle

Tutoriels vidéo

Grafikart : Playlist Serveur Web
Yves Rougy : Apprendre SSH

Outils utiles

Explain Shell : https://explainshell.com/ - Décompose les commandes shell
SSL Labs : https://www.ssllabs.com/ssltest/ - Teste la config SSL
Security Headers : https://securityheaders.com/ - Teste les en-têtes de sécurité

Commandes de référence

rsync :

# Synchronisation de base
rsync -avhP source/ destination/

# Avec exclusions
rsync -avhP --exclude 'node_modules' source/ destination/

# Avec suppression
rsync -avhP --delete source/ destination/

# Mode dry-run (simulation)
rsync -avhPn source/ destination/

SSH :

# Connexion standard
ssh user@host

# Avec port personnalisé
ssh -p 2222 user@host

# Exécuter une commande à distance
ssh user@host 'commande'

# Copier un fichier (scp)
scp fichier.txt user@host:/path/
scp -r dossier/ user@host:/path/

Git :

# Cloner un dépôt
git clone https://github.com/user/repo.git

# Mettre à jour
git pull origin main

# Vérifier le statut
git status

Checklist de sécurité

Avant de mettre votre VPS en production, vérifiez :

Mot de passe root changé
Utilisateur non-root créé avec sudo
Authentification SSH par clé configurée
Authentification SSH par mot de passe désactivée
Connexion root SSH désactivée
Pare-feu UFW activé et configuré
Fail2ban installé et actif
Mises à jour automatiques activées
Apache installé et fonctionnel
Certificat SSL installé (HTTPS)
DNS configuré correctement
Logs vérifiés (pas d'erreurs)

Troubleshooting

Impossible de se connecter en SSH

Symptôme : Connection refused ou Connection timed out

Solutions :

Vérifier que SSH écoute sur le bon port :
```
sudo netstat -tlnp | grep ssh
```
Vérifier le pare-feu :
```
sudo ufw status
```
Vérifier le service SSH :
```
sudo systemctl status sshd
```

Apache ne démarre pas

Symptôme : systemctl status apache2 montre une erreur

Solutions :

Tester la configuration :
```
sudo apache2ctl configtest
```
Lire les logs :
```
sudo journalctl -u apache2 -n 50
```

Vérifier qu'un autre service n'utilise pas le port 80/443 :

sudo netstat -tlnp | grep :80
sudo netstat -tlnp | grep :443

Let's Encrypt échoue

Symptôme : certbot retourne une erreur

Solutions :

Vérifier que le DNS pointe vers le VPS :
```
nslookup example.com
```
Vérifier qu'Apache fonctionne et est accessible en HTTP :
```
curl http://example.com
```
Vérifier les logs Certbot :
```
sudo journalctl -u certbot -n 50
```

Pour aller plus loin

Une fois votre VPS configuré, vous pouvez :

Installer Docker pour conteneuriser vos applications
Configurer un reverse proxy pour gérer plusieurs sites
Mettre en place une CI/CD avec GitHub Actions
Installer une base de données (PostgreSQL, MySQL)
Configurer un serveur mail (Postfix, Dovecot)
Monitorer votre serveur (Netdata, Prometheus + Grafana)
Optimiser Apache (compression, cache, rate limiting)
Renforcer la sécurité (AppArmor, SELinux, 2FA SSH)

Consultez les autres guides dans linux-essentials/ pour la maintenance et le diagnostic !

38 KiB Raw Blame History Unescape Escape

Mettre en place un serveur VPS

📋 Table des matières

Prérequis

Ce dont vous avez besoin

Informations à noter

⚠️ Deux types d'accès VPS

Première connexion

Étape 1 : Se connecter au VPS

Étape 2 : Mettre à jour le système

Sécurisation de base

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

Étape 4 : Configurer l'authentification par clé SSH

Étape 5 : Sécuriser SSH

Étape 6 : Installer et configurer le pare-feu (UFW)

Étape 7 : Installer Fail2ban

Étape 8 : Configurer les mises à jour automatiques

Installation d'un serveur web

Étape 9 : Installer Apache

Étape 10 : Configurer un nom de domaine

Étape 11 : Configurer un site avec Apache

Étape 12 : Installer un certificat SSL (HTTPS)

Déploiement

Étape 13 : Déployer avec rsync

Étape 14 : Déployer avec Git

Maintenance

Commandes utiles

Tâches régulières

Ressources

Documentation officielle

Tutoriels vidéo

Outils utiles

Commandes de référence

Checklist de sécurité

Troubleshooting

Impossible de se connecter en SSH

Apache ne démarre pas

Let's Encrypt échoue

Pour aller plus loin

38 KiB

Raw Blame History