Configurer la synchronisation NTP sur un VPS Linux avec chrony

L'horloge d'un VPS Linux ou d'un serveur dédié n'est pas un simple affichage : c'est une brique dont dépendent les journaux système, la validation des certificats TLS, les tâches planifiées par cron, la résolution DNS, la réplication des bases de données et la synchronisation des serveurs de jeu. Sur une machine virtuelle, l'horloge matérielle est elle-même virtualisée. Sans synchronisation NTP, elle peut dériver de plusieurs secondes par jour. Quelques secondes suffisent pour que les horodatages Unix des logs deviennent incohérents, qu'un certificat Let's Encrypt soit refusé par un client, ou qu'un job cron se décale silencieusement.

chrony est l'implémentation NTP de référence sur les distributions Linux modernes (Ubuntu 25.10+ et RHEL/CentOS l'installent par défaut). Plus rapide à converger que l'ancien ntpd et plus complet que systemd-timesyncd, il est conçu pour les environnements de virtualisation (KVM, VMware, Proxmox) où l'horloge peut sauter après une migration à chaud ou un redémarrage de l'hyperviseur. Ce guide couvre l'installation sur Ubuntu et Debian, la configuration du serveur avec les pools NTP français (fr.pool.ntp.org), les règles de firewall nécessaires, la vérification de la précision avec chronyc tracking et la mise en place d'une surveillance pour détecter les écarts avant qu'ils ne provoquent un incident.

Pourquoi la synchronisation NTP est critique sur un serveur

Le protocole NTP (Network Time Protocol) permet à un serveur de synchroniser son horloge système avec des serveurs de temps de référence, des horloges atomiques ou GPS accessibles par Internet. Sans NTP, un VPS Linux ou un serveur dédié accumule une dérive (drift) qui produit des effets concrets sur l'ensemble de la configuration du serveur :

• Logs incohérents : les horodatages des journaux système (journalctl, syslog, logs applicatifs) ne correspondent plus aux événements réels. Corréler les logs de plusieurs serveurs d'un cluster devient impossible pour l'administrateur.
• Certificats TLS refusés : un navigateur ou un client API vérifie que la date du serveur est dans la fenêtre de validité du certificat. Un décalage de quelques minutes provoque des erreurs NET::ERR_CERT_DATE_INVALID, même avec un certificat Let's Encrypt valide.
• Tâches cron décalées : les jobs cron et timers systemd s'exécutent selon l'horloge du système. Une dérive accumule un décalage progressif sur les sauvegardes automatiques (backup), les rotations de logs et les scripts de maintenance.
• Serveurs de jeu désynchronisés : FiveM, Minecraft ou Rust s'appuient sur l'horodatage pour la synchronisation réseau entre le serveur et les clients. Un écart d'horloge provoque des saccades, des téléportations ou des erreurs d'authentification.
• Authentification en échec : les protocoles basés sur des tokens temporels (TOTP, Kerberos, OAuth) rejettent les requêtes si l'horloge du serveur dépasse la fenêtre de tolérance.
• Résolution DNS et DNSSEC : les signatures DNSSEC contiennent des horodatages de validité. Un serveur dont l'horloge dérive peut échouer à valider des réponses DNS signées, ce qui casse la résolution DNS pour les domaines protégés par DNSSEC.
• Réplication des bases de données : MySQL, MariaDB et PostgreSQL utilisent les horodatages dans les binary logs et les journaux de transactions. Un écart entre un serveur principal et ses réplicas provoque des conflits de réplication ou des données incohérentes.
• Serveur web et reverse proxy : Apache et Nginx écrivent des timestamps dans les logs d'accès. Un reverse proxy Nginx dont l'horloge ne correspond pas à celle du backend rend le debug des latences impossible.
• Sauvegardes incrémentales : des outils comme rsync comparent les horodatages des fichiers pour déterminer ce qui a changé. Une horloge décalée provoque des sauvegardes complètes au lieu d'incrémentales, ou pire, des fichiers modifiés ignorés.
• Serveur SMTP : les en-têtes d'email contiennent un horodatage (Date:). Un serveur Postfix dont l'horloge dérive voit ses messages marqués comme suspects par les filtres anti-spam, ce qui dégrade la délivrabilité.

chrony, systemd-timesyncd, ntpd : lequel choisir

