Heimserver & Self-Hosting

Zeitsynchronisierung auf einem Debian-Homeserver - Eine gemeinsame Uhr fuer Protokolle und Dienste

Geschrieben von Adam Muiz Aktualisiert: 07 Sep 2026 11 Min. gelesen
Zeitsynchronisierung auf einem Debian-Homeserver - Eine gemeinsame Uhr fuer Protokolle und Dienste

Ein Homeserver kann die richtige Uhrzeit anzeigen und dennoch eine unzuverlässige Uhr haben. Die Zeitzone kann stimmen, während die Netzwerksynchronisierung fehlschlägt. Ein Zeitdienst kann laufen, obwohl seine Quelle nicht erreichbar ist. Zwei Rechner können einzeln betrachtet plausibel wirken und dennoch so stark voneinander abweichen, dass eine gemeinsame Ereigniszeitleiste verwirrend wird.

Die hilfreiche Frage lautet daher nicht nur: „Welche Uhrzeit zeigt der Server an?“ Wichtiger ist: Woher stammt diese Zeit, wann wurde sie zuletzt geprüft und welche Hinweise zeigen, dass die Uhr weiterhin vertrauenswürdig ist?

Dieser Artikel beschreibt eine ausschließlich lesende Prüfung für einen gewöhnlichen Debian-Homeserver. Er vergleicht systemd-timesyncd und chrony, ohne vorauszusetzen, dass eines von beiden installiert ist, und beschränkt sich auf den normalen Serverbetrieb statt auf Präzisionszeitmessung. Er behauptet weder ein Messergebnis von Adams Server noch ein allgemeingültiges Genauigkeitsziel für jede Arbeitslast.

Warum eine gemeinsame Zeitleiste wichtig ist

Die Uhrzeitsynchronisierung wirkt kosmetisch, bis mehrere Systeme dasselbe Ereignis beschreiben. Ein Reverse Proxy protokolliert eine Anfrage, eine Anwendung einen Fehler, eine Datenbank einen Schreibvorgang und eine Firewall eine Verbindung. Weichen ihre Uhren voneinander ab, kann das Sortieren nach Zeitstempeln eine Geschichte ergeben, die nie stattgefunden hat.

Das Debian Administrator's Handbook nennt diesen betrieblichen Nutzen ausdrücklich: Synchronisierte Rechner erleichtern das Abgleichen von Protokollen und die Rekonstruktion eines Angriffsablaufs. Eine genaue Wanduhrzeit ist außerdem für Software relevant, die Zeitfenster bewertet, etwa die Gültigkeit von Zertifikaten oder geplante Aufgaben. Die notwendige Toleranz bestimmt jedoch die Anwendung. Ein persönlicher Blog und eine verteilte Datenbank benötigen nicht automatisch dieselben Zeitgarantien.

NTP verspricht nicht, dass jede Uhr vollkommen korrekt wird. RFC 5905 beschreibt Messungen und Algorithmen zur Schätzung von Offset, Netzwerkverzögerung, Dispersion und Jitter sowie zur Auswahl und Kombination geeigneter Quellen, um die Systemuhr zu disziplinieren. Diese Schätzungen bleiben mit Unsicherheit behaftet. Netzüberlastung, asymmetrische Routen, eine fehlerhafte Quelle oder ein getrennter Client können das Ergebnis beeinträchtigen.

Vier häufig vermischte Dinge trennen

Zeitzone

Eine Zeitzone bestimmt, wie ein Zeitstempel für Menschen dargestellt wird. Der Wechsel von UTC zu Asia/Jakarta ändert die Darstellung, nicht den Synchronisierungszustand der Uhr. Eine korrekte Zeitzone mit falscher Systemuhr ergibt weiterhin eine falsche Ortszeit.

Echtzeituhr und Systemuhr

Ein typischer Rechner besitzt eine Hardware-Echtzeituhr (RTC), die eine ungefähre Zeit über Abschaltungen hinweg erhalten kann, sowie die vom Betriebssystem während des Linux-Betriebs genutzte Uhr. Die RTC kann beim Start einen Ausgangswert liefern; ein Netzwerkzeit-Client kann anschließend die Systemuhr korrigieren und disziplinieren. Debians timedatectl(1)-Dokumentation empfiehlt, die RTC nach Möglichkeit in UTC zu führen, weil lokale Zeit bei Zeitzonenwechseln und Sommerzeitübergängen Mehrdeutigkeiten erzeugt.

Wanduhr und monotone Uhr

