NTP und chrony: Zeitsynchronisation unter Linux richtig konfigurieren

1. Warum Zeitsynchronisation unter Linux kritisch ist

Eine korrekte Systemuhr wirkt auf den ersten Blick wie ein triviales Detail, ist aber Voraussetzung fuer eine ganze Reihe kritischer Systeme. TLS-Zertifikate haben ein Gueltigkeitsfenster, das gegen die lokale Uhrzeit geprueft wird. Weicht die Uhr um mehrere Minuten ab, schlaegt der Handshake fehl, obwohl das Zertifikat objektiv gueltig ist. Kerberos-Authentifizierung toleriert typischerweise nur wenige Minuten Differenz, danach werden Tickets als ungueltig zurueckgewiesen. Ohne verlaessliche Zeitsynchronisation entstehen so schwer zu diagnostizierende Fehler, die auf den ersten Blick nichts mit der Uhrzeit zu tun haben.

Noch deutlicher wird das Problem bei verteilten Systemen. Datenbank-Replikation, verteiltes Logging und Monitoring-Korrelation verlassen sich darauf, dass Zeitstempel ueber mehrere Server hinweg vergleichbar sind. Wenn ein Webserver seine Uhr drei Sekunden vorauslaeuft und die Datenbank drei Sekunden nachhinkt, lassen sich Ereignisse in einem Incident nicht mehr zuverlaessig in die richtige Reihenfolge bringen. NTP, das Network Time Protocol, loest genau dieses Problem, indem es Systemuhren gegen eine Referenzzeit abgleicht, und chrony ist die Implementierung, die diese Aufgabe unter modernen Linux-Distributionen uebernimmt.

2. Wie NTP funktioniert: Stratum, Offset und Jitter

NTP organisiert Zeitquellen in einer Hierarchie aus Stratum-Ebenen. Stratum 0 sind die Referenzuhren selbst, meist Atomuhren oder GPS-Empfaenger, die nicht direkt im Netzwerk angesprochen werden. Stratum 1 sind Server, die direkt an eine solche Referenzuhr angeschlossen sind. Die meisten Server im Internet, auch oeffentliche Pool-Server, sind Stratum 2 oder 3, weil sie ihre Zeit von einem Stratum-1-Server beziehen und selbst als Quelle fuer weitere Clients dienen. Jeder zusaetzliche Hop erhoeht potenziell die Unsicherheit der Zeitangabe, weshalb eine niedrigere Stratum-Zahl grundsaetzlich als praeziser gilt.

Zwei Messgroessen sind fuer den praktischen Betrieb entscheidend: der Offset und der Jitter. Der Offset beschreibt die aktuell gemessene Differenz zwischen lokaler Uhr und Referenzzeit, typischerweise im Millisekundenbereich. Der Jitter beschreibt, wie stark diese Messung von Anfrage zu Anfrage schwankt, meist verursacht durch variable Netzwerklaufzeiten. Ein hoher Jitter macht es fuer chrony schwerer, die tatsaechliche Abweichung zuverlaessig zu schaetzen, weshalb chrony mehrere Messungen statistisch filtert, statt einer einzelnen Antwort blind zu vertrauen. Anders als eine einfache Uhrkorrektur, die die Zeit ruckartig springen laesst, passt chrony die Ganggeschwindigkeit der Systemuhr kontinuierlich an, sodass Anwendungen niemals einen Zeitsprung rueckwaerts erleben.

3. chrony installieren und Grundkonfiguration

Auf den meisten aktuellen Debian-, Ubuntu- und RHEL-Distributionen ist chrony bereits als Standard-Zeitdienst vorinstalliert, da es systemd-timesyncd in Anspruchsvollere Szenarien uebertrifft. Ist das nicht der Fall, installiert apt install chrony beziehungsweise dnf install chrony das Paket samt Systemd-Unit. Die zentrale Konfigurationsdatei liegt unter /etc/chrony/chrony.conf auf Debian-basierten Systemen beziehungsweise /etc/chrony.conf auf RHEL-basierten Systemen. Nach jeder Aenderung muss der Dienst mit systemctl restart chrony neu gestartet werden, damit die neuen Einstellungen greifen.