Trois implémentations NTP coexistent sur les distributions Linux. Le tableau suivant résume leurs différences pour un administrateur de VPS ou de serveur dédié :

systemd-timesyncd est un client minimal qui ne surveille qu'un seul serveur à la fois : il ne détecte pas une source NTP défaillante qui renvoie une heure erronée. ntpd est l'implémentation historique des systèmes Unix, mais sa convergence lente et sa sensibilité aux sauts d'horloge le rendent inadapté à la virtualisation sur VPS et serveurs dédiés. chrony cumule la rapidité de convergence, la détection de sources défaillantes, une faible consommation de RAM et la tolérance aux environnements virtualisés (KVM, VMware, Proxmox).

Prérequis

Avant de commencer la configuration du serveur, vérifiez que vous disposez de :

• Un VPS Linux ou un serveur dédié sous Ubuntu 22.04+, Ubuntu 24.04 LTS ou Debian 12 ;
• Un accès SSH avec les droits root ou un utilisateur dans le groupe sudo ;
• Une connectivité réseau sortante sur le port UDP 123 (NTP) depuis votre hébergeur ;
• Le firewall du VPS (UFW ou nftables) configuré pour autoriser le trafic NTP sortant.

Installer chrony sur Ubuntu et Debian

Sur Ubuntu 24.04 LTS et Debian 12, systemd-timesyncd est le client NTP par défaut. Installer chrony le remplace automatiquement. Lancez la commande suivante en tant que root ou avec sudo :

sudo apt update
sudo apt install -y chrony

Vérifiez que le service est actif avec la commande suivante :

sudo systemctl status chrony

La sortie doit afficher active (running). Si systemd-timesyncd était actif, il est automatiquement désactivé lors de l'installation de chrony pour éviter un conflit entre les deux démons de synchronisation.

Pour confirmer que chrony est bien le client NTP utilisé par le système :

timedatectl status

La ligne NTP service: active confirme que la synchronisation NTP fonctionne. La ligne System clock synchronized: yes indique que l'horloge est déjà ajustée.

Sur les plateformes de virtualisation comme KVM ou VMware, l'hyperviseur peut injecter son propre temps via les guest additions. chrony gère ces sauts d'horloge sans intervention de l'admin. Si votre hébergeur met à disposition un panneau comme Plesk, l'heure affichée dans le tableau de bord reflète celle du système : une fois chrony configuré, elle sera exacte automatiquement.

Configurer les pools NTP français

Par défaut, chrony sur Ubuntu utilise les pools ntp.ubuntu.com. Pour un VPS hébergé en France, pointer vers les serveurs NTP français réduit la latence des requêtes et améliore la précision de synchronisation. Les noms de domaine fr.pool.ntp.org résolvent vers des adresses IP de serveurs NTP géographiquement proches, maintenus par des volontaires du projet pool.ntp.org.

Le fichier de configuration principal est /etc/chrony/chrony.conf. Ouvrez-le avec la commande suivante :

sudo nano /etc/chrony/chrony.conf

Remplacez les lignes pool ou server existantes par les pools NTP français :

pool 0.fr.pool.ntp.org iburst
pool 1.fr.pool.ntp.org iburst
pool 2.fr.pool.ntp.org iburst
pool 3.fr.pool.ntp.org iburst

L'option iburst accélère la synchronisation initiale en envoyant plusieurs requêtes rapprochées au démarrage du service, au lieu d'attendre l'intervalle d'interrogation normal.

Les autres directives essentielles de la config, déjà présentes dans les configurations par défaut :

• driftfile /var/lib/chrony/chrony.drift : stocke la dérive estimée de l'horloge pour accélérer la resynchronisation au redémarrage ;
• makestep 1 3 : autorise un ajustement brutal de l'horloge (step) si l'écart dépasse 1 seconde, mais seulement lors des 3 premières mises à jour après le démarrage. Après cela, chrony n'ajuste l'horloge que progressivement (slew) pour éviter de casser les applications ;
• rtcsync : synchronise l'horloge matérielle (RTC) avec l'horloge système toutes les 11 minutes.

Appliquez la configuration en redémarrant le service :

sudo systemctl restart chrony

Configurer le firewall pour le trafic NTP

chrony a besoin d'envoyer et de recevoir des paquets sur des ports réseau spécifiques. Si le firewall du serveur bloque ces ports, la synchronisation échouera silencieusement. Voici les ports à ouvrir :

