Chrony 4.5 on AWS User Guide

Overview

This guide covers launching and verifying Chrony 4.5 on Ubuntu 24.04 from cloudimg on Amazon EC2. It is one version of the cloudimg Hardened Pi-hole, AdGuard Home & DNS Server AMIs listing on AWS Marketplace; you pick it as the software version when you subscribe and launch. The other DNS and time servers in the listing are described on the listing's guide hub.

Chrony is a versatile implementation of the Network Time Protocol (NTP). It keeps the instance's own clock disciplined against the Amazon Time Sync Service and serves that time to the other machines in your network. It also speaks Network Time Security (NTS, RFC 8915), which authenticates time so a client can detect tampering.

The image ships Chrony 4.5 from Ubuntu 24.04's own chrony package (4.5-1ubuntu4.2), maintained by Canonical, so Ubuntu's security updates reach it through unattended upgrades.

What is on the image:

• Chrony 4.5 (chrony.service), the instance's time daemon, running as the unprivileged _chrony user
• Time from the Amazon Time Sync Service (169.254.169.123, reachable from every subnet, even without internet access; fd00:ec2::123 on IPv6 subnets) with the time.aws.com pool as fallback
• An NTP server on UDP 123 that answers private networks only
• An NTS key exchange server on TCP 4460 with a per-instance certificate, generated on first boot
• No chronyc command port: chronyc works for root over a local Unix socket only
• A self-test, /usr/local/sbin/chrony-selftest.sh, and two small probes, /usr/local/sbin/ntp-query.py and /usr/local/sbin/nts-ke-selfcheck.py

Default user: ubuntu · Architecture: x86_64 · Root volume: 8 GiB gp3

Security posture

• Not an open NTP server. The allow lines in /etc/chrony/chrony.conf admit loopback, the RFC 1918 private ranges, the carrier-grade NAT range 100.64.0.0/10 and IPv6 unique-local addresses (fc00::/7). Requests from any other address are dropped without a reply, and the NTS key exchange on TCP 4460 obeys the same list. Open NTP servers are abused for traffic amplification; this one is not open (Step 8 proves it).
• No control or "monlist" service. The chronyc UDP command port is disabled (cmdport 0, no cmdallow), so nothing on the network can query or control chronyd, and Chrony has no ntpd-style mode 6 or mode 7 service to amplify. Responses are rate-limited per client address.
• The listing security group opens SSH only. NTP (UDP 123) and NTS (TCP 4460) stay closed until you open them to your own VPC or VPN ranges. Clients use the instance's private IP.
• Per-instance NTS certificate. The NTS private key and certificate are generated on each instance's first boot. No key ships in the image, so no two instances share one. The keys NTS uses to protect its cookies are held in memory only and never written to disk.
• No credential to steal. NTP has no login, and /etc/chrony/chrony.keys holds no key.
• No metadata access for the time daemon. chrony.service and its first-boot unit are blocked from the instance metadata service (169.254.169.254 and fd00:ec2::254). The Amazon Time Sync Service at 169.254.169.123 is not blocked.
• IMDSv2 required. The AMI is registered with ImdsSupport v2.0, so instances launched from it refuse token-less (IMDSv1) metadata requests.
• SSH hardened. Key-only login, no root login and no X11 forwarding.
• Per-instance identity. SSH host keys and the machine ID are generated fresh on every instance.

Prerequisites

1. An AWS account and permission to launch EC2 instances
2. An EC2 key pair in the Region you launch in
3. A VPC subnet for the time server, and the CIDR ranges of the clients that will use it

Recommended instance type: m5.large. A time server for a few hundred clients runs comfortably on t3.small or larger.

Connecting to your instance

Version	Operating system	SSH user
Chrony 4.5 on Ubuntu 24.04	Ubuntu 24.04 LTS	ubuntu

Step 1: Launch the instance

Option A: AWS Marketplace console

