Ubuntu 26.04 et Chrony : diagnostiquer réellement la synchronisation NTP

Un service de temps peut être active sans que l’horloge soit correctement synchronisée. Une source peut être inaccessible, rejetée comme falseticker, trop instable ou simplement jamais sélectionnée. Dans des environnements utilisant Kerberos, certificats, clusters, journaux corrélés ou systèmes distribués, quelques secondes de dérive peuvent suffire à provoquer des incidents difficiles à relier immédiatement au temps.

Ubuntu 26.04 utilise Chrony comme daemon de temps par défaut sur les nouvelles installations, à la place de systemd-timesyncd. Canonical documente également une migration pour les systèmes existants et indique que les serveurs de temps Ubuntu utilisent NTS par défaut dans cette configuration.

L’objectif de cet article est de dépasser le simple systemctl status chrony et de construire un diagnostic observable avec chronyc : sources, sélection, reachability, offset, fréquence, stratum et état NTS.

Contexte et problème

NTP corrige l’horloge à partir de sources de temps. Chrony repose principalement sur deux composants :

chronyd   daemon qui mesure et discipline l’horloge
chronyc   interface de contrôle et de diagnostic

Le daemon collecte des mesures, estime l’écart et la dérive de fréquence, puis sélectionne les sources qu’il juge utilisables.

Une machine peut donc avoir :

chronyd démarré mais aucune source joignable ;
plusieurs sources joignables mais aucune sélectionnée ;
une source marquée falseticker ;
une connectivité UDP/123 partielle ;
une horloge en cours de convergence après boot ;
une source NTS dont la négociation d’authentification échoue ;
une politique réseau ou DNS qui empêche la résolution des serveurs.

Le diagnostic doit séparer état du service, état des sources et qualité réelle de synchronisation.

Rappel : offset, stratum et reachability

Quelques notions permettent de lire rapidement les sorties Chrony.

Offset : estimation de la différence entre l’horloge locale et la référence. Un offset ponctuel n’est pas suffisant pour juger la stabilité ; il faut regarder son évolution et l’incertitude.

Stratum : distance logique à une référence de temps. Un stratum plus faible n’implique pas automatiquement une meilleure source pour votre machine : latence, stabilité et cohérence avec les autres sources comptent aussi.

Reachability : historique de réponses NTP. Chrony l’affiche sous forme octale dans sources. Une valeur qui reste à zéro signale qu’aucune réponse utilisable n’est reçue.

Source sélectionnée : Chrony marque la source actuellement utilisée avec * dans la sortie sources; + indique généralement une source combinée ou acceptable, tandis que d’autres symboles signalent des sources non sélectionnables ou rejetées.

Prérequis

Avant de modifier la configuration, relevez :

le serveur Ubuntu et sa version ;
le daemon de temps actuellement installé ;
les serveurs NTP/NTS configurés ;
la politique firewall en sortie ;
le DNS utilisé par le serveur ;
les éventuels proxies ou restrictions réseau ;
l’existence d’une source de temps interne d’entreprise.

N’ajoutez pas un serveur NTP public dans une infrastructure réglementée sans validation de la politique réseau.

Mise en pratique

1. Identifier le daemon actif

Vérifiez les packages et services :

dpkg-query -W -f='${Package}\t${Version}\n' chrony systemd-timesyncd 2>/dev/null
systemctl status chrony --no-pager
systemctl status systemd-timesyncd --no-pager

Sur une nouvelle installation Ubuntu 26.04, Chrony est le choix par défaut documenté par Canonical.

Pour une machine existante après upgrade, Canonical documente la migration suivante :

sudo apt-mark auto systemd-timesyncd
sudo apt install chrony

Ne lancez pas cette migration uniquement pour faire un test si le serveur utilise une architecture de temps gérée par une solution d’entreprise. Inventoriez d’abord la configuration actuelle.

2. Vérifier l’état global avec `tracking`

Commencez par :

chronyc tracking