• UDP 123 (sortant) : port standard du protocole NTP, utilisé pour toutes les requêtes de synchronisation ;
• TCP 4460 (sortant) : port de négociation NTS (Network Time Security), nécessaire uniquement si vous activez l'authentification TLS des échanges NTP.

Avec UFW (le firewall par défaut sur Ubuntu), autorisez le trafic NTP sortant :

sudo ufw allow out 123/udp
sudo ufw allow out 4460/tcp

Si vous utilisez nftables comme pare-feu, ajoutez les règles équivalentes dans votre configuration. Pour vérifier que les ports sont bien ouverts et que chrony communique avec les serveurs NTP, listez les ports en écoute avec ss :

sudo ss -ulnp | grep chronyd

La sortie doit montrer chronyd en écoute sur le port UDP 123. Si aucune source NTP ne répond après quelques minutes, vérifiez que votre hébergeur ou le routeur en amont ne bloque pas le trafic UDP 123 sortant.

Vérifier la synchronisation avec chronyc

chronyc est l'outil en ligne de commande pour interroger le démon chrony. Les deux commandes essentielles pour l'admin :

Sources NTP actives

chronyc sources -v

Cette commande affiche la liste des serveurs NTP interrogés par chrony, avec leur adresse IP et leur état. Chaque ligne indique :

• ^* : la source actuellement sélectionnée comme référence principale ;
• ^+ : une source utilisable comme alternative ;
• ^- : une source valide mais exclue (trop éloignée de la majorité) ;
• ^? : une source dont la fiabilité n'a pas encore été établie.

La colonne Stratum indique le nombre de sauts entre le serveur NTP et une horloge de référence (stratum 1 = directement connecté à une horloge atomique ou GPS). La colonne Poll donne l'intervalle d'interrogation en secondes (puissance de 2).

Précision de l'horloge locale

chronyc tracking

Cette commande affiche l'état de synchronisation du système. Les valeurs clés :

• System time : l'écart entre l'horloge système et la source NTP sélectionnée. Sur un VPS bien synchronisé, cette valeur est de l'ordre de quelques millisecondes ou microsecondes ;
• Last offset : le dernier ajustement effectué ;
• RMS offset : la moyenne quadratique des décalages récents, indicateur de la stabilité globale ;
• Frequency : la dérive mesurée de l'oscillateur en ppm (parts per million). Une valeur stable indique que chrony a bien estimé la dérive de l'horloge du VPS ;
• Stratum : le stratum de votre serveur (stratum du serveur source + 1).

Utiliser chrony comme serveur NTP sur un réseau local

Si vous administrez un cluster de serveurs (VPS ou serveurs dédiés) dans le même datacenter, vous pouvez configurer un seul serveur comme serveur NTP de référence pour tout le réseau local. Les autres machines synchronisent leur horloge sur ce serveur interne au lieu de multiplier les requêtes vers les pools publics. Cette configuration réduit la bande passante NTP sortante et garantit une cohérence d'horloge entre tous les serveurs du cluster.

Sur le serveur NTP principal, ajoutez la directive allow dans /etc/chrony/chrony.conf pour autoriser les requêtes depuis le sous-réseau local :

# Autoriser les clients du réseau local à se synchroniser
allow 10.0.0.0/24

Remplacez 10.0.0.0/24 par le sous-réseau de votre infrastructure. Redémarrez chrony pour appliquer la configuration. Sur les autres serveurs du cluster, pointez vers l'adresse IP du serveur NTP interne :

server 10.0.0.1 iburst

Ce serveur NTP interne agit comme un proxy de temps : il se synchronise sur les pools publics et redistribue l'heure aux machines du réseau local. Les serveurs clients n'ont pas besoin d'un accès direct aux pools NTP externes via le routeur.

Surveiller la dérive pour éviter les incidents silencieux

Une horloge qui dérive lentement ne produit pas d'erreur visible immédiatement. Le problème ne se manifeste qu'au moment où un certificat est refusé, un log est incohérent ou une sauvegarde échoue. Deux approches pour détecter ces écarts avant qu'ils ne provoquent un incident :

Script de vérification ponctuel (Bash)

Ce script Bash vérifie que l'écart d'horloge reste inférieur à 100 millisecondes et que chrony est bien synchronisé :