Anwendungen müssen zudem zwischen „Welches Datum und welche Uhrzeit ist jetzt?“ und „Wie viel Zeit ist vergangen?“ unterscheiden. Linux stellt CLOCK_REALTIME für die Wanduhrzeit und CLOCK_MONOTONIC für die Messung verstrichener Zeit bereit. Das Linux-Handbuch zu clock_gettime(2) erklärt, dass die Echtzeit diskontinuierliche Sprünge erfahren kann, während die monotone Uhr solchen Wanduhrsprüngen nicht folgt. Zeitsynchronisierung repariert keine Anwendung, die Wanduhrzeit unbedacht für Dauern und Timeouts verwendet.

Synchronisierungszustand

Synchronisierung ist die fortlaufende Beziehung zwischen Systemuhr und einer oder mehreren Referenzquellen. Sie ist nicht gleichbedeutend mit einem lediglich aktivierten Dienst. Eine belastbare Prüfung fragt, ob eine Quelle kürzlich akzeptable Messungen geliefert hat und ob die verbleibende Unsicherheit zur Arbeitslast passt.

Vor jeder Änderung prüfen

Am Anfang stehen Befehle, die die Uhr nicht verändern:

date --iso-8601=seconds
timedatectl status
systemctl list-units --type=service | grep -E 'chrony|timesync|ntp'

Der erste Befehl liefert einen eindeutigen Zeitstempel mit UTC-Offset. timedatectl status zeigt lokale Zeit, UTC, RTC-Zeit, Zeitzone, den Synchronisierungszustand der Systemuhr und den Status eines erkannten Netzwerkzeitdienstes. Die Dienstsuche hilft, den tatsächlichen Anbieter festzustellen, statt für jede Debian-Installation denselben vorauszusetzen.

Diese Felder sind getrennt zu lesen. „NTP service: active“ besagt, dass ein bekannter Synchronisierungsdienst aktiv ist; allein daraus folgt nicht, dass kürzlich eine Messung akzeptiert wurde. „System clock synchronized: yes“ ist ein stärkerer Hinweis, bleibt aber eine Zusammenfassung des lokalen Stacks und keine externe Genauigkeitsgarantie.

Ist systemd-timesyncd der Anbieter, lassen sich die aktuelle Messung und das jüngste Protokoll so prüfen:

timedatectl timesync-status
systemctl status systemd-timesyncd.service
journalctl -u systemd-timesyncd.service --since today

Das systemd-timesyncd(8)-Handbuch dokumentiert timesync-status für diesen Zweck. Die Ausgabe kann ausgewählten Server, Abfrageintervall, Stratum, Root-Distanz, Offset, Verzögerung, Jitter, Paketzahl und Frequenzkorrektur enthalten. Eine Momentaufnahme ist nützlich; eine über längere Zeit beobachtete Folge ist aussagekräftiger.

Ist chrony installiert, sollte dessen eigene Schnittstelle verwendet werden:

chronyc tracking
chronyc sources -v

Das offizielle chronyc(1)-Handbuch beschreibt tracking als Ansicht der Systemuhrleistung und sources -v als Ansicht des Quellenzustands. In der Quellenliste kennzeichnet * die ausgewählte beste Quelle, + eine weitere kombinierte Quelle, x eine als inkonsistent bewertete Quelle und ? eine derzeit nicht auswählbare Quelle. Das Feld Reach fasst kürzlich gültige Antworten zusammen; es ist gemeinsam mit den übrigen Feldern und nicht als alleiniger Zustandswert zu interpretieren.

Den Client nach dem benötigten Nachweis wählen

systemd-timesyncd ist bewusst klein gehalten. Sein Handbuch beschreibt ihn als reinen SNTP-Client, der große Offsets durch einen Sprung und kleinere Differenzen schrittweise korrigiert. Für einen einfachen Host mit einer vertrauenswürdigen, zuverlässigen Quelle kann diese engere Rolle vollkommen ausreichen. Die Integration mit timedatectl erleichtert zudem eine grundlegende Prüfung.

chrony deckt einen größeren betrieblichen Bereich ab. Seine offiziellen FAQ und Handbücher dokumentieren die gleichzeitige Verwendung und Auswahl mehrerer Quellen, detaillierte Offset- und Frequenzberichte, den Umgang mit unterbrochenen Netzwerkverbindungen, den NTP-Serverbetrieb und optionale Network Time Security (NTS). Diese Fähigkeiten sind hilfreich, wenn Quellen voneinander abweichen, die Verbindung instabil ist oder eine stärkere Überwachung benötigt wird.