1. Open the cloudimg Hardened Pi-hole, AdGuard Home & DNS Server AMIs listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
2. Once the subscription is active, choose Launch your software.
3. Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for the full launch wizard). In Version, choose Chrony 4.5 on Ubuntu 24.04, then choose your Region.
4. Pick an instance type (m5.large recommended; the software charge is $0.04 per vCPU per hour) and your key pair.
5. Security group: the listing's default group allows SSH (22) only. Restrict it to your own IP address. You will open NTP to your clients in Step 4.
6. Choose your VPC and subnet, leave the metadata defaults (the image already requires IMDSv2), then choose Launch.

Option B: AWS CLI

Run this on your own workstation. It creates a security group that allows SSH from your management address and NTP plus NTS from your VPC, then launches the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page, and the VPC, subnet, key pair and CIDR ranges with your own:

SG=$(aws ec2 create-security-group --group-name chrony-time \
  --description "Chrony NTP and NTS server" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol udp --port 123 --cidr 10.0.0.0/16
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 4460 --cidr 10.0.0.0/16
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=chrony-time}]'

You do not need --metadata-options: the AMI already makes IMDSv2 required.

Step 2: Connect and read the instance details

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a few seconds of launch. It creates the instance's NTS key and certificate, enables the NTS key exchange server and writes /root/chrony-info.txt with the private IP, the certificate fingerprint, the allowed client ranges and a client example. The note holds no secret: the private key stays in /etc/chrony/nts/server.key, readable only by root and the _chrony group.

sudo cat /root/chrony-info.txt

# Chrony 4.5 on Ubuntu 24.04 LTS (cloudimg AWS Marketplace image) - THIS instance.
# NTP has no login. The NTS private key was generated on this instance's first boot and
# exists nowhere else.

chrony.role=ntp_nts_server
chrony.private_ip=172.31.88.43
chrony.ntp=172.31.88.43:123/udp
chrony.nts_ke=172.31.88.43:4460/tcp
chrony.nts_cert=/etc/chrony/nts/server.crt
chrony.nts_cert_sha256=90:88:BB:5D:C0:C7:F5:C6:D2:48:3E:10:06:88:E2:15:05:27:34:BF:62:DA:D1:65:8D:61:65:AF:90:B6:14:14
chrony.nts_key=/etc/chrony/nts/server.key (root:_chrony 0640 - never copy it off this instance)
chrony.preferred_source=169.254.169.123 (Amazon Time Sync Service)
chrony.allowed_clients=127.0.0.0/8 ::1 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 100.64.0.0/10 fc00::/7
chrony.config=/etc/chrony/chrony.conf
#
# NETWORK ACCESS: the listing security group opens SSH only. To serve clients, add inbound rules for
# udp/123 (NTP) and tcp/4460 (NTS key exchange) ONLY from your own VPC / VPN / on-premises CIDRs - never
# 0.0.0.0/0 - and point clients at the PRIVATE IP above. chrony also answers only the allowed_clients
# ranges ('allow' lines in /etc/chrony/chrony.conf); add an 'allow <cidr>' line for any other range, then:
#   sudo systemctl restart chrony
#
# NTS client (chrony on another machine): copy /etc/chrony/nts/server.crt to the client, then
#   ntstrustedcerts /etc/chrony/cloudimg-nts.crt
#   server 172.31.88.43 iburst nts
#
# Checks on this server (root):
#   sudo chronyc -n sources -v    # 169.254.169.123 should be the selected (*) source
#   sudo chronyc serverstats      # NTP + NTS-KE requests served
#   sudo /usr/local/sbin/chrony-selftest.sh
# User guide: https://www.cloudimg.co.uk/guides/chrony-4-5-on-ubuntu-24-04-aws/

Step 3: Confirm the server is running

chrony.service and its first-boot unit are active. The self-test checks that the Amazon Time Sync Service is the selected source, the allow list and the disabled command port, a local NTP query, a real NTS key exchange with this instance's certificate, the not-an-open-server probe from Step 8, the exact set of listening ports and the metadata block from Step 10.

systemctl is-active chrony.service chrony-firstboot.service
chronyd --version
dpkg-query -W -f='${Package} ${Version}\n' chrony
sudo /usr/local/sbin/chrony-selftest.sh