Cette commande résume l’état de synchronisation : référence utilisée, stratum, différence système, fréquence et autres indicateurs internes.

Les points à vérifier sont :

présence d’une Reference ID cohérente ;
stratum non nul lorsqu’une source est acquise ;
Leap status indiquant un état normal plutôt qu’une horloge non synchronisée ;
offsets qui convergent plutôt que des écarts qui augmentent.

Une valeur unique ne doit pas être transformée en seuil universel. Les exigences dépendent de l’application : une plateforme Kerberos et une base de données distribuée n’ont pas nécessairement les mêmes tolérances.

3. Lire les sources

Utilisez :

chronyc sources -v

La colonne d’état permet d’identifier rapidement la source sélectionnée.

Exemple conceptuel :

^* ntp-a.example.net
^+ ntp-b.example.net
^- ntp-c.example.net

Le * indique la source sélectionnée. Le + désigne une source acceptable participant à la combinaison, et - une source non retenue dans la sélection actuelle.

Vérifiez aussi la colonne Reach. Après plusieurs polls réussis, elle doit refléter des réponses reçues. Une valeur durablement nulle oriente le diagnostic vers DNS, routage, firewall ou serveur distant.

4. Mesurer la qualité avec `sourcestats`

Pour voir les statistiques de mesures :

chronyc sourcestats -v

Cette sortie aide à examiner notamment :

nombre de mesures ;
fréquence estimée ;
offset estimé ;
erreur associée aux mesures.

Le but n’est pas de chercher un chiffre « parfait », mais de détecter une source dont la dispersion ou la tendance est nettement différente des autres.

5. Comprendre pourquoi une source n’est pas sélectionnée

Sur les versions de Chrony qui proposent cette commande, utilisez :

chronyc selectdata -v

selectdata expose les raisons de sélection ou de rejet avec davantage de détails que sources. La documentation Chrony distingue par exemple des sources non synchronisées, manquant de mesures, trop instables, trop éloignées ou en désaccord avec les autres.

Cette commande est particulièrement utile lorsqu’une source est joignable mais ne devient jamais * ni +.

6. Contrôler l’activité des sources

chronyc activity

Vous obtenez le nombre de sources en ligne, hors ligne ou dans d’autres états.

Si toutes les sources sont offline, contrôlez avant de modifier Chrony :

getent ahosts <NTP_SERVER>
ip route get <SERVER_IP>

Puis utilisez les outils réseau autorisés dans votre environnement pour vérifier l’accès NTP.

Évitez de désactiver le firewall comme méthode de diagnostic. Cherchez la règle précise qui bloque éventuellement le trafic.

7. Examiner la configuration

Sur Ubuntu, contrôlez les fichiers Chrony réellement chargés :

grep -RniE '^(server|pool|peer|makestep|rtcsync|minsources|authselectmode)' \
  /etc/chrony/chrony.conf /etc/chrony/conf.d 2>/dev/null

Ne modifiez pas la configuration tant que vous n’avez pas identifié si les sources sont gérées par un package, un outil de configuration central ou votre automatisation.

Après une modification validée :

sudo systemctl restart chrony
systemctl status chrony --no-pager

Puis refaites tracking, sources -v et sourcestats -v.

NTS : authentifier la source de temps

Network Time Security (NTS) ajoute un mécanisme cryptographique à NTP. NTS utilise notamment une phase d’établissement de clés protégée par TLS puis authentifie les échanges NTP. Il ne faut pas présenter NTS comme un mécanisme destiné à cacher l’heure ou à assurer la confidentialité du trafic NTP lui-même ; son objectif principal est l’authenticité et l’intégrité de la synchronisation.

Canonical indique qu’Ubuntu 26.04 configure NTS par défaut avec les serveurs de temps Ubuntu dans le scénario documenté.

Pour une source NTS explicitement approuvée par votre organisation, une directive Chrony peut ressembler à :

server <NTS_SERVER> iburst nts

N’utilisez pas un hostname fictif en production. Validez la source, la chaîne de certificats, le DNS et l’accès réseau correspondant.