Dies ist kein Benchmark, der einen Client grundsätzlich zum besseren erklärt. Einfachheit ist bei einfachen Anforderungen ein Vorteil; umfangreichere Quellenauswahl ist bei einem entsprechenden Fehlermodell ein Vorteil. Entscheidend ist, genau eine Komponente als Verantwortliche für die Disziplinierung der Systemuhr zu identifizieren. Ein zweiter Client sollte nicht nur deshalb aktiviert werden, weil die Statusausgabe des ersten ungewohnt ist.

Auch die Quellenkonfiguration verlangt Zurückhaltung. timesyncd.conf(5) dokumentiert Administrator-Drop-ins unter /etc/systemd/timesyncd.conf.d/, die Änderungen an herstellereigenen Dateien vorzuziehen sind. chrony unterscheidet server- von pool-Einträgen und kann aus mehreren aufgelösten Quellen auswählen. In beiden Fällen sollten Quellen mit verständlicher Betriebsrichtlinie verwendet, Regeln öffentlicher Pools beachtet und Abfrageintervalle nicht ohne nachgewiesenen Grund verkürzt werden.

Gesund bedeutet mehr als „Active“

Kein einzelnes Feld beantwortet jede Zeitfrage. Eine praktische Bewertung kombiniert mehrere Signale:

  • Dienstzustand: Läuft der vorgesehene Client, und fehlt ein unerwarteter konkurrierender Client?
  • Aktuelle Quelle: Ist eine Quelle ausgewählt und erreichbar, und liefert sie akzeptierte Messungen?
  • Offset und Unsicherheit: Sind gemeldeter Offset, Verzögerung, Dispersion oder Root-Distanz für dieses Netzwerk und diese Arbeitslast plausibel?
  • Verlauf: Bleibt der Client über Neustarts, Verbindungsunterbrechungen und gewöhnliche Überlastungsphasen hinweg gesund?
  • Anwendungsanforderung: Ist der beobachtete Zustand für die davon abhängigen Komponenten gut genug?

Besondere Vorsicht verlangt das Stratum. Es beschreibt die Position einer Quelle in der NTP-Hierarchie. Eine niedrigere Zahl beweist nicht automatisch einen besseren Pfad von diesem Client: Netzwerkverzögerung, Quellenstabilität, Unsicherheit und Übereinstimmung mit anderen Quellen bleiben relevant. Ebenso ist ein kleiner Offset in einer Befehlsausgabe eine Messung zu einem Zeitpunkt und kein lebenslanges Genauigkeitszertifikat.

Die Startreihenfolge kann eine Genauigkeitslücke öffnen

Ein Server kann mit einer schlechten RTC-Schätzung starten und sich erst synchronisieren, wenn das Netzwerk verfügbar ist. Dadurch entsteht ein Zeitfenster, in dem frühe Dienste eine ungenaue Wanduhr sehen. Laut systemd-timesyncd-Handbuch kann das Wiederherstellen eines gespeicherten Zeitstempels die Zeit über Neustarts hinweg ungefähr monoton voranschreiten lassen, auch auf Systemen ohne batteriegepufferte RTC. Es nennt außerdem einen wichtigen Unterschied: Die gewöhnliche Initialisierung hält nicht jeden Dienst an, bis eine genaue Netzwerkquelle erreicht wurde.

Kann eine Anwendung vor einer genauen Synchronisierung tatsächlich nicht sicher starten, ist dies eine ausdrücklich zu entwerfende und zu testende Abhängigkeit, keine Folgerung aus „NTP enabled“. systemd stellt für diese Art der Reihenfolge systemd-time-wait-sync.service und time-sync.target bereit. Ob gewartet, nach einer Frist abgebrochen oder eingeschränkt weitergearbeitet wird, bleibt jedoch eine Anwendungsentscheidung. Den gesamten Start unbegrenzt von einem unerreichbaren öffentlichen Dienst abhängig zu machen, kann einen anderen Fehler erzeugen.

Große Korrekturen bringen einen weiteren Zielkonflikt mit sich. Sowohl systemd-timesyncd als auch chrony unterscheiden sofortige Sprünge von schrittweisem Slewing. Das chrony-Handbuch warnt, dass Zeitsprünge manche Software erheblich beeinträchtigen können. Ein kontrollierter Sprung nahe am Systemstart kann sinnvoll sein, solange kaum zustandsbehaftete Arbeit läuft; auf einem ausgelasteten Server sollte ein erzwungener Sprung kein beiläufiger Reflex bei der Fehlersuche sein.