active
active
chronyd (chrony) version 4.5 (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
chrony 4.5-1ubuntu4.2
[chrony-selftest] selected source: 169.254.169.123 (Amazon Time Sync Service); Stratum : 4;System time : 0.000014427 seconds fast of NTP time;
[chrony-selftest] NTP OK: mode=4 stratum=4 offset=-0.000s from 127.0.0.1:123 (source default)
[chrony-selftest] OK NTS-KE 127.0.0.1:4460 TLS1.3 ntske/1 NTPv4 AEAD15 cookies=8 cert-sha256=9088bb5dc0c7f5c6d2483e100688e215052734bf62dad1658d6165af90b61414
[chrony-selftest] not an open server: 192.0.2.123 gets no NTP reply and no NTS-KE session; 127.0.0.1 and 172.31.88.43 answered; no mode 6/7 replies
[chrony-selftest]   NO REPLY mode=3 from 172.31.88.43:123 (source 192.0.2.123); NTS-KE from 192.0.2.123: connection closed by the server (no session)
[chrony-selftest] listening set OK (tcp: 22 4460 ; udp: 68 123 ); no chronyc command port
[chrony-selftest] chrony.service IPAddressDeny: ::ffff:169.254.169.254/128 fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32
CHRONY_SELFTEST_OK

Step 4: Open NTP and NTS to your clients

The listing's security group allows SSH only. To serve time, add inbound rules to the instance's security group from your own VPC or VPN CIDR ranges only, never from 0.0.0.0/0:

Protocol	Port	Source	Purpose
UDP	123	your VPC / VPN CIDRs	NTP
TCP	4460	your VPC / VPN CIDRs	NTS key exchange (only for NTS clients)

In the EC2 console choose the instance, open Security, choose the security group, then Edit inbound rules. Point clients at the instance's private IP (chrony.private_ip in Step 2). These are the only ports the instance listens on:

sudo ss -Hltnu | awk '{print $1, $5}' | sort -u

tcp 0.0.0.0:22
tcp 0.0.0.0:4460
tcp 127.0.0.53%lo:53
tcp 127.0.0.54:53
tcp [::]:22
tcp [::]:4460
udp 0.0.0.0:123
udp 127.0.0.53%lo:53
udp 127.0.0.54:53
udp 172.31.88.43%ens5:68
udp [::]:123

Chrony serves NTP on UDP 123 and NTS key exchange on TCP 4460. Port 68 is the DHCP client, and 127.0.0.53 and 127.0.0.54 belong to the instance's own local resolver (systemd-resolved). There is no chronyc command port (UDP 323).

Step 5: Check synchronisation

chronyc sources lists the server's time sources. The Amazon Time Sync Service (169.254.169.123) is the preferred source and is marked * (selected); the time.aws.com pool adds two more when the subnet has internet access. Both serve the same leap-smeared time, so they agree with each other.

sudo chronyc -n sources -v
sudo chronyc tracking

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* 169.254.169.123               3   4   377     6    -10us[  -60us] +/-  423us
^? fd00:ec2::123                 0   4     0     -     +0ns[   +0ns] +/-    0ns
^- 54.81.127.33                  4   6    37     5    -32us[  -32us] +/-  758us
^- 44.201.148.133                4   6    37     6    -87us[ -136us] +/-  664us
Reference ID    : A9FEA97B (169.254.169.123)
Stratum         : 4
Ref time (UTC)  : Wed Oct 21 02:01:18 2026
System time     : 0.000035282 seconds slow of NTP time
Last offset     : -0.000049537 seconds
RMS offset      : 0.000049537 seconds
Frequency       : 1.505 ppm slow
Residual freq   : -0.019 ppm
Skew            : 3.314 ppm
Root delay      : 0.000441129 seconds
Root dispersion : 0.000251860 seconds
Update interval : 32.8 seconds
Leap status     : Normal

fd00:ec2::123 is the Amazon Time Sync Service's IPv6 address. It shows ? (unusable) on an IPv4-only subnet and becomes a second Amazon source on Nitro instances in an IPv6-enabled subnet; you do not need to remove it. In a private subnet without internet access the time.aws.com entries disappear, which is fine: 169.254.169.123 is enough.

chronyc needs sudo. As a normal user it reports 506 Cannot talk to daemon, because the command port is disabled and the local Unix socket is root-only.

Step 6: Serve time to your clients

A client query from the instance's private address shows what your clients receive. /usr/local/sbin/ntp-query.py is a minimal NTP client shipped with the image:

PRIV=$(ip -4 -o route get 1.1.1.1 | sed -nE 's/.* src ([0-9.]+).*/\1/p')
python3 /usr/local/sbin/ntp-query.py "$PRIV" 123

NTP OK: mode=4 stratum=4 offset=-0.000s from 172.31.88.43:123 (source default)

On your client machines, point the time service at the server's private IP. These are configuration snippets for the clients, not commands to run on the server:

# chrony (Ubuntu, Amazon Linux, RHEL family): /etc/chrony/chrony.conf or /etc/chrony.conf
server 172.31.88.43 iburst

# systemd-timesyncd: /etc/systemd/timesyncd.conf
[Time]
NTP=172.31.88.43

# Windows (elevated prompt)
w32tm /config /manualpeerlist:172.31.88.43 /syncfromflags:manual /update

Restart the client's time service after the change (sudo systemctl restart chrony or sudo systemctl restart systemd-timesyncd; on Windows w32tm /resync). Every EC2 instance can also use the Amazon Time Sync Service directly, so this server is most useful as the time source for on-premises machines reached over VPN or Direct Connect, for containers and appliances that need one internal NTP address, and for clients that want authenticated time with NTS.

Step 7: Authenticated time with NTS

With NTS, the client first runs a TLS 1.3 key exchange on TCP 4460, checking the server's certificate, and then every NTP packet is authenticated. The certificate is generated on this instance's first boot. Clients trust it by its file, so copy /etc/chrony/nts/server.crt (it is public; the private key never leaves the server) to each NTS client.

The certificate carries the instance's private IP, so NTS clients connect to the private IP:

sudo openssl x509 -in /etc/chrony/nts/server.crt -noout -subject -ext subjectAltName -fingerprint -sha256
PRIV=$(ip -4 -o route get 1.1.1.1 | sed -nE 's/.* src ([0-9.]+).*/\1/p')
sudo python3 /usr/local/sbin/nts-ke-selfcheck.py "$PRIV" 4460 /etc/chrony/nts/server.crt

subject=CN = 172.31.88.43, O = cloudimg Chrony NTS server (per-instance)
X509v3 Subject Alternative Name: 
    IP Address:172.31.88.43, IP Address:127.0.0.1, DNS:localhost, DNS:ip-172-31-88-43, DNS:ip-172-31-88-43.ec2.internal
sha256 Fingerprint=90:88:BB:5D:C0:C7:F5:C6:D2:48:3E:10:06:88:E2:15:05:27:34:BF:62:DA:D1:65:8D:61:65:AF:90:B6:14:14
OK NTS-KE 172.31.88.43:4460 TLS1.3 ntske/1 NTPv4 AEAD15 cookies=8 cert-sha256=9088bb5dc0c7f5c6d2483e100688e215052734bf62dad1658d6165af90b61414

Compare the fingerprint with chrony.nts_cert_sha256 in Step 2 before you trust the file you copied. On a Chrony client, copy the certificate to /etc/chrony/cloudimg-nts.crt and add these lines to its configuration (the info note in Step 2 has them with your IP filled in):

ntstrustedcerts /etc/chrony/cloudimg-nts.crt
server 172.31.88.43 iburst nts

You can watch a complete NTS exchange from the server itself. This runs a second, throwaway chronyd in measure-only mode (-Q: it prints the clock offset and never changes the clock) with this server as its only nts source. A Chrony nts source accepts only authenticated replies, so a printed offset means the key exchange and the authenticated NTP exchange both worked:

PRIV=$(ip -4 -o route get 1.1.1.1 | sed -nE 's/.* src ([0-9.]+).*/\1/p')
sudo install -m 0644 /etc/chrony/nts/server.crt /run/chrony/nts-test.crt
sudo timeout 40 chronyd -Q -t 30 -f /dev/null "server $PRIV iburst nts maxsamples 4" \
  "ntstrustedcerts /run/chrony/nts-test.crt" "pidfile /run/chrony/nts-test.pid" \
  "cmdport 0" "bindcmdaddress /run/chrony/nts-test.sock"
sudo rm -f /run/chrony/nts-test.*
sudo chronyc serverstats | grep 'NTS-KE connections'

2026-10-21T02:01:24Z chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
2026-10-21T02:01:24Z Disabled control of system clock
2026-10-21T02:01:30Z System clock wrong by 0.000020 seconds (ignored)
2026-10-21T02:01:30Z chronyd exiting
NTS-KE connections accepted: 6
NTS-KE connections dropped : 0

The test files sit in /run/chrony because the chronyd AppArmor profile only lets chronyd use that directory. NTS needs the client to reach both ports, so open TCP 4460 as well as UDP 123 for NTS clients (Step 4). If the instance's private IP ever changes (it does not for the life of an instance), regenerate the certificate by removing /var/lib/cloudimg/chrony-firstboot.done and running sudo systemctl restart chrony-firstboot.service, then copy the new certificate to your clients.

Step 8: Confirm it is not an open NTP server

The access rules are in /etc/chrony/chrony.conf, and the NTS server lines that first boot wrote are in /etc/chrony/conf.d/cloudimg-nts.conf:

grep -nE '^(server|pool|confdir|allow|ratelimit|ntsratelimit|cmdport|local)' /etc/chrony/chrony.conf
grep -v '^#' /etc/chrony/conf.d/cloudimg-nts.conf

12:server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4
13:server fd00:ec2::123 prefer iburst minpoll 4 maxpoll 4
14:pool time.aws.com iburst maxsources 2
17:confdir /etc/chrony/conf.d
29:allow 127.0.0.0/8
30:allow ::1
31:allow 10.0.0.0/8
32:allow 172.16.0.0/12
33:allow 192.168.0.0/16
34:allow 100.64.0.0/10
35:allow fc00::/7
38:ratelimit interval 1 burst 16
39:ntsratelimit interval 6 burst 8
46:cmdport 0
58:local stratum 10
ntsserverkey /etc/chrony/nts/server.key
ntsservercert /etc/chrony/nts/server.crt
ntsport 4460

chronyc accheck asks chronyd whether it would answer an address:

sudo chronyc accheck 203.0.113.5
sudo chronyc accheck 10.20.30.40
sudo chronyc accheck 100.64.1.1

209 Access denied
208 Access allowed
208 Access allowed

You can prove the policy from the instance itself. This adds a temporary public test address (192.0.2.53, from the TEST-NET-1 documentation range) to the loopback interface, sends an NTP request and an NTS key exchange from it to the private IP, sends the same from the private IP, and removes the address again. The public source gets no NTP reply and its NTS connection is closed; the private source is answered:

PRIV=$(ip -4 -o route get 1.1.1.1 | sed -nE 's/.* src ([0-9.]+).*/\1/p')
sudo ip addr add 192.0.2.53/32 dev lo
python3 /usr/local/sbin/ntp-query.py "$PRIV" 123 --src 192.0.2.53 --timeout 3 --expect-none
sudo python3 /usr/local/sbin/nts-ke-selfcheck.py "$PRIV" 4460 /etc/chrony/nts/server.crt --src 192.0.2.53 || true
python3 /usr/local/sbin/ntp-query.py "$PRIV" 123 --src "$PRIV"
sudo python3 /usr/local/sbin/nts-ke-selfcheck.py "$PRIV" 4460 /etc/chrony/nts/server.crt --src "$PRIV"
sudo ip addr del 192.0.2.53/32 dev lo

NO REPLY mode=3 from 172.31.88.43:123 (source 192.0.2.53)
FAIL NTS-KE TLS session with 172.31.88.43:4460 failed: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1000)
NTP OK: mode=4 stratum=4 offset=-0.000s from 172.31.88.43:123 (source 172.31.88.43)
OK NTS-KE 172.31.88.43:4460 TLS1.3 ntske/1 NTPv4 AEAD15 cookies=8 cert-sha256=9088bb5dc0c7f5c6d2483e100688e215052734bf62dad1658d6165af90b61414