Eine minimale, aber vollstaendige Grundkonfiguration definiert mindestens eine NTP-Quelle, ein Verzeichnis fuer die Drift-Datei und grundlegende Zugriffsbeschraenkungen. Die Drift-Datei speichert, wie schnell die lokale Hardware-Uhr im Vergleich zur Referenzzeit vor- oder nachgeht, sodass chrony nach einem Neustart sofort mit einer guten Schaetzung starten kann, statt bei null anzufangen. Ohne diese Datei braucht die Zeitsynchronisation nach jedem Reboot erneut mehrere Minuten, bis eine stabile Korrektur gefunden ist.

# Install chrony on Debian/Ubuntu
sudo apt update && sudo apt install -y chrony

# Install chrony on RHEL/Rocky/AlmaLinux
sudo dnf install -y chrony

# Enable and start the service
sudo systemctl enable --now chronyd

# Check that the service is active
systemctl status chronyd --no-pager

# Restart after any config change
sudo systemctl restart chronyd

4. chrony versus klassisches ntpd: Warum chrony der Standard ist

Das klassische ntpd aus dem NTP-Referenzprojekt war jahrzehntelang der De-facto-Standard, hat aber strukturelle Schwaechen, die chrony gezielt adressiert. ntpd braucht typischerweise deutlich laenger, um nach dem Start eine stabile Synchronisation zu erreichen, und reagiert bei instabilen Netzwerkverbindungen traeger auf Aenderungen. chrony hingegen ist von Grund auf fuer Systeme konzipiert, die nicht permanent online sind, etwa Laptops, die staendig zwischen Netzwerken wechseln, oder virtuelle Maschinen, die nach Wochen im Suspend-Zustand aufwachen.

Ein weiterer praktischer Vorteil von chrony: Es funktioniert korrekt auch dann, wenn ein System zeitweise komplett offline ist, und synchronisiert nach Wiederherstellung der Verbindung deutlich schneller als ntpd. Fuer Server, die dauerhaft online sind, mag der Unterschied gering erscheinen, doch fuer alles, was mit intermittierender Konnektivitaet zu tun hat, container-basierte Workloads eingeschlossen, ist chrony die robustere Wahl. Aus diesem Grund haben Debian, Ubuntu, RHEL und die meisten anderen grossen Distributionen chrony inzwischen als Standardpaket fuer die Zeitsynchronisation etabliert und ntpd in den Hintergrund gedraengt.

5. NTP-Quellen konfigurieren: Pools, eigene Server, Fallbacks

Die Direktive pool in chrony.conf weist chrony an, mehrere Server aus einem DNS-Pool wie pool.ntp.org zu verwenden und automatisch die zuverlaessigsten auszuwaehlen. Fuer die meisten Standardserver reichen zwei bis vier Pool-Eintraege aus verschiedenen Regionen aus, um Ausfallsicherheit zu gewaehrleisten. In Unternehmensnetzwerken mit eigener Zeitinfrastruktur ist die Direktive server vorzuziehen, um explizit auf einen internen Stratum-1- oder Stratum-2-Server zu verweisen, ohne den Umweg ueber oeffentliche Pools und die damit verbundene Firewall-Freigabe nach aussen.

Die Option iburst hinter jeder Quelle beschleunigt die initiale Synchronisation erheblich, indem beim Start mehrere Anfragen kurz hintereinander gesendet werden, statt auf das normale Poll-Intervall zu warten. Fuer isolierte Netzwerke ohne Internetzugang, etwa in einer DMZ, kann eine lokale Hardware-Uhr als Fallback-Quelle mit niedriger Prioritaet konfiguriert werden, damit das System auch ohne externe NTP-Verbindung eine plausible, wenn auch nicht perfekte, Zeit halten kann.

# /etc/chrony/chrony.conf

