Chrony

Search for Chrony in the Marketplace, select the SecureAnyCloud publisher, and click Create.

Configure the Network Security Group to allow UDP 123 from the clients that will synchronise against the server, and TCP 22 for administration. Keep UDP 123 restricted to the subnets you serve. There is no need to expose it to the public internet for a private-network time server.

RG="time-prod"; LOCATION="eastus"; VM_NAME="chrony1" IMAGE_URN="sac1647283583153:chrony-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:chrony-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 123 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

Open UDP 123 only to the client subnets you intend to serve.

On first boot, the image detects the Azure Hyper-V host clock and adds it as a high-accuracy PTP reference. It also resolves this VM's address, writes the informational note /root/chrony-info.txt, and restarts chrony so it serves time within seconds. SSH in as azureuser and read the note:

sudo cat /root/chrony-info.txt

The note records this server's role, the address and port it serves, the detected PTP reference clock, and the path to the configuration. Chrony has no password, so the note holds no secret.

chrony.service is active, and chronyd --version reports 4.5. The ss command confirms that chronyd is listening on UDP 123 on all interfaces, ready to answer clients on your allowed networks.

systemctl is-active chrony.service chronyd --version sudo ss -ulnp | grep -E ':123'

The ss output shows chronyd bound to 0.0.0.0:123 and [::]:123, the NTP server port. The command port 323 is bound only to 127.0.0.1 and ::1, so it is never reachable from off the machine.

chronyc tracking reports the server's own synchronisation state. Leap status : Normal means the server is synchronised and safe to serve time. The Reference ID and Stratum identify the upstream source the server is locked to. The System time and RMS offset lines show how tightly the clock is disciplined, typically well under a millisecond.

chronyc tracking

On Azure, the server locks to the Hyper-V host clock (shown as PHC0, stratum 0 to 1) or to a stratum 2 NTP pool server. It reports Leap status : Normal with a sub-millisecond system time offset.

chronyc sources lists every source the server is disciplining from, with a state marker in the first column:

• * is the currently selected best source.
• + is a combined source.
• # marks a local hardware reference clock such as the Azure PHC.
• ? or - are sources that are not currently selected.

chronyc sourcestats shows the measured offset and skew for each source.

chronyc sources chronyc sourcestats

On Azure, you see the PHC0 hardware reference clock alongside several ntp.ubuntu.com and pool servers, with one source marked * as the current best.

This is the security posture that matters for an NTP server. The shipped allow list answers only the local host and the RFC1918 private ranges, so a query from a public source address is dropped.

Read the allow list and confirm that the command port is loopback only. Then use the bundled self-check to prove that the server answers a real NTP client query on port 123.

sudo grep -E '^(allow|cmdport|bindcmdaddress)' /etc/chrony/chrony.conf
sudo ss -ulnp | grep -E ':323' python3 /usr/local/sbin/ntp-selfcheck.py 127.0.0.1

The allow lines are scoped to 127.0.0.1, ::1 and the private ranges, and never to allow all. The command port 323 is bound only to loopback. The self-check sends a real NTP client request to port 123 and prints OK with the returned time. This proves that the server serves NTP while remaining scoped to your private networks.

Configure your other machines to use this instance as their NTP server, using its private IP address (shown in the info note from Step 3). Run the examples below on each client, not on this server.

# --- Linux client running chrony ---
# Add a line to the client's /etc/chrony/chrony.conf, then restart chrony: # server <server-ip> iburst # # --- Linux client running systemd-timesyncd --- # Set NTP=<server-ip> in /etc/systemd/timesyncd.conf, then: # sudo systemctl restart systemd-timesyncd # # --- Windows client --- # w32tm /config /manualpeerlist:"<server-ip>" /syncfromflags:manual /update # # Verify from a Linux client that it is using this server: # chronyc sources # the server should appear, selected with a '*'

Replace <server-ip> with this instance's private IP address. The default allow list already covers the RFC1918 private ranges, so clients on your virtual network can synchronise immediately with no change on the server.

The shipped allow list covers the whole RFC1918 private space. To narrow it to your exact virtual network, or to serve a network outside RFC1918, edit the allow lines in /etc/chrony/chrony.conf and restart the service.

Only add networks you control. Never use allow all, which turns the server into an open amplifier.

# Edit /etc/chrony/chrony.conf and set the allow list to your exact VNet CIDR, e.g.
# allow 10.20.0.0/16
# Remove the broader ranges you do not need, then apply the change:
#
sudo systemctl restart chrony
# Confirm the new scope:
#
sudo grep -E '^allow' /etc/chrony/chrony.conf

Chrony validates the configuration on restart. If there is a syntax error, the service reports it in systemctl status chrony, so you can correct it before clients are affected.

Everything Chrony does is configured in /etc/chrony/chrony.conf, and the per-instance details are in the info note. Read both with sudo.

sudo cat /etc/chrony/chrony.conf
sudo cat /root/chrony-info.txt

The info note is 0600 root:root and holds no secret, because an NTP server has no login. It records the server's role, the address it serves, and the detected PTP reference for convenience.

