Zeitsynchronisation: NTP, chrony und warum Uhren stimmen müssen

Zeitsynchronisation sorgt dafür, dass die Uhren aller Systeme übereinstimmen. Was nach einer Nebensächlichkeit klingt, ist eine der wichtigsten Grundlagen im Betrieb: Ohne gemeinsame Zeit lassen sich Protokolle nicht zusammenführen, Zertifikate schlagen fehl, und Signaturen werden ungültig.

Warum die Uhr so genau sein muss

  • Protokolle zusammenführen: Ein Vorfall wird mit Logs aus fünf Systemen rekonstruiert. Weichen die Uhren um Sekunden ab, ist die Reihenfolge der Ereignisse nicht mehr erkennbar.
  • Zertifikate: Ein TLS-Zertifikat gilt „ab“ einem Zeitpunkt. Ist die Uhr des Servers zu weit vorn oder hinten, wird die Verbindung abgelehnt – mit einer Fehlermeldung, die nicht auf die Uhr hindeutet.
  • Signaturen und Token: Zeitlich begrenzte Zugangsnachweise (Kerberos, JWT, Einmal-Passwörter) funktionieren nur in einem engen Zeitfenster. Üblich sind fünf Minuten Toleranz.
  • Datenbanken und Cluster: Verteilte Systeme mit Zeitstempeln als Ordnungskriterium reagieren empfindlich auf Abweichungen. Konsensverfahren setzen Uhren in der Nähe der Wahrheit voraus.
  • Abrechnung und Aufbewahrung: Fristen, Protokollierungspflichten und Abrechnungen brauchen nachvollziehbare Zeitstempel.

NTP und der Aufbau der Schichten

NTP (Network Time Protocol) ist das klassische Verfahren. Der Dienst ntpd, der modernere chrony und das einfache systemd-timesyncd setzen es um. Zeitquellen sind in Schichten (Stratum) organisiert:

  • Schicht 0: die Referenz selbst – Atomuhr, GPS-Empfänger, Funkzeit.
  • Schicht 1: Server, die direkt an einer Referenz hängen.
  • Schicht 2: Server, die von Schicht 1 beziehen. Und so weiter.

Für die meisten Zwecke sind öffentliche Pool-Server (Schicht 2 bis 4) völlig ausreichend – die Genauigkeit liegt dann im Bereich von Millisekunden bis wenigen Dutzend Millisekunden. Wer mehr braucht (Handel, Messtechnik, Funktechnik), nutzt eigene Quellen oder PTP mit Hardware-Zeitstempeln; damit sind Abweichungen im Nanosekundenbereich erreichbar.

Einrichtung

# Zeitzone und Uhr pruefen
timedatectl
timedatectl set-timezone Europe/Berlin

# systemd-timesyncd (einfach, Standard auf vielen Systemen)
timedatectl set-ntp true
systemctl status systemd-timesyncd
timedatectl timesync-status        # Quelle, Abweichung, Intervall

# chrony (fuer Server empfohlen: genauere Regelung, bessere Protokolle)
apt install chrony
chronyc tracking                  # aktuelle Abweichung und Quelle
chronyc sources -v                # Liste der Quellen mit Bewertung
chronyc sourcestats -v            # Langzeitstatistik je Quelle
chronyc makestep                  # sofort angleichen (Vorsicht!)
# /etc/chrony/chrony.conf
pool 2.debian.pool.ntp.org iburst
# iburst = mehrere Pakete beim Start -> schnellere erste Angleichung

# Eigene Server bevorzugen
server ntp1.example.org iburst prefer
server ntp2.example.org iburst

# Falls das System als Zeitquelle fuer das eigene Netz dienen soll
allow 10.0.0.0/24
local stratum 10

# Bei grossen Abweichungen sofort korrigieren (nur einmalig beim Start)
makestep 1.0 3

# Protokollierung
logdir /var/log/chrony
log measurements statistics tracking

Eigener Zeitserver im Netz

Aus zwei Gründen sinnvoll: Konsistenz und Verfügbarkeit.

  1. Konsistenz: Alle internen Systeme beziehen von derselben Quelle. Dadurch sind Uhren untereinander maximal nah beieinander, auch wenn sie alle leicht von der Weltzeit abweichen. Für Protokollvergleiche ist das wichtiger als absolute Genauigkeit.
  2. Verfügbarkeit und Kontrolle: Fällt der Internetzugang aus, läuft die Zeitverteilung intern weiter. Außerdem muss nicht jeder Server ins Internet – ein Sicherheitsgewinn.
# Firewall: eingehende NTP-Anfragen nur aus dem eigenen Netz
iptables -A INPUT -p udp --dport 123 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 123 -j DROP

Wichtig: Ein offener NTP-Server im Internet wird für Verstärkungsangriffe missbraucht, weil die Antwort größer sein kann als die Anfrage. Ohne Zugriffsbeschränkung gehört kein NTP-Dienst ins offene Netz.

Typische Fehler und Diagnose

# 1. Ist der Dienst ueberhaupt aktiv?
timedatectl | grep -i 'synchronized\|NTP'

# 2. Sind die Quellen erreichbar? (UDP 123 nach aussen offen?)
chronyc sources -v
#   ^*  = aktuell gewaehlte Quelle
#   ^+  = brauchbare Alternative
#   ^?  = noch nicht bewertet oder unerreichbar

# 3. Wie gross ist die Abweichung?
chronyc tracking | grep -E 'System time|Last offset|Frequency'

# 4. Notfall: manuelle Anpassung (nur bei kleinen Abweichungen sinnvoll)
chronyc makestep
# Bei GROSSEN Abweichungen macht NTP absichtlich langsam -
# sonst springt die Zeit und Anwendungen brechen ab.
# Fuer einen kontrollierten Sprung: Dienst stoppen, Uhr setzen, Dienst starten.
  • Uhr läuft falsch nach einem Neustart: Die Hardware-Uhr ist falsch oder die Zeitzone ist nicht gesetzt. hwclock --systohc schreibt sie zurück.
  • Kein Kontakt zu den Quellen: Häufig blockiert die Firewall ausgehendes UDP auf Port 123. Viele Netze erlauben nur unverschlüsselten NTP-Verkehr gar nicht mehr – dann braucht es NTS oder einen internen Server.
  • Zeit springt rückwärts: Meist zwei konkurrierende Zeitdienste. Nur einen betreiben: entweder systemd-timesyncd oder chrony, nicht beide.
  • Virtuelle Maschinen: Bei Virtualisierung sollte der Hypervisor die Zeit durchreichen und nicht selbst regeln; sonst kämpfen Gast und Wirt um die richtige Uhr. Üblich ist diese Aufteilung: der Wirt holt die Zeit, der Gast bezieht sie über den Hypervisor.

Was aus der Zeit folgt

Zeitsynchronisation ist unspektakulär und wird deshalb häufig übergangen – bis zu dem Moment, in dem eine Fehlersuche scheitert, weil die Logs nicht zusammenpassen, oder eine Anmeldung mit einer nicht nachvollziehbaren Meldung abbricht. Sie gehört zu den wenigen Konfigurationen, die man einmal richtig macht und dann nie wieder anfassen muss.

Verwandte Grundlagen: NTP, Monitoring, TLS, Zertifikat.