# Public NTP pool with fast initial sync
pool pool.ntp.org iburst

# Internal reference servers (preferred if reachable)
server ntp1.internal.example.com iburst prefer
server ntp2.internal.example.com iburst

# Fallback: local hardware clock if no source is reachable
local stratum 10

# Store drift information across restarts
driftfile /var/lib/chrony/chrony.drift

# Step the clock on the first three updates if the offset is large
makestep 1.0 3

6. Synchronisationsstatus pruefen mit chronyc

Das Kommandozeilenwerkzeug chronyc ist die zentrale Schnittstelle, um den Status der Zeitsynchronisation zu ueberpruefen. Der Befehl chronyc tracking zeigt den aktuellen Systemoffset, die geschaetzte Fehlerrate und ob das System als synchronisiert gilt. Besonders wichtig ist das Feld Leap status, das Normal anzeigen sollte. Ein Wert wie Not synchronised bedeutet, dass chrony noch keine ausreichend zuverlaessige Quelle gefunden hat, was unmittelbar nach einem Neustart oder bei Netzwerkproblemen auftreten kann.

Der Befehl chronyc sources -v listet alle konfigurierten Zeitquellen samt Stratum, Reachability und aktuellem Offset auf. Ein Sternchen vor einer Quelle markiert die aktuell ausgewaehlte Referenz, ein Plus markiert Kandidaten, die ebenfalls als plausibel gelten. Die Reachability-Spalte zeigt als Oktalzahl, welche der letzten acht Anfragen erfolgreich beantwortet wurden, ein Wert von 377 bedeutet, dass alle acht letzten Versuche erfolgreich waren. Wer regelmaessig ueberpruefen moechte, ob die Zeitsynchronisation stabil bleibt, sollte diesen Befehl in ein Monitoring-Skript integrieren, statt nur manuell nachzuschauen.

# Show the current tracking status
chronyc tracking

# List all configured sources with stratum and offset
chronyc sources -v

# Show detailed statistics per source
chronyc sourcestats -v

# Force an immediate resynchronization
sudo chronyc makestep

# Verify NTS is active for a given source (if configured)
chronyc -N authdata

7. Zeitsynchronisation in virtuellen Maschinen und Containern

Virtuelle Maschinen bringen eine zusaetzliche Fehlerquelle mit: die virtualisierte Hardware-Uhr laeuft unter Last des Hypervisors nicht immer gleichmaessig, besonders bei ueberbuchten Hosts. Ein Snapshot, der Stunden oder Tage spaeter wiederhergestellt wird, startet mit einer massiv falschen Systemzeit, bis chrony korrigiert. Fuer solche Faelle empfiehlt sich die Kombination aus einem aggressiven makestep-Wert, der grosse Abweichungen sofort per Sprung statt langsamer Anpassung korrigiert, und einer kurzen Timeout-Konfiguration fuer die erste Synchronisation nach dem Boot.

Container teilen sich in den meisten Faellen den Systemtakt des Host-Kernels und benoetigen deshalb keinen eigenen chrony-Prozess, ein zusaetzlicher chrony-Daemon innerhalb eines Containers wuerde sogar mit dem Host um die Kontrolle der Uhr konkurrieren und sollte vermieden werden. Wichtig ist stattdessen, dass der Host selbst korrekt synchronisiert ist, denn alle Container erben automatisch dessen Systemzeit. Bei Cloud-Instanzen mit Hypervisor-eigenem Zeitdienst, etwa bei manchen KVM- oder Xen-Setups, sollte geprueft werden, ob der Hypervisor selbst schon eine Zeitquelle injiziert, um Konflikte zwischen zwei konkurrierenden Synchronisationsmechanismen zu vermeiden.

8. NTP absichern: NTS, Zugriffsbeschraenkung, Monitoring

