cat /etc/chrony.conf

# Use public ##servers from the ##pool.ntp.org project.
# Please consider joining the ##pool (http://www.pool.ntp.org/join.html).
###pool 2.centos.pool.ntp.org iburst
# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift
# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3
# Enable kernel synchronization of the real-time clock (RTC).
rtcsync
# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *
# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2
# Allow NTP client access from local network.
#allow 192.168.0.0/16
# Serve time even if not synchronized to a time source.
#local stratum 10
# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys
# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC
# Specify directory for log files.
logdir /var/log/chrony
# Select which information is logged.
#log measurements statistics tracking
server time1.tencentyun.com iburst
server time2.tencentyun.com iburst
server time3.tencentyun.com iburst
server time4.tencentyun.com iburst
server time5.tencentyun.com iburst
systemctl enable chronyc

systemctl status chronyc
timedatectl
chronyc
chronyc sources

chronyc sources -v

timedatectl set-timezone Asia/Shanghai
NTS 是一种新的 NTP 验证机制。它使客户端能够验证它们从服务器接收的数据包在传输过程中有没有被修改。当 NTS 启用时，攻击者唯一能做的就是丢弃或延迟数据包。
如果你从之前的 Fedora 版本升级，或者你没有在安装程序中启用 NTS，你可以直接在 /etc/chrony.conf 中启用 NTS。除了推荐的 iburst 选项外，还可以对指定服务器使用 nts 选项。例如：
server time.cloudflare.com iburst nts
server nts.sth1.ntp.se iburst nts
server nts.sth2.ntp.se iburst nts
你还应该允许客户端将 NTS 密钥和 cookie 保存到磁盘上，这样它就不必在每次启动时重复 NTS-KE 会话。在 chrony.conf 中添加以下一行，如果还没有的话：
ntsdumpdir /var/lib/chrony
如果不想让 DHCP 提供的 NTP 服务器与你指定的服务器混在一起，请在 chrony.conf 中删除或注释以下一行：
sourcedir /run/chrony-dhcp
当你完成编辑 chrony.conf 后，保存你的更改并重新启动 chronyd 服务：
systemctl restart chronyd
在 root 用户下运行以下命令，检查 NTS 密钥建立是否成功：
# chronyc -N authdata
Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
time.cloudflare.com          NTS     1   15  256  33m    0    0    8  100
nts.sth1.ntp.se              NTS     1   15  256  33m    0    0    8  100
nts.sth2.ntp.se              NTS     1   15  256  33m    0    0    8  100
KeyID、Type 和 KLen 列应该有非零值。如果它们为零，请检查系统日志中是否有来自 chronyd 的错误信息。一个可能的故障原因是防火墙阻止了客户端与服务器的 TCP 端口（端口 4460）的连接。
另一个可能的故障原因是由于客户机的时钟错误而导致证书无法验证。这是 NTS 的先有鸡还是先有蛋的问题。你可能需要手动修正日期或暂时禁用 NTS，以使 NTS 正常工作。如果你的电脑有实时时钟，几乎所有的电脑都有，而且有好的电池做备份，这种操作应该只需要一次。
如果计算机没有实时时钟或电池，就像一些常见的小型 ARM 计算机（如树莓派）那样，你可以在 /etc/sysconfig/chronyd 中添加 -s 选项来恢复上次关机或重启时保存的时间。时钟会落后于真实时间，但如果电脑没有关机太久，服务器的证书也没有在离到期时间太近的时候更新，应该足以让时间检查成功。作为最后的手段，你可以用 nocerttimecheck 指令禁用时间检查。详情请参见chrony.conf(5) 手册页。
运行下面的命令来确认客户端是否在进行 NTP 测量：
# chronyc -N sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.cloudflare.com           3   6   377    45   +355us[ +375us] +/-   11ms
^+ nts.sth1.ntp.se               1   6   377    44   +237us[ +237us] +/-   23ms
^+ nts.sth2.ntp.se               1   6   377    44   -170us[ -170us] +/-   22ms
Reach 列应该有一个非零值，最好是 377。上图所示的值 377 是一个八进制数，它表示最后八个请求都有有效的响应。如果启用了 NTS 的话，验证检查将包括 NTS 认证。如果该值一直很少或从未达到 377，则表明 NTP 请求或响应在网络中丢失了。众所周知，一些主要的网络运营商有中间设备，它可以阻止或限制大的 NTP 数据包的速率，以缓解利用 ntpd 的监控协议进行的放大攻击。不幸的是，这影响了受 NTS 保护的 NTP 数据包，尽管它们不会引起任何放大。NTP 工作组正在考虑为 NTP 提供一个替代端口，作为解决这个问题的办法。
在服务器上启用 NTS
如果你有自己的 NTP 服务器，运行着 chronyd，你可以启用服务器的 NTS 支持，让它的客户端安全同步。如果该服务器是其他服务器的客户端，它应该使用 NTS 或对称密钥与之同步。客户端假设同步链在所有服务器到主时间服务器之间是安全的。
启用服务器 NTS 类似于在 Web 服务器上启用 HTTPS。你只需要一个私钥和证书。例如，证书可以由 Let's Encrypt 权威机构使用 certbot 工具签署。当你有了密钥和证书文件（包括中间证书），在 chrony.conf 中用以下指令指定它们：
ntsserverkey /etc/pki/tls/private/foo.example.net.key
ntsservercert /etc/pki/tls/certs/foo.example.net.crt
确保之前在客户端配置中提到的 ntsdumpdir 指令存在于 chrony.conf 中。它允许服务器将其密钥保存到磁盘上，这样服务器的客户端在重启服务器时就不必获取新的密钥和 cookie 了。
重新启动 chronyd 服务：
systemctl restart chronyd
如果系统日志中没有来自 chronyd 的错误信息，那么它应该是可以接受客户端连接的，如果服务器有防火墙，则需要同时允许 UDP 123 和 TCP 4460 端口的 NTP 和 NTS-KE 服务。
你可以用下面的命令在客户端机器上进行快速测试：
$ chronyd -Q -t 3 'server foo.example.net iburst nts maxsamples 1'
2020-10-13T12:00:52Z chronyd version 4.0 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
2020-10-13T12:00:52Z Disabled control of system clock
2020-10-13T12:00:55Z System clock wrong by -0.001032 seconds (ignored)
2020-10-13T12:00:55Z chronyd exiting
如果你看到一个“System clock wrong”消息，说明它是正确工作的。
在服务器上，你可以使用下面的命令来检查它已经处理了多少个 NTS-KE 连接和认证的 NTP 数据包：
# chronyc serverstats
NTP packets received       : 2143106240
NTP packets dropped        : 117180834
Command packets received   : 16819527
Command packets dropped    : 0
Client log records dropped : 574257223
NTS-KE connections accepted: 104
NTS-KE connections dropped : 0
Authenticated NTP packets  : 52139
如果你看到非零的 “NTS-KE connections accepted” 和 “Authenticated NTP packets”，这意味着至少有一些客户端能够连接到 NTS-KE 端口，并发送一个认证的 NTP 请求。