Accurate Time on Linux: A Quick, Step‑by‑Step NTP Configuration Guide

Keeping accurate time on Linux servers is foundational for logging, authentication, scheduling, and distributed systems. This article provides a concise, step‑by‑step NTP configuration guide with practical commands, verification techniques, and security hardening tips. It targets system administrators, developers, and business users running VPS or dedicated infrastructure who need reliable time synchronization for services such as databases, TLS certificates, cron jobs, and clustered applications.

Why Accurate Time Matters

Accurate system time is more than convenience — it affects core system functions:

• Security: Kerberos, TLS certificate validity, and log timestamps rely on synchronized clocks.
• Distributed systems: Databases, consensus algorithms, and event ordering require consistent time across nodes.
• Auditing and troubleshooting: Accurate timestamps enable proper correlation of logs and forensic analysis.
• Scheduling: Cron jobs and batch processes depend on the system clock.

Time Synchronization Technologies on Linux

There are several daemons and services available. Choosing the right one depends on your workload.

ntpd (Classic NTP)

ntpd (from the NTP Project) is the traditional daemon. It supports steep algorithms for gradual clock discipline and many advanced options. It’s robust for long‑running servers but can be heavier to configure and slower to step large time differences by default.

chrony

chrony is increasingly popular for virtualized and cloud environments (like VPS), where clocks can drift more when VMs are paused or migrated. chrony converges faster, handles intermittent network connectivity well, and can step or slew the clock as configured. It is often recommended for container and cloud deployments.

systemd‑timesyncd

For minimal needs, systemd includes systemd‑timesyncd, a lightweight NTP client. It’s sufficient for many desktop and simple server use cases but lacks advanced features and doesn’t act as an NTP server for other systems.

Other implementations

NTPsec is a security‑focused fork of ntpd, aiming to remove legacy vulnerabilities. Use it when you need NTP compatibility but require a smaller attack surface.

Core Concepts: NTP Servers, Stratum, and Drift

Understanding these terms helps when configuring clients and planning architectures:

• Stratum: A hierarchical distance metric from the reference clock. Stratum 0 refers to high‑precision devices (GPS, atomic clocks). Stratum 1 servers connect to stratum 0 and so on. Prefer lower stratum sources when possible.
• Drift file: A file storing measured clock drift for faster corrections on restart. Daemons like chrony and ntpd use drift files to improve accuracy.
• Step vs Slew: Step immediately adjusts the clock (useful for large offsets), while slew adjusts gradually to avoid disrupting time‑sensitive applications.

Practical Step‑by‑Step NTP Configuration

The following sections provide commands and configuration snippets for the two most common choices: chrony and ntpd. The examples assume a Debian/Ubuntu or RHEL/CentOS environment; package manager commands are included.

Option A — Configure chrony (recommended for VPS/cloud)

1) Install chrony

• Debian/Ubuntu: sudo apt update && sudo apt install -y chrony
• RHEL/CentOS: sudo yum install -y chrony or sudo dnf install -y chrony

2) Edit /etc/chrony/chrony.conf and add reliable NTP servers, for example:

server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server time.cloudflare.com iburst

Key options:

• iburst speeds up initial synchronization.
• minsources and maxsources control peer selection.
• Use allow if you want to provide time service to a trusted LAN.

3) Start and enable the service

• sudo systemctl enable --now chronyd

4) Verify synchronization

• chronyc tracking — shows current offset, jitter, and estimated error.
• chronyc sources -v — lists NTP sources and their status.

5) Persist hardware clock (RTC) if desired

• sudo hwclock --systohc — write system time to RTC.

Option B — Configure ntpd (classic)

1) Install ntp

• Debian/Ubuntu: sudo apt update && sudo apt install -y ntp
• RHEL/CentOS: sudo yum install -y ntp

2) Edit /etc/ntp.conf, example servers:

server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst

3) Set driftfile and restrict lines for security

driftfile /var/lib/ntp/ntp.drift

Security example to block unwanted queries:

restrict default nomodify noquery nopeer notrap
restrict 127.0.0.1

4) Start and enable

• sudo systemctl enable --now ntp (or ntpd on some systems)

5) Verify

• ntpq -p — peer list and offsets.
• ntpstat — concise sync state (available on some distros).

Network and Firewall Considerations

NTP uses UDP port 123. When your host is behind a firewall or running iptables/nftables, permit outbound and inbound traffic as required:

• Allow outbound UDP/123 to upstream servers (recommended for clients).
• If acting as an NTP server for a LAN, allow inbound UDP/123 from trusted subnets only.
• Example iptables rule to allow client queries from LAN: iptables -A INPUT -p udp --dport 123 -s 192.168.0.0/24 -j ACCEPT

Hardening and Best Practices

Time services can be abused for amplification attacks or become an information leak. Apply these best practices:

• Restrict access: Configure your NTP daemon to refuse control queries from untrusted hosts (use restrict in ntp.conf or allow/deny in chrony).
• Use authenticated NTP: If you manage a private NTP hierarchy, use symmetric key authentication. chrony and ntpd support MAC‑based authentication.
• Monitor offsets and jitter: Set up monitoring (Prometheus exporters, scripts) to alert when offsets exceed thresholds.
• Log and audit: Keep logs of large steps or frequent adjustments — frequent stepping can indicate deeper problems like faulty RTC or host clock issues.
• Limit NTP server exposure: If running on a public VPS, avoid acting as a public stratum server unless required.

Troubleshooting Tips

Common issues and diagnostic commands:

• Large offset on startup: Check virtualization host time sync (VMM tools), suspend/resume behavior, and whether guest tools (like QEMU guest agent) are adjusting the clock.
• No sync: Verify UDP/123 connectivity (sudo tcpdump -n -i any udp port 123), ensure correct server names and DNS resolution, and check SELinux audit logs if enabled.
• Frequent stepping: Review drift file and consider switching to slew behavior if applications cannot tolerate steps. In chrony set makestep or tweak maxslewrate.
• Virtual machine drift: Use chrony, which handles VM clock drift better. Also disable host‑guest time sync if it conflicts with the guest NTP daemon.

When to Choose Which NTP Stack

Selection depends on environment and requirements:

• chrony: Best for cloud/VPS, laptops, and transient networks. Fast convergence, good for VMs.
• ntpd: Suitable for legacy setups and networks requiring classical NTP behaviors.
• systemd‑timesyncd: Lightweight choice for desktops or simple servers where acting as an NTP server is unnecessary.
• NTPsec: Consider when security auditability and reduced attack surface are priorities.

Additional Recommendations for Production

For enterprise deployments:

• Use a mix of public and private time sources (multiple upstream servers across different strata and networks) to avoid single points of failure.
• Deploy at least one internal stratum 1 server with a hardware reference (GPS) if extremely high accuracy is required.
• Document your NTP architecture and include time monitoring in runbooks and incident response plans.
• Test time behavior during maintenance operations (reboots, snapshots, migrations) to ensure deterministic outcomes.

Summary

Accurate time on Linux is straightforward once you pick the right tool and follow disciplined configuration and security practices. For most VPS and cloud use cases, chrony offers the best mix of speed and stability. For legacy setups, ntpd remains a capable choice. Always verify synchronization with chronyc or ntpq, secure your server by restricting access, and monitor offsets to catch issues early.

If you run servers on a cloud VPS and want reliable, low‑latency hosting to pair with proper time synchronization, consider exploring reliable hosting options such as VPS.DO and specifically their USA VPS offering for US‑based deployments. These environments are well suited for the stable network connectivity required by NTP clients and can simplify deploying a consistent time infrastructure across your fleet.