The legacy control and "monlist" queries that made old NTP servers into amplifiers get no reply at all, even from loopback, and nothing listens on the chronyc command port:

python3 /usr/local/sbin/ntp-query.py 127.0.0.1 123 --mode 6 --timeout 3 --expect-none
python3 /usr/local/sbin/ntp-query.py 127.0.0.1 123 --mode 7 --timeout 3 --expect-none
sudo ss -Hlun 'sport = :323' | wc -l

NO REPLY mode=6 from 127.0.0.1:123 (source default)
NO REPLY mode=7 from 127.0.0.1:123 (source default)
0

Step 9: Allow another of your own networks (optional)

NTP is answered for the local host and the private ranges above. To serve another network you trust, for example a VPN range that uses public addresses, add an allow line next to the others in /etc/chrony/chrony.conf and restart Chrony:

sudo sed -i 's|^allow fc00::/7$|allow fc00::/7\nallow 203.0.113.0/24|' /etc/chrony/chrony.conf
sudo systemctl restart chrony
sudo chronyc accheck 203.0.113.5

208 Access allowed

Replace 203.0.113.0/24 with your own range. Never use allow all, allow 0.0.0.0/0 or allow ::/0: the self-test fails on any of them. Remember to allow the same range in the security group (Step 4).

Step 10: Metadata access is blocked for the time daemon

