Authenticated NTP with chrony needs per-peer keys and a rotation plan

In the realm of network time synchronization, Chrony's authenticated mode demands careful key management. Authentication relies on Network Time Security or shared symmetric keys, but both require a well-thought-out operational plan. Chrony's documentation advises generating 128-bit or longer random keys, with a minimum 80-bit length considered insecure. These keys must match on both communicating peers for successful authentication.

Mismanaging keys can have dire consequences. If a compromised key is shared across the entire time service fleet, the breach extends to every association. To mitigate this, each peer should utilize distinct keys, either for individual client-server pairs or explicitly defined groups. The key file should be stored with stringent permissions and excluded from any backups leaving the time service's trusted domain.

When rotating keys, introduce the new key while maintaining the old one long enough for both ends to update. Confirm the new key's correct specification using chronyc authdata, then retire the old key only after all clients have transitioned and the source remains operational. It's a common oversight to prioritize availability over authentication; however, operators should scrutinize the selected source, offset, root distance, and authentication state before making their decision.

Network Time Security is generally preferable in environments that support it, as it establishes protected keys via TLS instead of distributing static symmetric secrets. However, maintaining a fallback to unauthenticated NTP or a weaker association should be a deliberate policy decision, not a default response to a timeout. Strictly control time service exposure by limiting clients through daemon access controls and network policies, and segregate internal clients from external infrastructure when feasible.

Continuous monitoring is crucial. Track configuration changes, key file permissions, source alterations, and clock jumps. Alert on any host inadvertently adopting an unapproved source, even if its time offset appears normal. Upon a key compromise, rotate every association that utilized the key, validate peer configurations, and meticulously inspect logs from the exposure period.

If clock integrity is in question, cross-reference application events with an independent time source before piecing together an incident timeline.

For further information, refer to Chrony's configuration manual, FAQ, and chronyc reference.