NTP-Sicherheit hat Grenzen

Einfache Netzwerkzeit ist nicht automatisch authentifiziert, nur weil sie von einem bekannten Hostnamen stammt. Ein Angreifer auf dem Übertragungsweg kann versuchen, nicht authentifizierte Nachrichten zu fälschen, zu verändern, zu verzögern, umzuleiten oder zu verwerfen. Mehrere Quellen und Plausibilitätsgrenzen können einige Risiken verringern, verwandeln nicht authentifizierte Pakete aber nicht in einen kryptografischen Nachweis.

RFC 8915 definiert NTS für den Client-Server-Modus von NTP. Es verwendet TLS zum Schlüsselaustausch und authentifizierte NTP-Erweiterungsfelder für die folgenden Zeitaustausche. NTS kann Server und Pakete authentifizieren, vor Wiederholungen schützen und eine Antwort an eine Anfrage binden. Einen Angreifer auf dem Pfad kann es weiterhin nicht am Verzögern oder Verwerfen von Paketen hindern. Authentifizierte Zeit ist daher ein stärkerer Nachweis, keine magische Gewissheit.

NTS besitzt zudem ein Bootstrap-Problem: Die Prüfung eines TLS-Zertifikats hängt selbst von einem hinreichend plausiblen lokalen Datum ab. Eine funktionierende RTC oder ein sicher wiederhergestellter früherer Zeitstempel kann helfen. Das Abschalten der Zertifikatszeitprüfung schwächt genau die Zusicherung, die NTS liefern soll, und ist keine routinemäßige Reparatur.

Eine kurze Fehleruntersuchung

Fehlt die Synchronisierung oder ist sie veraltet, sollte der Pfad der Reihe nach geprüft werden, statt mehrere Einstellungen gleichzeitig zu ändern:

  1. Zeitzone, RTC-Interpretation, Zusammenfassung der Systemuhr und aktiven Zeit-Client bestätigen.
  2. Anbieterspezifischen Zustand und Protokolle auf ausgewählten Server, letzte akzeptierte Messung und eindeutige Fehler prüfen.
  3. Prüfen, ob die Quellennamen aufgelöst werden. Ein DNS-Fehler kann wie ein Zeitfehler aussehen.
  4. Routing und Firewall-Richtlinie prüfen. Traditioneller NTP-Austausch verwendet normalerweise UDP-Port 123; der NTS-Schlüsselaustausch nutzt eine separate TLS-Verbindung und benötigt kompatible Server.
  5. Das Verhalten über mehrere Abfragen vergleichen, statt nach einer fehlenden Antwort sofort eine Uhränderung zu erzwingen.
  6. Nach der Wiederherstellung die zeitnutzenden Anwendungen und nicht nur den Zeit-Daemon prüfen.

Unterbrochene Verbindungen verändern den Erfolgsmaßstab. Ein vom Internet getrennter Homeserver kann eine externe Quelle nicht fortlaufend befragen. Ein geeigneter Client kann jedoch die Drift des Oszillators schätzen und Messungen fortsetzen, sobald die Verbindung zurückkehrt. Dadurch bleibt die Uhr offline nicht unbegrenzt korrekt. Der Fehler wird vielmehr beherrschbarer und, ebenso wichtig, beobachtbar.

Zeit zu einer ausdrücklichen Abhängigkeit machen

Eine verlässliche Serveruhr besteht nicht aus einem einzelnen beeindruckenden Offset-Wert. Sie ist eine dokumentierte Kette: Die RTC liefert beim Start einen plausiblen Ausgangspunkt, ein bekannter Client diszipliniert die Systemuhr, vertrauenswürdige Quellen bleiben erreichbar, der Status macht Unsicherheit sichtbar und Anwendungen verwenden Wand- oder monotone Zeit entsprechend ihrer Messaufgabe.

Die kleinste sinnvolle Wartungsgewohnheit besteht darin, den verantwortlichen Client zu dokumentieren, seinen anbieterspezifischen Zustand nach wichtigen Netzwerk- oder Systemänderungen zu prüfen und „gut genug“ für die abhängigen Dienste zu definieren. NTP kann eine gemeinsame Zeitleiste schaffen, aber nicht entscheiden, wie viel Unsicherheit eine Anwendung toleriert. Diese letzte Grenze bleibt eine lokale technische Frage.

References