Après configuration, contrôlez à nouveau les sources et les logs :

chronyc sources -v
journalctl -u chrony -b --no-pager

Une erreur de certificat, de résolution DNS ou de négociation NTS doit être corrigée plutôt que contournée en supprimant l’authentification sans analyse.

Vérification opérationnelle

Un contrôle utile après changement peut être structuré ainsi :

chrony.service actif
        ↓
au moins une source joignable
        ↓
source sélectionnée
        ↓
tracking synchronisé
        ↓
offset stable/convergent
        ↓
application dépendante du temps validée

Vous pouvez aussi utiliser la commande de monitoring waitsync pour attendre une synchronisation selon les paramètres prévus par Chrony, mais les seuils doivent être choisis en fonction des exigences de votre environnement.

Pour un serveur joint à un domaine ou exécutant Kerberos, validez également un login ou un ticket dans le lab après avoir corrigé un incident de temps.

Bonnes pratiques

Utilisez plusieurs sources indépendantes lorsque l’architecture le permet. Une seule source crée un point de dépendance et rend la détection d’une référence incorrecte plus difficile.

Documentez les sources autorisées et leur mode d’authentification. Évitez les mélanges arbitraires entre pools publics et références internes.

Surveillez la dérive et la disponibilité dans le temps plutôt que d’exécuter uniquement un test manuel après installation.

Ne forcez pas systématiquement une correction brutale de l’horloge sur un serveur applicatif sans comprendre les conséquences. Les changements soudains de temps peuvent perturber certains logiciels, journaux ou bases de données.

Sécurité

Le temps est une dépendance de sécurité. Des horloges incorrectes peuvent affecter Kerberos, certificats TLS, validation de tokens et corrélation des logs.

NTS réduit le risque d’accepter une réponse NTP non authentique lorsque la source et la chaîne de confiance sont correctement configurées.

Restreignez également l’exposition réseau : un poste client Chrony n’a pas besoin de devenir serveur NTP pour tout le réseau. Contrôlez les directives allow avant d’exposer chronyd comme serveur.

Coûts

Chrony est disponible dans les repositories Ubuntu et n’introduit pas de licence payante. Le coût peut provenir de l’exploitation d’une infrastructure de temps interne redondée ou de ressources cloud associées, mais aucun tarif précis n’est nécessaire pour ce diagnostic.

Limites et rollback

La qualité de la synchronisation dépend du réseau, de l’hyperviseur, des sources, du kernel et de la charge du système. Un mauvais offset ne prouve pas à lui seul une erreur de configuration Chrony.

Les VMs peuvent aussi être influencées par les mécanismes de temps de l’hyperviseur ; évitez deux mécanismes concurrents qui cherchent à corriger l’horloge sans coordination.

Si une nouvelle configuration Chrony dégrade la situation, restaurez le fichier précédent, puis :

sudo systemctl restart chrony
chronyc tracking
chronyc sources -v

Si la migration depuis systemd-timesyncd elle-même doit être annulée, utilisez la procédure de package supportée par votre version Ubuntu après avoir restauré la configuration précédente. Ne désinstallez pas le daemon actif à distance sans disposer d’un accès de secours et sans savoir quel service reprendra la synchronisation.

Références officielles

Ubuntu 26.04 LTS summary — Canonical : https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/
chronyc(1) — Chrony project : https://chrony-project.org/documentation.html
chrony documentation — Chrony project : https://chrony-project.org/documentation.html

Conclusion

Avec Ubuntu 26.04, Chrony devient le point de référence pour les nouvelles installations. L’essentiel n’est toutefois pas le changement de daemon : c’est la capacité à prouver que l’horloge est correctement synchronisée.

tracking, sources, sourcestats, selectdata et activity fournissent les observations nécessaires pour distinguer un service simplement démarré d’une synchronisation saine. Ajoutez NTS lorsque l’architecture le prévoit, puis validez la dépendance applicative au temps avant de considérer le changement terminé.