Authenticated NTP with chrony needs per-peer keys and a rotation plan
Authenticated NTP with chrony needs per-peer keys and a rotation plan Time is an input to certificate validation, authentication logs and distributed transactions. An attacker who can influence an unauthenticated NTP a
Authenticated NTP with chrony needs per-peer keys and a rotation plan
Time is an input to certificate validation, authentication logs and distributed transactions. An attacker who can influence an unauthenticated NTP association may shift a host's clock or make it select a false source. Chrony supports authenticated time through Network Time Security or symmetric keys, but either choice needs an operational plan.
Symmetric NTP authentication uses a shared key file and a key identifier. The chrony configuration documentation recommends randomly generated keys of at least 128 bits and warns when a configured key is shorter than 80 bits. The same key and key identifier must be configured on both peers. A shared key copied across an entire fleet makes one host compromise affect every association.
Keep keys scoped to peers
Use a distinct key for each client-server pair or a small, explicitly defined group. Store the key file with restrictive permissions and exclude it from backups that travel beyond the time service's trust boundary. Do not put key material in a monitoring dashboard or ticket.
When rotating, introduce the new key identifier while retaining the old association long enough to update both ends. Confirm through chronyc authdata that the source reports the expected authentication mode and key identifier. Remove the old key only after every client has switched and the source remains healthy.
Do not let availability override authentication
Operators sometimes add several time sources and accept whichever responds. That can improve availability while hiding a source with a bad clock or an unexpected authentication mode. Review the selected source, offset, root distance and authentication state. Keep the source list intentional and map each address to a time service owner.
NTS is generally preferable when the environment supports it because it establishes protected keys through TLS rather than distributing static symmetric secrets. A fallback to unauthenticated NTP or a weaker association should be a documented policy decision, not an automatic reaction to a timeout.
Restrict service exposure
Do not serve time to arbitrary networks. Restrict clients with the daemon's access controls and network policy, and separate internal clients from external infrastructure where possible. Monitor configuration changes, key file permissions, source changes and clock jumps. Alert on a host that starts using an unapproved source even if its time offset looks normal.
After a key compromise, rotate every association that used the key, validate peer configuration and inspect logs around the exposure window. If clock integrity is uncertain, correlate application events with an independent time source before reconstructing an incident timeline.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.