Stay punctual with chrony

On Time

© Photo by Malvestida Magazine on Unsplash

© Photo by Malvestida Magazine on Unsplash

Article from Issue 225/2019

The chrony implementation of the network time protocol provides an alternative to the familiar NTP daemon.

Keeping your computer's clock set correctly is important; otherwise, a number of bad things can happen. For example, on a server, the logs can become inaccurate and confusing (and therefore insecure and ineffective). Also, when all files on your server or your desktop are modified or accessed, the time is noted. For day-to-day tasks, this timekeeping is moderately important, but for security it can be key, as you might imagine, if an attacker changes files on a system.

Networking can become disorganized, too. You may find with older implementations of secure web pages (SSL, Secure Sockets Layer) that the time on your desktop machine must have the correct time for the connections to work as expected.

Moreover, many anti-spam email systems treat time-warped email sent from the future as unwanted spam by default. Some systems instantly and silently refuse to process the offending email in any way, shape, or form. Finally do not forget that scheduled tasks (e.g., downloading new packages) also get messed up if your system clock is skewed.

In this article, I show you a lightweight alternative to the long-residing champion of time synchronization ntpd, the network time protocol daemon. The excellent ntpd has been found on many a Unix-like operating system (OS) for decades. Another kid on the block, however, is called chrony [1], which has been around since dial-up modems were singing high-pitched cacophonies all over the planet. Rest assured, then, that it's a time-tested and trusted piece of software. I'll run through the basics of its installation and operation and how to secure it for servers and desktops alike.

What Time Is It?

The chrony package installed on my Debian derivative Ubuntu/Mint box offers the following additional packages: libtomcrypt0, libtommath0, and timelimit. Thankfully, they take up barely any disk space because the clever chrony is so lightweight and performant. At installation, the timely chrony managed to configure itself at lightning speed and then synchronize automatically with four remote time servers.

Two main binaries compose the chrony package: The daemon chronyd, which sits quietly running in the background, and chronyc (Listing 1), which is a command-line interface (CLI) program for adjusting an already running chronyd.

Listing 1


$ chronyc sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
^-       3   6    17    32  +5747us[+5747us] +/-  113ms
^*             2   6    17    32    +33ms[  +17ms] +/-   92ms
^-                  2   6    17    31    +11ms[  +11ms] +/-   38ms
^-     2   6    17    31  +1181us[+1181us] +/-   72ms

If you've used ntpd before, the output looks familiar and is relatively easy to understand: The network is connecting to four clocks and tells where in the pecking order (Stratum) they are for accuracy, with the times presented relative to your network time. In super-simple terms, the higher the stratum the more accurate the clock. A stratum 1 server, for example, might be connected to a reference clock or some other type of atomic clock or similarly reliable device. You will not see a stratum 0 device connected to a network by design, because such a reference clock would need a time server to do its networking for it.