chrony.service and the first-boot unit carry a systemd IPAddressDeny rule for the instance metadata addresses, so nothing running inside them can reach the metadata service. Each entry is a single address, so the Amazon Time Sync Service at 169.254.169.123 keeps working, as the source list shows:

systemctl show -p IPAddressDeny chrony.service chrony-firstboot.service
sudo chronyc -n sources | grep 169.254.169.123

IPAddressDeny=::ffff:169.254.169.254/128 fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32

IPAddressDeny=::ffff:169.254.169.254/128 fd00:ec2::254/128 168.63.129.16/32 169.254.169.254/32
^* 169.254.169.123               3   4    17    14  -1831ns[-8948ns] +/-  582us

First boot needs no metadata: it reads the private IP from the instance's own routing table.

Step 11: Security recommendations

• Keep the security group tight. Open UDP 123 and TCP 4460 only to the networks that need the server, and SSH only to your management address.
• Keep the allow list scoped. Only add networks you trust (Step 9), never everything. The allow list is a layer of defence behind the security group.
• Prefer NTS for clients that support it. It stops an attacker on the path from shifting your clients' clocks, which can break TLS certificate checks, Kerberos and log correlation.
• Watch the server. sudo chronyc serverstats counts the NTP requests and NTS key exchanges served and dropped; sudo journalctl -u chrony shows the daemon's log.
• Keep Ubuntu patched. Unattended upgrades apply Ubuntu's security updates, including those for the chrony package.