#!/bin/bash
OFFSET=$(chronyc tracking | awk '/System time/{print $4}')
SYNC=$(chronyc tracking | awk '/Leap status/{print $4}')
if [ "$SYNC" != "Normal" ]; then
    echo "ALERTE : chrony non synchronise (Leap status: $SYNC)"
    exit 1
fi
# Comparer l'offset a 0.1 seconde
if awk "BEGIN{exit !($OFFSET > 0.1)}" ; then
    echo "ALERTE : derive NTP de ${OFFSET}s (seuil: 0.1s)"
    exit 1
fi
echo "OK : derive NTP ${OFFSET}s, synchronisation normale"

Planifiez ce script toutes les heures avec un timer systemd ou un job cron pour recevoir une alerte en cas de dérive.

Alternative en Python

Si vos scripts de monitoring sont en Python, la commande suivante interroge chrony et retourne l'offset en une ligne :

python3 -c "
import subprocess, re, sys
out = subprocess.check_output(['chronyc', 'tracking']).decode()
m = re.search(r'System time\s+:\s+([\d.]+)', out)
offset = float(m.group(1)) if m else None
if offset is None or offset > 0.1:
    print(f'ALERTE: derive NTP {offset}s'); sys.exit(1)
print(f'OK: derive NTP {offset}s')
"

Monitoring continu

Pour un suivi graphique de la dérive NTP, les exporteurs Prometheus comme node_exporter exposent les métriques node_timex_offset_seconds et node_timex_estimated_error_seconds. Un tableau de bord Grafana sur votre VPS permet de visualiser l'évolution de l'offset et de déclencher des alertes automatiques quand la dérive dépasse un seuil. Si votre hébergeur met à disposition un panneau Plesk, vérifiez également que l'heure affichée dans l'interface d'administration correspond à l'heure réelle.

Dépannage courant

Pour forcer une resynchronisation immédiate (utile après une restauration de snapshot ou une migration de VM) :

sudo chronyc makestep

Cette commande force un ajustement brutal de l'horloge, indépendamment de la directive makestep du fichier de config. À n'utiliser qu'en cas de décalage important constaté, pas en routine.

Sécuriser la synchronisation NTP

Le protocole NTP classique (port UDP 123) n'authentifie pas les réponses. Un attaquant en position de man-in-the-middle peut injecter des réponses NTP falsifiées pour décaler l'horloge d'un serveur. Les conséquences vont de la création d'un créneau d'acceptation d'un certificat révoqué à la désynchronisation de logs pour masquer une intrusion.

chrony supporte NTS (Network Time Security), une extension du protocole NTP qui authentifie les échanges via TLS (port TCP 4460 pour la négociation de clés, puis port UDP 123 pour les paquets NTP authentifiés). NTS est supporté nativement par chrony depuis la version 4.0 et activé par défaut sur Ubuntu 26.04. Pour activer NTS manuellement avec des serveurs qui le supportent, remplacez les directives pool par des directives server avec l'option nts dans votre fichier de config :

server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts

Après redémarrage du service, vérifiez l'état de l'authentification NTS avec la commande suivante :

sudo chronyc -N authdata

La colonne Mode doit afficher NTS pour les serveurs configurés avec cette option. NTS est un renforcement recommandé, surtout si le VPS ou le serveur dédié gère des services sensibles comme des certificats TLS, des bases de données ou des données d'authentification. Pour renforcer la sécurité globale de votre serveur, consultez notre guide sécuriser SSH sur VPS Linux.

Conclusion

chrony transforme la synchronisation NTP d'une configuration qu'on oublie après l'installation en un élément surveillé de l'infrastructure. La séquence tient en quatre étapes : installer le paquet, pointer vers les pools français, ouvrir les ports du firewall et vérifier avec chronyc tracking. Sur un VPS ou un serveur dédié qui héberge des serveurs de jeu, un serveur web, des bases de données MySQL ou des sauvegardes planifiées, une horloge fiable est un prérequis silencieux dont l'absence ne se remarque qu'au moment où elle casse quelque chose. Pour optimiser les performances globales de votre VPS Linux au-delà de la synchronisation NTP, consultez notre guide dédié. Et pour maintenir votre serveur à jour sur les correctifs de sécurité, voyez comment automatiser les mises à jour de sécurité sur Ubuntu.