• Restrict the NSG to your use case. Allow UDP 123 only from the client subnets you serve. There is no need to expose a private-network time server to the public internet.
• Keep the allow list tight. Only add subnets you control to the allow lines. Never use allow all, because that turns the server back into an open amplifier that can be abused for reflection attacks.
• Leave the command port loopback only. The chronyc command interface is bound to 127.0.0.1 and ::1, so it cannot be reached or reflected from off the machine. Keep it that way, and administer the server over SSH.
• Prefer the hardware reference on Azure. The Hyper-V host clock (PHC0) is a stratum 0 reference disciplined to Microsoft's time sources, and it is the most accurate option. It is configured automatically on first boot.
• Keep the OS patched. Unattended security upgrades remain enabled on the running VM.

Chrony is an open-source project distributed under the GNU General Public License version 2. This SecureAnyCloud image bundles the unmodified official Chrony package from Ubuntu.

SecureAnyCloud provides the packaging, the systemd hardening, the secure-by-default scoped allow configuration, the Azure PTP reference clock automation, the paired deploy guide, and 24/7 support with a guaranteed 24 hour response SLA.

SecureAnyCloud is not affiliated with or endorsed by the Chrony project. Chrony is a mark of its respective owner and is used here only to identify the software.

Deploy on Azure

Find Chrony NTP Time Server on Ubuntu 24.04 LTS on the Azure Marketplace, published by SecureAnyCloud. Deploy it from the Portal or the Azure CLI, as shown above.

Need Help?

Email sales@secureanycloud.com for deployment help, configuration questions, or licensing enquiries.

Deploy on Azure

Launch Chrony 4.5 on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Find Chrony on AWS Marketplace, published by SecureAnyCloud. Choose Continue to Subscribe, then Continue to Configuration, then Continue to Launch.

Select the Ubuntu 24.04 delivery option, your instance type (m5.large) and your key pair. Choose a security group that allows TCP 22 for administration plus UDP 123 from the client networks you want to serve.

SSH in with your EC2 key pair. For Ubuntu 24.04, the SSH login user is ubuntu, for example: ssh -i your-key.pem ubuntu@<public-ip>

ssh -i your-key.pem ubuntu@<public-ip>

On first boot, the image resolves this instance's address via EC2 instance metadata (IMDSv2) and writes a per-instance information note to /root/chrony-info.txt. Then systemd starts chronyd.

Chrony begins disciplining the clock from the Amazon Time Sync Service and the NTP pool immediately, because time synchronisation never waits on first boot. This completes within a minute.

Confirm that the service is active and synchronised to a real time source. chronyc tracking reports the reference source, the stratum, the current offset, and a Leap status of Normal once the clock is disciplined:

sudo systemctl start chrony 2>/dev/null || true systemctl is-active chrony chronyc tracking

The service reports active, the Reference ID shows 169.254.169.123 (the Amazon Time Sync Service), the offset is a few microseconds, and Leap status reads Normal.

chronyc sources -v lists every source Chrony is disciplining from and marks the currently selected best source with ^*:

chronyc sources -v

The Amazon Time Sync Service (169.254.169.123) is selected as the current best source (^*), with the public NTP pool servers as reachable candidates (^-).

Prove that the server is actually serving time. chronyc serverstats counts the NTP requests it has answered. chronyc clients lists the clients that have queried it. ss shows it listening on UDP 123 across all interfaces.

The bundled self-check sends a real NTP client request to the server on port 123 and validates the reply:

sudo chronyc serverstats
sudo chronyc clients ss -lun 'sport = :123' python3 /usr/local/sbin/ntp-selfcheck.py 127.0.0.1

NTP packets received is non-zero, the client list shows the queries served, the server is listening on 0.0.0.0:123 and [::]:123, and the self-check prints a valid NTP timestamp. The server is answering clients.

Point your servers, workstations and network devices at this instance as their NTP server, using its private IP. Open UDP 123 to your client subnets in the instance security group. On a Linux client running chrony, add a line to /etc/chrony/chrony.conf:

server <this-server-private-ip> iburst

On a Linux client running systemd-timesyncd, set NTP=<this-server-private-ip> in /etc/systemd/timesyncd.conf. Windows and network devices take the same server address in their NTP client settings.

Keep the security group rules as tight as your use case allows. Open UDP 123 to specific client subnets, not to 0.0.0.0/0.

By default the server answers NTP only for loopback and the private RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). If your clients sit outside those ranges, add an allow line for your exact client CIDR to /etc/chrony/chrony.conf (for example with sudo nano /etc/chrony/chrony.conf), so the allow section reads:

allow 127.0.0.1 allow ::1 allow 10.0.0.0/8 allow 172.16.0.0/12 allow 192.168.0.0/16 allow 198.51.100.0/24
# <-- your client CIDR

Then apply the change:

sudo systemctl restart chrony

Never use allow all, because it turns the server into an open NTP amplifier. Widen the allow list to specific client networks only, and pair it with a matching UDP 123 security group rule scoped to those same networks.

The shipped configuration is scoped to private networks, and the command interface is bound to loopback only. You can review the whole posture at a glance:

chronyd --version grep -E '^(server 169|allow|cmdport|bindcmdaddress)' /etc/chrony/chrony.conf

The allow list covers loopback and the RFC1918 ranges with no allow all, and cmdport/bindcmdaddress keep the chronyc command port on loopback only. A query from a public source address matches no allow rule and is dropped, so the server cannot be abused for reflection or amplification even if UDP 123 is exposed by the security group.

sudo systemctl status chrony --no-pager

After a configuration change, run sudo systemctl restart chrony. The service is enabled at boot, so the server starts serving time automatically on every reboot. The single source of truth for the configuration is /etc/chrony/chrony.conf.