Troubleshooting

• A client gets no answer. Check that the security group allows UDP 123 (not TCP) from the client, that the client uses the server's private IP, and that sudo chronyc accheck <client-ip> reports 208 Access allowed. On the server, python3 /usr/local/sbin/ntp-query.py 127.0.0.1 123 proves Chrony is serving.
• No source is marked *. That is normal for a few seconds after start. If it persists, check sudo chronyc -n sources for the 169.254.169.123 source and sudo journalctl -u chrony -n 50 for errors.
• An NTS client cannot connect. Open TCP 4460 as well as UDP 123, make sure the client connects to the private IP (the name in the certificate) and trusts this instance's /etc/chrony/nts/server.crt. sudo journalctl -u chrony-firstboot shows the first boot that created it.
• chronyc says 506 Cannot talk to daemon. Run it with sudo; the command port is disabled and the local socket is root-only.

Support and licensing

Chrony is developed by the chrony project and is distributed under the GNU General Public License, version 2. The licence text is in /usr/share/doc/chrony/copyright. cloudimg provides the configuration, the not-an-open-server allow list, the per-instance NTS certificate, the metadata block, the self-test and 24/7 support.

cloudimg is not affiliated with or endorsed by the chrony project. Chrony is used here only to identify the software.

For help with deployment or configuration, email support@cloudimg.co.uk or visit cloudimg support.