Klassisches NTP ueber UDP ist unverschluesselt und ungeschuetzt gegen Manipulation, ein Angreifer im Netzwerkpfad koennte theoretisch gefaelschte Zeitantworten einschleusen, um Zertifikatspruefungen auszutricksen oder Logs zu verfaelschen. Network Time Security, kurz NTS, loest dieses Problem durch eine TLS-basierte Authentifizierung der Zeitquelle, bevor die eigentlichen NTP-Pakete ausgetauscht werden. Chrony unterstuetzt NTS seit Version 4.0 nativ, viele grosse oeffentliche Pool-Server wie die von Cloudflare oder Netnod bieten NTS-faehige Endpunkte an, die sich mit der Direktive server ... nts aktivieren lassen.

Zusaetzlich zur Verschluesselung sollte der Zugriff auf den eigenen chrony-Dienst restriktiv gehalten werden, falls der Server selbst als Zeitquelle fuer andere Systeme im internen Netz dient. Die Direktive allow beschraenkt, welche Subnetze abfragen duerfen, waehrend cmdport 0 den Remote-Zugriff auf die administrative Kommandoschnittstelle vollstaendig deaktiviert, wenn er nicht benoetigt wird. Fuer produktive Umgebungen empfiehlt sich zusaetzlich ein Monitoring-Check, der regelmaessig chronyc tracking auswertet und Alarm schlaegt, sobald der Offset einen definierten Schwellenwert ueberschreitet, bevor abhaengige Systeme wie TLS oder Kerberos betroffen sind.

# /etc/chrony/chrony.conf — hardened configuration

# Use NTS-authenticated public servers
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts

# Only allow the internal management subnet to query this server
allow 10.0.0.0/24

# Disable remote administrative access entirely
cmdport 0

# Log measurements for later auditing
log tracking measurements statistics
logdir /var/log/chrony

9. chrony, ntpd und systemd-timesyncd im Vergleich

Neben chrony und dem klassischen ntpd bringt jede systemd-basierte Distribution zusaetzlich systemd-timesyncd mit, einen bewusst minimalen SNTP-Client. Die Wahl zwischen den drei Optionen haengt stark davon ab, wie praezise und wie ausfallsicher die Zeitsynchronisation sein muss.

Fuer Produktivserver, insbesondere fuer Systeme mit TLS-Terminierung, Datenbank-Replikation oder Kerberos-Authentifizierung, ist chrony die klar empfohlene Wahl, weil es die schnellste Konvergenz, die beste NTS-Unterstuetzung und den geringsten Ressourcenverbrauch kombiniert. systemd-timesyncd eignet sich fuer minimale Container-Images, in denen keine hohe Praezision benoetigt wird, sollte aber nie fuer Systeme verwendet werden, die selbst als Zeitquelle fuer andere dienen sollen.

10. Zusammenfassung

NTP und chrony loesen ein Problem, das im Alltag unsichtbar bleibt, bis es akut wird: falsche Systemzeit fuehrt zu gescheiterten TLS-Handshakes, ungueltigen Kerberos-Tickets und unbrauchbarer Log-Korrelation. chrony hat sich als Standard-Implementierung durchgesetzt, weil es schneller konvergiert als klassisches ntpd, robuster mit instabiler Konnektivitaet umgeht und mit NTS eine moderne, verschluesselte Absicherung der Zeitquelle bietet. Die Kombination aus pool-Direktiven fuer Ausfallsicherheit, iburst fuer schnelle initiale Synchronisation und einer gepflegten Drift-Datei bildet das Fundament jeder stabilen Konfiguration.

Fuer den taeglichen Betrieb ist chronyc tracking der wichtigste Befehl, um zu pruefen, ob ein System tatsaechlich synchronisiert ist, waehrend chronyc sources -v Transparenz ueber die verwendeten Quellen schafft. In virtualisierten Umgebungen sollte die Konfiguration auf schnelle Korrektur nach Snapshot-Wiederherstellung ausgelegt sein, waehrend produktive Server ihre Zeitkommunikation konsequent mit NTS und restriktiven allow-Regeln absichern sollten.

11. FAQ: NTP und chrony