NTP.CONF(5) | NTPsec | NTP.CONF(5) |
NAME¶
ntp.conf - Network Time Protocol (NTP) daemon configuration file format
SYNOPSIS¶
/etc/ntp.conf
DESCRIPTION¶
The ntp.conf configuration file is read at initial startup by the ntpd(8) daemon in order to specify the synchronization sources, modes, and other related information. Usually, it is installed in the /etc directory, but could be installed elsewhere (see the daemon’s -c command line option).
The file format is similar to other UNIX configuration files. Comments begin with a ‘#’ character and extend to the end of the line; blank lines are ignored. Configuration commands consist of an initial keyword followed by a list of arguments, some of which may be optional, separated by whitespace. Commands may not be continued over multiple lines. Arguments may be host names, host addresses written in numeric, dotted-quad form, integers, floating point numbers (when specifying times in seconds) and text strings.
Configuration files may have inclusion lines. The syntax is includefile followed by whitespace followed by a file or directory name. The configuration is evaluated as though the text of the file - or all files of the directory with the extension ".conf" - were textually spliced in at the point of the include. Relative paths will work, even when the -c option changes the config directory root.
The rest of this page describes the configuration and control options. The "Notes on Configuring NTP and Setting up an NTP Subnet" page (available as part of the HTML documentation provided under /usr/share/doc/ntp) contains an extended discussion of these options. In addition to the discussion of general Configuration Options, there are sections describing the following supported functionality and the options used to control it:
Following these is a section describing Miscellaneous Options. While there is a rich set of options available, the only required option is one or more pool, server, peer, or broadcast commands.
CONFIGURATION SUPPORT¶
Following is a description of the configuration commands in NTPv4. There are two classes of commands, association commands that configure a persistent association with a remote server or peer or reference clock, and auxiliary commands that specify environment variables that control various related operations.
Association Commands¶
Only those options applicable to each command are listed below. Use of options not listed may not be caught as an error, but may result in some weird and even destructive behavior.
In contexts where a host name is expected, a -4 or --ipv4 qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a -6 or --ipv6 qualifier forces DNS resolution to the IPv6 namespace.
In these commands, an address can be any of (a) an IPV4 address in a.b.c.d format, (b) an IPV6 address in [a:b:c:d:e:f:g:h] format, (c) a link-local IPV6 address with an interface specified in [a:b:c:d:e:f:g:h]%device format, or (d) a DNS hostname.
pool address [burst] [iburst] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll] [preempt]
server address [key key] [burst] [iburst] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll]
peer address [key key] [version version] [prefer] [minpoll minpoll] [maxpoll maxpoll]
unpeer [address | associd | clock clocktype [unit unitnum]]
pool
server
peer
unpeer
Association Options¶
bias
burst
iburst
key key
minpoll minpoll, maxpoll maxpoll
mode option
noselect
prefer
true
version version
Association Auxiliary Commands¶
mdnstries number
Authentication Commands¶
The following declarations control MAC authentication:
controlkey key
keys keyfile
trustedkey key...
The MAC authentication procedures require that both the local and remote servers share the same key id, key type, and key text. The easiest way to do this is to copy the whole line. Different keys should be used for each server-client pair. The key_id arguments are integers with values from 1 to 65,535.
NTS Commands¶
The following command controls NTS authentication. It overrides normal TLS protocol negotiation, which is not usually necessary.
nts [enable|disable] [mintls version] [maxtls version] [tlsciphersuites name] [tlsecdhcurves name]
The options are as follows:
cert file
Note that there is no checking on the certificate. In particular, it may have expired or may not cover the host name used to get to this server or may not be signed by a CA that is in the clients root-server collection.
key file
ca location
cookie location
enable
disable
mintls string
maxtls string
tlsciphersuites string
The server picks the cipher. The default is client preference. Specifying ciphersuites also switches to server preference.
tlsecdhcurves string
aead string
The following options of the server command configure NTS (as a client).
nts
The hostname following the server command is used as the address of the NTS key exchange server (NTS-KE) rather than the address of a NTP server. The NTS-KE exchange defaults to using the same IP address for the NTP server.
Note that the server hostname must match the name on the NTS-KE server’s certificate.
noval
ca location
aead string
The same aead algorithms are also used to encrypt cookies. The default is AES_SIV_CMAC_256. There is no config file option to change it, but you can change it by editing the saved cookie key file, probably /var/lib/ntp/nts-keys. Adjust the L: slot to be 48 or 64 and adjust the I: slots to have the right number of bytes. Then restart the server. (All old cookies held by clients will be rejected so their next 8 NTP requests will be ignored. They should recover by retrying NTS-KE to get fresh cookies.)
MONITORING SUPPORT¶
ntpd(8) includes a comprehensive monitoring facility suitable for continuous, long term recording of server and client timekeeping performance. See the statistics command below for a listing and example of each type of statistics currently supported. Statistic files are managed using file generation sets and scripts in the ./scripts directory of this distribution. Using these facilities and UNIX cron(8) jobs, the data can be automatically summarized and archived for retrospective analysis.
Monitoring Commands¶
statistics name...
clockstats
49213 525.624 SPECTRACOM(1) 93 226 00:08:29.606 |
Item | Units | Description |
49213 | MJD | modified Julian day number |
525.624 | s | time of day (s) past midnight UTC |
SPECTRACOM(1) | receiver identifier (Spectracom unit 1) | |
93 226 00:08:29.606 | timecode (format varies by refclock) |
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next normally shows clock type and unit (but if you are running in strict Classic compatibility mode it will show the magic clock address in dotted-quad notation). The final field is the last timecode received from the clock in decoded ASCII format, where meaningful. For some clock drivers, a good deal of additional information can be gathered and displayed as well. See information specific to each clock for further details.
loopstats
50935 75440.031 0.000006019 13.778190 0.000351733 0.0133806 |
Item | Units | Description |
50935 | MJD | date |
75440.031 | s | time past midnight |
0.000006019 | s | clock offset |
13.778 | PPM | drift (frequency offset) |
0.000351733 | s | RMS jitter |
0.013380 | PPM | RMS frequency jitter (aka wander) |
6 | log2 s | clock discipline loop time constant |
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next five fields show time offset (seconds), frequency offset (parts per million - PPM), RMS jitter (seconds), Allan deviation (PPM) and clock discipline time constant.
ntsstats
60209 77147.187 3600 1320 1239 0 2895 2895 11 4104 0 2897 2885 10 0 0 2 0 |
Item | Units | Description |
60209 | MJD | date |
77147.187 | s | time past midnight |
3600 | s | time since reset |
1320 | packets | client requests sent |
1239 | packets | client responses received good |
0 | packets | client responses received bad |
2895 | packets | server responses sent |
2895 | packets | server requests received good |
11 | packets | server requests received bad |
4104 | packets | cookies made |
0 | packets | cookie decodes not server |
2897 | packets | cookie decodes total |
2885 | packets | cookie decodes current |
10 | packets | cookie decodes 1-2 days |
0 | packets | cookie decodes 2-3 days |
0 | packets | cookie decodes 3-10 days |
2 | packets | cookie decodes too old |
0 | packets | cookie decodes error |
These counters are also available via ntpq's nts command.
ntskestats
60209 77147.187 3600 10 2.914 0.026 2 3.218 0.004 0 0.000 0.000 0 0 |
Item | Units | Description |
60209 | MJD | date |
77147.187 | s | time past midnight |
3600 | s | time since reset |
10 | requests | server requests good |
2.914 | seconds | server good wall clock time |
0.026 | seconds | server good CPU time |
2 | requests | server requests no-TLS |
3.218 | seconds | server no-TLS wall clock time |
0.004 | seconds | server no-TLS CPU time |
0 | requests | server requests bad |
0.000 | seconds | server bad wall clock time |
0.000 | seconds | server bad CPU time |
0 | requests | client requests good |
0 | requests | client requests bad |
These counters are also available via ntpq's nts command.
There are two types of failures for NTS-KE server processing. The no-TLS slots are for the path when the TLS connection doesn’t get setup. The bad slots are for the path when the TLS connection does get setup but there is an error during the NTS-KE exchange.
Both are typically caused by bad guys probing for servers to abuse. A no-TLS event would be caused by a bad guy using unencrypted SMTP while a bad event would be caused by SMTP over TLS.
protostats
49213 525.624 128.4.1.1 963a 8a message |
Item | Units | Description |
49213 | MJD | date |
525.624 | s | time past midnight |
128.4.1.1 | IP | source address (0.0.0.0 for system) |
963a | code | status word |
8a | code | event message code |
message | text | event message |
The event message code and message field are described on the "Event Messages and Status Words" page.
peerstats
48773 10847.650 SPECTRACOM(4) 9714 -0.001605376 0.000000000 0.001424877 0.000958674 |
Item | Units | Description |
48773 | MJD | date |
10847.650 | s | time past midnight |
SPECTRACOM(4) | clock name (unit) or source address | |
9714 | hex | status word |
-0.001605376 | s | clock offset |
0.000000000 | s | roundtrip delay |
0.001424877 | s | dispersion |
0.000958674 | s | RMS jitter |
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The third field shows the reference clock type and unit number (but if you are running in the peer address in dotted-quad notation instead) The fourth field is a status word, encoded in hex in the format described in Appendix A of the NTP specification RFC 1305. The final four fields show the offset, delay, dispersion and RMS jitter, all in seconds.
rawstats
59786 36302.768 2610:20:6f15:15::27 2604:a880:1:20::17:5001 3867818701.119346355 3867818701.152009264 3867818701.152010426 3867818702.768490825 0 3 4 1 13 -29 0.000244 0.000488 .NIST. 0 1 2000 |
Item | Units | Description |
59786 | MJD | date |
36302.768 | s | time past midnight |
2610:20:6f15:15::27 | IP | source address |
2604:a880:1:20::17:5001 | IP | destination address |
3867818701.119346355 | NTP s | origin timestamp |
3867818701.152009264 | NTP s | receive timestamp |
3867818701.152010426 | NTP s | transmit timestamp |
3867818702.768490825 | NTP s | destination timestamp |
0 | 0: OK, 1: insert pending, 2: delete pending, 3: not synced | leap warning indicator |
3 | 4 was current in 2012 | NTP version |
4 | 3: client, 4: server, 6: ntpq | mode |
1 | 1-15, 16: not synced | stratum |
13 | log2 seconds | poll |
-29 | log2 seconds | precision |
0.000244 | seconds | total roundtrip delay from the remote server to the primary reference clock |
0.000488 | seconds | total dispersion from the remote server to the primary reference clock |
.NIST. | IP or text | refid, association ID |
0 | integer | lost packets since last response |
1 | integer | dropped packets since last request |
2000 | hex integer | 0 if packet accecpted, BOGON flag if packet is discarded |
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The next two fields show the remote IP Address followed by the local address. The next four fields show the originate, receive, transmit and final NTP timestamps in order. The timestamp values are as received and before processing by the various data smoothing and mitigation algorithms.
A packet that is accecpted is logged. At most the first dropped packet per request is logged. That avoids DDoSing the log file.
The BOGON flags are decoded here.
sysstats
59935 82782.547 3600 36082754 31287166 26510580 4779042 113 19698 1997 428 4773352 0 366120 |
Item | Units | Description |
59935 | MJD | date |
82782.547 | s | time past midnight |
3600 | s | time since reset |
36082754 | # | packets received |
31287166 | # | packets processed |
26510580 | # | current version |
4779042 | # | old version(s) |
113 | # | access denied |
19698 | # | bad length or format |
1997 | # | bad authentication |
428 | # | declined |
4773352 | # | rate exceeded |
0 | # | kiss-o'-death packets sent |
366120 | # | NTPv1 packets received |
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The remaining ten fields show the statistics counter values accumulated since the last generated line.
usestats
57570 83399.541 3600 0.902 1.451 164 0 0 0 2328 64226 1 0 4308 |
Item | Units | Description |
57570 | MJD | date |
83399.541 | s | time past midnight |
3600 | s | time since reset |
0.902 | s | ru_utime: CPU seconds - user mode |
1.451 | s | ru_stime: CPU seconds - system |
164 | # | ru_minflt: page faults - reclaim/soft (no I/O) |
0 | # | ru_majflt: page faults - I/O |
0 | # | ru_nswap: process swapped out |
0 | # | ru_inblock: file blocks in |
2328 | # | ru_oublock: file blocks out |
64226 | # | ru_nvcsw: context switches, wait |
1 | # | ru_nivcsw: context switches, preempts |
0 | # | ru_nsignals: signals |
4308 | # | ru_maxrss: resident set size, kilobytes |
The first two fields show the date (Modified Julian Day) and time (seconds and fraction past UTC midnight). The ru_ tags are the names from the rusage struct. See man getrusage for details. (The NetBSD and FreeBSD man pages have more details.) The maxrss column is the high water mark since the process was started. The remaining fields show the values used since the last report.
statsdir directory_path
filegen name [file filename] [type typename] [link | nolink] [enable | disable]
Note that this command can be sent from the ntpq(1) program running at a remote location.
name
file filename
Attribute | Description |
prefix | This is a constant filename path. It is not subject to modifications via the filegen option. It is defined by the server, usually specified as a compile-time constant. It may, however, be configurable for individual file generation sets via other commands. For example, the prefix used with loopstats and peerstats generation can be configured using the statsdir option explained above. |
filename | This string is directly concatenated to the prefix mentioned above (no intervening ‘/’). This can be modified using the file argument to the filegen statement. No .. elements are allowed in this component to prevent filenames referring to parts outside the filesystem hierarchy denoted by prefix. |
suffix | This part is reflects individual elements of a file set. It is generated according to the type of a file set. |
type typename
Attribute | Description |
none | The file set is actually a single plain file. |
pid | One element of file set is used per incarnation of a ntpd server. This type does not perform any changes to file set members during runtime, however it provides an easy way of separating files belonging to different ntpd(8) server incarnations. The set member filename is built by appending a ‘.’ to concatenated prefix and filename strings, and appending the decimal representation of the process ID of the ntpd(8) server process. |
day | One file generation set element is created per day. A day is defined as the period between 00:00 and 24:00 UTC. The file set member suffix consists of a ‘.’ and a day specification in the form YYYYMMdd. YYYY is a 4-digit year number (e.g., 1992). MM is a two digit month number. dd is a two digit day number. Thus, all information written at 10 December 1992 would end up in a file named prefix filename.19921210. |
week | Any file set member contains data related to a certain week of a year. The term week is defined by computing day-of-year modulo 7. Elements of such a file generation set are distinguished by appending the following suffix to the file set filename base: A dot, a 4-digit year number, the letter W, and a 2-digit week number. For example, information from January, 10th 1992 would end up in a file with suffix 1992W1. |
month | One generation file set element is generated per month. The file name suffix consists of a dot, a 4-digit year number, and a 2-digit month. |
year | One generation file element is generated per year. The filename suffix consists of a dot and a 4 digit year number. |
age | This type of file generation sets changes to a new element of the file set every 24 hours of server operation. The filename suffix consists of a dot, the letter a, and an 8-digit number. This number is taken to be the number of seconds the server is running at the start of the corresponding 24-hour period. |
link | nolink
enable | disable
ACCESS CONTROL SUPPORT¶
The ntpd(8) daemon implements a general purpose address/mask based restriction list. The list contains address/match entries sorted first by increasing address values and then by increasing mask values. A match occurs when the bitwise AND of the mask and the packet source address is equal to the bitwise AND of the mask and address in the list. The list is searched in order with the last match found defining the restriction flags associated with the entry. Additional information and examples can be found in the "Notes on Configuring NTP and Setting up a NTP Subnet" page (available as part of the HTML documentation).
The restriction facility was implemented in conformance with the access policies for the original NSFnet backbone time servers. Later the facility was expanded to deflect cryptographic and clogging attacks. While this facility may be useful for keeping unwanted or broken or malicious clients from congesting innocent servers, it should not be considered an alternative to the NTP authentication facilities. Source address based restrictions are easily circumvented by a determined cracker.
Clients can be denied service because they are explicitly included in the restrict list created by the restrict command or implicitly as the result of cryptographic or rate limit violations. Cryptographic violations include certificate or identity verification failures; rate limit violations generally result from defective NTP implementations that send packets at abusive rates. Some violations cause denied service only for the offending packet, others cause denied service for a timed period and others cause the denied service for an indefinite period. When a client or network is denied access for an indefinite period, the only way at present to remove the restrictions is by restarting the server.
The Kiss-of-Death Packet¶
Ordinarily, packets denied service are simply dropped with no further action except incrementing statistics counters. Sometimes a more proactive response is needed, such as a server message that explicitly requests the client to stop sending and leave a message for the system operator. A special packet format has been created for this purpose called the "kiss-of-death" (KoD) packet. KoD packets have the leap bits set unsynchronized and stratum set to zero and the reference identifier field set to a four-byte ASCII code. If the noserve or notrust flag of the matching restrict list entry is set, the code is "DENY"; if the limited flag is set and the rate limit is exceeded, the code is "RATE". Finally, if a cryptographic violation occurs, the code is "CRYP".
A client receiving a KoD performs a set of sanity checks to minimize security exposure, then updates the stratum and reference identifier peer variables, sets the access denied (BOGON4) bit in the peer flash variable and sends a message to the log. As long as the BOGON4 bit is set, the client will send no further packets to the server. The only way at present to recover from this condition is to restart the protocol at both the client and server. This happens automatically at the client when the association times out. It will happen at the server only if the server operator cooperates.
ACCESS CONTROL COMMANDS¶
limit [average average] [burst burst] [kod kod]
average average
burst burst
kod kod
restrict address[/cidr] [mask mask] [flag ...]
flake
ignore
kod
limited
mssntp
nomodify
nomrulist
nopeer
noquery
noserve
notrust
ntpport
version
Note: A second restrict line with the same address/mask does not replace the first one. The flags are merged. Thus:
restrict bob X restrict bob Y
is the same as
restrict bob X Y
Default restriction list entries with the flags ignore, interface, ntpport, for each of the local host’s interface addresses are inserted into the table at startup to prevent the server from attempting to synchronize to its own time. A default entry is also always present. It has noquery to avoid packet length amplification which can be used for DDoS with a forged return address and limited to avoid DDoS reflections.
unrestrict address[/cidr] [mask mask] [flag ...]
Note: unrestrict default will not do anything; you can’t remove the builtin defaults. If you want to remove them, use unrestrict default noquery limited to turn off those flags.
AUTOMATIC NTP CONFIGURATION OPTIONS¶
Manycasting¶
For a detailed description of manycast operation, see the "Server Discovery" page (available as part of the HTML documentation).
Manycast Options¶
tos [ceiling ceiling | floor floor | minclock minclock | minsane minsane]
ceiling ceiling
floor floor
minclock minclock
minsane minsane
REFERENCE CLOCK SUPPORT¶
For a detailed description of reference-clock configuration, see the "Reference Clock Drivers" page (available as part of the HTML documentation provided in /usr/share/doc/ntp).
REFERENCE CLOCK COMMANDS¶
refclock drivername [unit u] [prefer] [subtype int] [mode int] [minpoll int] [maxpoll int] [time1 sec] [time2 sec] [stratum int] [refid string] [path filename] [ppspath filename] [baud number] [flag1 {0 | 1}] [flag2 {0 | 1}] [flag3 {0 | 1}] [flag4 {0 | 1}]
unit
prefer
subtype int
mode int
minpoll int; maxpoll int
time1 sec
time2 secs
stratum int
refid string
path filepath
ppspath filepath
baud number
flag1 {0 | 1}; flag2 {0 | 1}; flag3 {0 | 1}; flag4 {0 | 1}
MISCELLANEOUS OPTIONS¶
driftfile driftfile
The file format consists of a single line containing a single floating point number, which records the frequency offset measured in parts-per-million (PPM). The file is updated by first writing the current drift value into a temporary file and then renaming this file to replace the old version; this implies that ntpd(8) must have write permission for the directory the drift file is located in, and that file system links, symbolic or otherwise, should be avoided.
enable [auth | calibrate | kernel | monitor | ntp | stats]; disable [auth | calibrate | kernel | monitor | ntp | stats]
auth
calibrate
kernel
monitor
ntp
stats
includefile includefile
interface [listen | ignore | drop] [all | ipv4 | ipv6 | wildcard | name | address[/prefixlen]]
leapfile leapfile
The leapfile is scanned when ntpd processes the leapfile directive or when ntpd detects that leapfile has changed. ntpd checks once a day to see if the leapfile has changed.
leapsmearinterval interval
logconfig configkeyword
Configuration keywords are formed by concatenating the message class with the event class. The all prefix can be used instead of a message class. A message class may also be followed by the all keyword to enable/disable all messages of the respective message class. Thus, a minimal log configuration could look like this:
logconfig =syncstatus +sysevents
This would just list the synchronizations state of ntpd(8) and the major system events. For a simple reference server, the following minimum message configuration could be useful:
logconfig =syncall +clockall
This configuration will list all clock information and synchronization information. All other events and messages about peers, system events and so on is suppressed.
logfile logfile
If your ntpd runs for a long time, you probably want to use logrotate or newsyslog to switch to a new log file occasionally. SIGHUP will reopen the log file.
mru [maxdepth count | maxmem kilobytes | mindepth count | maxage seconds | minage seconds | initalloc count | initmem kilobytes | incalloc count | incmem kilobytes]
maxdepth count, maxmem kilobytes
mindepth count
maxage seconds, minage seconds
initalloc count, initmem kilobytes
incalloc count, incmem kilobytes
nonvolatile threshold
phone dial ...
reset [allpeers] [auth] [ctl] [io] [mem] [sys] [timer]
setvar variable [default]
tinker [allan allan | dispersion dispersion | freq freq | huffpuff huffpuff | panic panic | step step | stepback stepback | stepfwd stepfwd | stepout stepout]
The variables operate as follows:
allan allan
dispersion dispersion
freq freq
huffpuff huffpuff
panic panic
step step
stepback stepback
stepfwd stepfwd
stepout stepout
rlimit [memlock megabytes | stacksize 4kPages | filenum filedescriptors]
memlock megabytes
stacksize 4kPages
filenum filedescriptors
FILES¶
/etc/ntp.conf
ntp.keys
SEE ALSO¶
In addition to the manual pages provided, comprehensive documentation is available on the world wide web at https://www.ntpsec.org. A snapshot of this documentation is available in HTML format in /usr/share/doc/ntp.
BUGS¶
The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected.
04/17/2024 | NTPsec 1.2.3 |