Just typing chronyc without arguments will offer you a familiar CLI prompt, from which you can type a number of native chrony commands (or you can enter them directly after the command, which I'll touch on in a moment). Table 1 shows the CLI commands available, as listed by chronyc help. As you can see, chrony is highly configurable.

Table 1

chronyc Commands



accheck <address>

Check whether NTP access is allowed to <address>


Check how many NTP sources are online/offline

add peer <address>

Add a new NTP peer

add server <address>

Add a new NTP server

allow [<subnet-addr>]

Allow NTP access to that subnet as a default

allow all [<subnet-addr>]

Allow NTP access to that subnet and all children

burst <n-good>/<n-max> [<mask>/<masked-address>]

Start a rapid set of measurements


Report on clients that have accessed the server

cmdaccheck <address>

Check whether command access is allowed to <address>

cmdallow [<subnet-addr>]

Allow command access to that subnet as a default

cmdallow all [<subnet-addr>]

Allow command access to that subnet and all children

cmddeny [<subnet-addr>]

Deny command access to that subnet as a default

cmddeny all [<subnet-addr>]

Deny command access to that subnet and all children


Close and reopen logfiles

delete <address>

Remove an NTP server or peer

deny [<subnet-addr>]

Deny NTP access to that subnet as a default

deny all [<subnet-addr>]

Deny NTP access to that subnet and all children


Dump all measurements to save files

local off

Disable server capability for unsynchronized clock

local stratum <stratum>

Enable server capability for unsynchronized clock

makestep [<threshold> <updates>]

Correct clock by stepping

manual off|on|reset

Disable/enable/reset settime command and statistics

manual list

Show previous settime entries

maxdelay <address> <new-max-delay>

Modify maximum round-trip valid sample delay for source

maxdelayratio <address> <new-max-ratio>

Modify maximum round-trip delay ratio for source

maxdelaydevratio <address> <new-max-ratio>

Modify maximum round-trip delay to standard deviation of round-trip delay ratio for source

maxpoll <address> <new-maxpoll>

Modify maximum polling interval of source

maxupdateskew <new-max-skew>

Modify maximum skew for a clock frequency update to be made

minpoll <address> <new-minpoll>

Modify minimum polling interval of source

minstratum <address> <new-min-stratum>

Modify minimum stratum of source

offline [<mask>/<masked-address>]

Set sources in subnet to offline status

online [<mask>/<masked-address>]

Set sources in subnet to online status

password [<new-password>]

Set command authentication password

polltarget <address> <new-poll-target>

Modify poll target of source


Reselect synchronization source


Print current real-time clock (RTC) performance parameters

settime <date/time>

Manually set the daemon time (e.g., Nov 21, 1997 16:30:05 or 16:30:05)


Display current time smoothing state

smoothtime reset|activate

Reset/activate time smoothing

sources [-v]

Display information about current sources

sourcestats [-v]

Display estimation information about current sources


Display system time information


Correct RTC relative to system clock

waitsync [max-tries [max-correction [[max-skew]]]

Wait until synchronized


Save RTC parameters to file

authhash <name>

Set command authentication hash function

dns -n|+n

Disable/enable resolving IP addresses to hostnames

dns -4|-6|-46

Resolve hostnames only to IPv4/IPv6/both addresses

timeout <milliseconds>

Set initial response timeout

retries <n>

Set maximum number of retries


Leave the program


Generate this help

You can run your commands of choice directly on the CLI or within the chrony shell. This flexibility could help with scripting. The tracking command, for example, offers a very useful summary of chrony's status (Figure 1) and can be achieved with either

$ chronyc tracking


$ chronyc
chronyc> tracking
Figure 1: The chrony tracking command offers a useful summary.

Next, I'll look at the config file that runs the super-slick chrony.

You're Late

The main file to read is located (on my Debian derivative) at /etc/chrony/chrony.conf. In the chrony directory, you'll also find the keys file if you want to change authentication options. A number of useful comments can help when you're unsure about an option in the main file. In a moment, I'll look at three areas you might want to consider altering.

Additionally, first have a look at the excellent logging found, unsurprisingly, under /var/log/chrony. In that directory, you'll find the statistics.log, measurements.log, and tracking.log files. As you'd expect, the considerate chrony drops a logrotate profile in place to keep your system sane and juggles your logs automatically once a week by default. I'd recommend having a rummage in those three logfiles if you're tuning your time server sources. More on that in a moment.

Even a Stopped Clock …

At least two or three worthwhile changes can help you take full advantage of the trimmed-down ntpd model offered by chrony to help limit your attack surface. I'd recommend exploring these yourselves, because differing versions of chrony might do things slightly differently. For example, I think some defaults were changed in version 2.0.

Although chrony is a feature-filled time server, it's safe to say that not all the features will be required in most cases. As I alluded to at installation time, it was up and running in a few seconds.

You might simply want to keep your local clock synced, rather than allowing other machines to ask your machine the time. The venerable chrony allows you to bind to your localhost ( with the bindcmdaddress option, which you can add to the config file mentioned above. Of course, you'll need to bounce your chronyd daemon after making a change (most likely with the systemctl restart chrony command).

Adding the following option to your config file will ensure that the wider network to which your system is connected can't connect to chronyc:


If you're using IPv6, make sure this option follows the above IPv4 option:

bindcmdaddress ::1

The well-written FAQ [2] provides much more information.

To disable all NTP client or peer connections completely, add

port 0

to the config file. This option stops requests ever even making it to the chrony daemon.

You can also consider this similar-looking option,

cmdport 0

with which you can switch off all access to chronyc (the CLI binary), outside of the local chrony user (which it runs under) and the machine's root user.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Admin Workshop: NTP

    Networks often require very accurate timekeeping. The Network Time Protocol provides the time with precision.

  • RHEL 7

    On June 10, Red Hat launched a new major release of its enterprise distribution, RHEL 7. We take a look to find out where RHEL is headed.

  • Hardening Linux for Production Use

    To protect your production server from attacks, employ these common security tools to help safeguard your system.

  • Ajenti

    Ease the process of managing Linux installations remotely with the web-based Ajenti control panel.

  • Charly's Column – Precise Timekeeping

    After the idea of procuring an atomic clock failed to thrill the other members of Charly's household, our intrepid columnist simply decided to tap into the timekeeping of a GPS satellite. In doing so, he ensured the kind of punctuality at home that only large data centers actually need. Precisely.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Find SysAdmin Jobs