+(4.2.7p338) 2012/12/25 Released by Harlan Stenn <stenn@ntp.org>
* mdoc2texi fixes: Handle_ArCmFlIc, Handle_Fn, HandleQ.
* ntp-keygen autogen documentation updates.
* ntpq autogen docs.
#
# EDIT THIS FILE WITH CAUTION (invoke-ntp.conf.texi)
#
-# It has been AutoGen-ed December 22, 2012 at 11:47:38 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 25, 2012 at 11:32:50 AM by AutoGen 5.16.2
# From the definitions ntp.conf.def
# and the template file agtexi-file.tpl
@end ignore
The rest of this page describes the configuration and control options.
The
-"NotesonConfiguringNTPandSettingupaNTPSubnet"
+"Notes on Configuring NTP and Setting up a NTP Subnet"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp})
-)
contains an extended discussion of these options.
In addition to the discussion of general
@ref{Configuration}Configuration
@item Xo
[@code{burst} ]
[@code{iburst} ]
-[@code{version} @code{Ar} @code{version} ]
+[@code{version} @code{version} ]
[@code{prefer} ]
-[@code{minpoll} @code{Ar} @code{minpoll} ]
-[@code{maxpoll} @code{Ar} @code{maxpoll} ]
+[@code{minpoll} @code{minpoll} ]
+[@code{maxpoll} @code{maxpoll} ]
@item Xo
-[@code{key} @code{Ar} @code{key}\&| @code{Cm} @code{autokey} ]
+[@code{key} @code{key} @code{\&|} @code{Cm} @code{autokey} ]
[@code{burst} ]
[@code{iburst} ]
-[@code{version} @code{Ar} @code{version} ]
+[@code{version} @code{version} ]
[@code{prefer} ]
-[@code{minpoll} @code{Ar} @code{minpoll} ]
-[@code{maxpoll} @code{Ar} @code{maxpoll} ]
+[@code{minpoll} @code{minpoll} ]
+[@code{maxpoll} @code{maxpoll} ]
@item Xo
-[@code{key} @code{Ar} @code{key}\&| @code{Cm} @code{autokey} ]
-[@code{version} @code{Ar} @code{version} ]
+[@code{key} @code{key} @code{\&|} @code{Cm} @code{autokey} ]
+[@code{version} @code{version} ]
[@code{prefer} ]
-[@code{minpoll} @code{Ar} @code{minpoll} ]
-[@code{maxpoll} @code{Ar} @code{maxpoll} ]
+[@code{minpoll} @code{minpoll} ]
+[@code{maxpoll} @code{maxpoll} ]
@item Xo
-[@code{key} @code{Ar} @code{key}\&| @code{Cm} @code{autokey} ]
-[@code{version} @code{Ar} @code{version} ]
+[@code{key} @code{key} @code{\&|} @code{Cm} @code{autokey} ]
+[@code{version} @code{version} ]
[@code{prefer} ]
-[@code{minpoll} @code{Ar} @code{minpoll} ]
-[@code{ttl} @code{Ar} @code{ttl} ]
+[@code{minpoll} @code{minpoll} ]
+[@code{ttl} @code{ttl} ]
@item Xo
-[@code{key} @code{Ar} @code{key}\&| @code{Cm} @code{autokey} ]
-[@code{version} @code{Ar} @code{version} ]
+[@code{key} @code{key} @code{\&|} @code{Cm} @code{autokey} ]
+[@code{version} @code{version} ]
[@code{prefer} ]
-[@code{minpoll} @code{Ar} @code{minpoll} ]
-[@code{maxpoll} @code{Ar} @code{maxpoll} ]
-[@code{ttl} @code{Ar} @code{ttl} ]
+[@code{minpoll} @code{minpoll} ]
+[@code{maxpoll} @code{maxpoll} ]
+[@code{ttl} @code{ttl} ]
@end multitable
These five commands specify the time server name or address to
be used and the mode in which to operate.
The
-@kbd{address} can be
+@code{address} can be
either a DNS name or an IP address in dotted-quad notation.
Additional information on association behavior can be found in the
-"AssociationManagement"
+"Association Management"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp}).
-)
-.
@table @samp
@item Ic
For type s addresses, this command mobilizes a persistent
subnet specified, but multicast messages go to all interfaces.
In broadcast mode the local server sends periodic broadcast
messages to a client population at the
-@kbd{address} specified, which is usually the broadcast address on (one of) the
+@code{address} specified, which is usually the broadcast address on (one of) the
local network(s) or a multicast address assigned to NTP.
The IANA
has assigned the multicast group address IPv4 224.0.1.1 and
The
client broadcasts a request message to the group address associated
with the specified
-@kbd{address} and specifically enabled
+@code{address} and specifically enabled
servers respond to these messages.
The client selects the servers
providing the best time and continues as with the
@item Cm
All packets sent to and received from the server or peer are to
include authentication fields encrypted using the specified
-@kbd{key} identifier with values from 1 to 65534, inclusive.
+@code{key} identifier with values from 1 to 65534, inclusive.
The
default is to include no encryption field.
@item Cm
this host will be chosen for synchronization among a set of
correctly operating hosts.
See the
-"MitigationRulesandthepreferKeyword"
+"Mitigation Rules and the prefer Keyword"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp})
-)
for further information.
@item Cm
This option is used only with broadcast server and manycast
client modes.
It specifies the time-to-live
-@kbd{ttl} to
+@code{ttl} to
use on broadcast server and multicast server and the maximum
-@kbd{ttl} for the expanding ring search with manycast
+@code{ttl} for the expanding ring search with manycast
client packets.
Selection of the proper value, which defaults to
127, is something of a black art and should be coordinated with the
related information are specified in a key
file, usually called
@file{ntp.keys},
-,
which must be distributed and stored using
secure means beyond the scope of the NTP protocol itself.
Besides the keys used
utility, which uses the standard
protocol defined in RFC-1305.
The
-@kbd{key} argument is
+@code{key} argument is
the key identifier for a trusted key, where the value can be in the
range 1 to 65,534, inclusive.
@item Xo
-[@code{cert} @code{Ar} @code{file} ]
-[@code{leap} @code{Ar} @code{file} ]
-[@code{randfile} @code{Ar} @code{file} ]
-[@code{host} @code{Ar} @code{file} ]
-[@code{sign} @code{Ar} @code{file} ]
-[@code{gq} @code{Ar} @code{file} ]
-[@code{gqpar} @code{Ar} @code{file} ]
-[@code{iffpar} @code{Ar} @code{file} ]
-[@code{mvpar} @code{Ar} @code{file} ]
-[@code{pw} @code{Ar} @code{password} ]
+[@code{cert} @code{file} ]
+[@code{leap} @code{file} ]
+[@code{randfile} @code{file} ]
+[@code{host} @code{file} ]
+[@code{sign} @code{file} ]
+[@code{gq} @code{file} ]
+[@code{gqpar} @code{file} ]
+[@code{iffpar} @code{file} ]
+[@code{mvpar} @code{file} ]
+[@code{pw} @code{password} ]
This command requires the OpenSSL library.
It activates public key
cryptography, selects the message digest and signature
in the
@code{keysdir} command or default
@file{/usr/local/etc}.
-.
Following are the subcommands:
@table @samp
@item Cm
Specifies the location of the required host public certificate file.
This overrides the link
@file{ntpkey_cert_}NsArhostname
-Ns
-Ar
-hostname
in the keys directory.
@item Cm
Specifies the location of the optional GQ parameters file.
This
overrides the link
@file{ntpkey_gq_}NsArhostname
-Ns
-Ar
-hostname
in the keys directory.
@item Cm
Specifies the location of the required host key file.
This overrides
the link
@file{ntpkey_key_}NsArhostname
-Ns
-Ar
-hostname
in the keys directory.
@item Cm
Specifies the location of the optional IFF parameters file.This
overrides the link
@file{ntpkey_iff_}NsArhostname
-Ns
-Ar
-hostname
in the keys directory.
@item Cm
Specifies the location of the optional leapsecond file.
This
overrides the link
@file{ntpkey_mv_}NsArhostname
-Ns
-Ar
-hostname
in the keys directory.
@item Cm
Specifies the password to decrypt files containing private keys and
This overrides
the link
@file{ntpkey_sign_}NsArhostname
-Ns
-Ar
-hostname
in the keys directory.
If this file is
not found, the host key is also the sign key.
cryptographic keys, parameters and certificates.
The default is
@file{/usr/local/etc/}.
-.
.It
Ic
requestkey
proprietary protocol specific to this implementation of
@code{ntpd(1ntpdmdoc)}.
The
-@kbd{key} argument is a key identifier
+@code{key} argument is a key identifier
for the trusted key, where the value can be in the range 1 to
65,534, inclusive.
.It
purpose, although different keys can be used with different
servers.
The
-@kbd{key} arguments are 32-bit unsigned
+@code{key} arguments are 32-bit unsigned
integers with values from 1 to 65,534.
@end multitable
and monitoring protocol trap mechanism.
@table @samp
@item 101
-(badfieldformatorlength)
+(bad field format or length)
The packet has invalid version, length or format.
@item 102
-(badtimestamp)
+(bad timestamp)
The packet timestamp is the same or older than the most recent received.
This could be due to a replay or a server clock time step.
@item 103
-(badfilestamp)
+(bad filestamp)
The packet filestamp is the same or older than the most recent received.
This could be due to a replay or a key file generation error.
@item 104
-(badormissingpublickey)
+(bad or missing public key)
The public key is missing, has incorrect format or is an unsupported type.
@item 105
-(unsupporteddigesttype)
+(unsupported digest type)
The server requires an unsupported digest/signature scheme.
@item 106
-(mismatcheddigesttypes)
+(mismatched digest types)
Not used.
@item 107
-(badsignaturelength)
+(bad signature length)
The signature length does not match the current public key.
@item 108
-(signaturenotverified)
+(signature not verified)
The message fails the signature check.
It could be bogus or signed by a
different private key.
@item 109
-(certificatenotverified)
+(certificate not verified)
The certificate is invalid or signed with the wrong key.
@item 110
-(certificatenotverified)
+(certificate not verified)
The certificate is not yet valid or has expired or the signature could not
be verified.
@item 111
-(badormissingcookie)
+(bad or missing cookie)
The cookie is missing, corrupted or bogus.
@item 112
-(badormissingleapsecondstable)
+(bad or missing leapseconds table)
The leapseconds table is missing, corrupted or bogus.
@item 113
-(badormissingcertificate)
+(bad or missing certificate)
The certificate is missing, corrupted or bogus.
@item 114
-(badormissingidentity)
+(bad or missing identity)
The identity key is missing, corrupt or bogus.
@end multitable
@item Ic
Enables writing of statistics records.
Currently, four kinds of
-@kbd{name} statistics are supported.
+@code{name} statistics are supported.
@table @samp
@item Cm
Enables recording of clock driver statistics information.
Ar
name
Xo
-[@code{file} @code{Ar} @code{filename} ]
-[@code{type} @code{Ar} @code{typename} ]
+[@code{file} @code{filename} ]
+[@code{type} @code{typename} ]
[@code{link} | @code{nolink} ]
[@code{enable} | @code{disable} ]
Configures setting of generation file set name.
This is the file name for the statistics records.
Filenames of set
members are built from three concatenated elements
-@kbd{Cm} @kbd{prefix}, @kbd{Cm} @kbd{filename} and
-@kbd{Cm} @kbd{suffix}: @table @samp
+@code{Cm} @code{prefix}, @code{Cm} @code{filename} and
+@code{Cm} @code{suffix}: @table @samp
@item Cm
This is a constant filename path.
It is not subject to
modifications via the
-@kbd{filegen} option.
+@code{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
-@kbd{loopstats} and
-@kbd{peerstats} generation can be configured using the
-@kbd{statsdir} option explained above.
+@code{loopstats} and
+@code{peerstats} generation can be configured using the
+@code{statsdir} option explained above.
@item Cm
This string is directly concatenated to the prefix mentioned
above (no intervening
-@quoteleft{}/).@quoteright{}
+@quoteleft{}/ ) .@quoteright{}
This can be modified using
the file argument to the
-@kbd{filegen} statement.
+@code{filegen} statement.
No
@file{..}
elements are
allowed in this component to prevent filenames referring to
parts outside the filesystem hierarchy denoted by
-@kbd{prefix}. @item Cm
+@code{prefix}. @item Cm
This part is reflects individual elements of a file set.
It is
generated according to the type of a file set.
The set member filename is built by appending a
@quoteleft{}\&.@quoteright{}
to concatenated
-@kbd{prefix} and
-@kbd{filename} strings, and
+@code{prefix} and
+@code{filename} strings, and
appending the decimal representation of the process ID of the
@code{ntpd(1ntpdmdoc)}
server process.
@code{dd} is a two digit day number.
Thus, all information written at 10 December 1992 would end up
in a file named
-@kbd{prefix} @kbd{filename} @kbd{Ns}.19921210. @item Cm
+@code{prefix} @code{filename} @code{Ns} @code{.19921210}. @item Cm
Any file set member contains data related to a certain week of
a year.
The term week is defined by computing day-of-year
last match found defining the restriction flags associated
with the entry.
Additional information and examples can be found in the
-"NotesonConfiguringNTPandSettingupaNTPSubnet"
+"Notes on Configuring NTP and Setting up a NTP Subnet"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp}).
-)
-.
The restriction facility was implemented in conformance
with the access policies for the original NSFnet backbone
Commands
@table @samp
@item Xo
-[@code{average} @code{Ar} @code{avg} ]
-[@code{minimum} @code{Ar} @code{min} ]
-[@code{monitor} @code{Ar} @code{prob} ]
+[@code{average} @code{avg} ]
+[@code{minimum} @code{min} ]
+[@code{monitor} @code{prob} ]
Set the parameters of the
@code{limited} facility which protects the server from
client abuse.
The monitor subcommand specifies the probability of discard
for packets that overflow the rate-control window.
@item Xo
-[@code{mask} @code{Ar} @code{mask} ]
-[@kbd{flag}... ]
+[@code{mask} @code{mask} ]
+[@code{flag} @code{...} ]
The
-@kbd{address} argument expressed in
+@code{address} argument expressed in
dotted-quad form is the address of a host or network.
Alternatively, the
-@kbd{address} argument can be a valid host DNS name.
+@code{address} argument can be a valid host DNS name.
The
-@kbd{mask} argument expressed in dotted-quad form defaults to
-255.255.255.255, meaning that the
-@kbd{address} is treated as the address of an individual host.
+@code{mask} argument expressed in dotted-quad form defaults to
+@code{255.255.255.255}, meaning that the
+@code{address} is treated as the address of an individual host.
A default entry (address
-0.0.0.0, mask
-0.0.0.0) is always included and is always the first entry in the list.
+@code{0.0.0.0}, mask
+@code{0.0.0.0}) is always included and is always the first entry in the list.
Note that text string
@code{default}, with no mask option, may
be used to indicate the default entry.
@table @samp
@item Xo
.Oo
-@code{ceiling} @code{Ar} @code{ceiling} | @code{cohort}{ @code{0} | @code{1}} | @code{floor} @code{Ar} @code{floor} | @code{minclock} @code{Ar} @code{minclock} | @code{minsane} @code{Ar} @code{minsane} .Oc
+@code{ceiling} @code{ceiling} | @code{cohort}{ @code{0} | @code{1}} | @code{floor} @code{floor} | @code{minclock} @code{minclock} | @code{minsane} @code{minsane} .Oc
This command affects the clock selection and clustering
algorithms.
It can be used to select the quality and
used for backup or when no other clock source is available.
Detailed descriptions of individual device drivers and options can
be found in the
-"ReferenceClockDrivers"
+"Reference Clock Drivers"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp}).
-)
-.
Additional information can be found in the pages linked
there, including the
-"DebuggingHintsforReferenceClockDrivers"
+"Debugging Hints for Reference Clock Drivers"
and
-"HowToWriteaReferenceClockDriver"
+"How To Write a Reference Clock Driver"
pages
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp}).
-)
-.
In addition, support for a PPS
signal is available as described in the
-"Pulse-per-second(PPS)SignalInterfacing"
+"Pulse-per-second (PPS) Signal Interfacing"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp}).
-)
-.
Many
drivers support special line discipline/streams modules which can
significantly improve the accuracy using the driver.
These are
described in the
-"LineDisciplinesandStreamsDrivers"
+"Line Disciplines and Streams Drivers"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp}).
-)
-.
A reference clock will generally (though not always) be a radio
timecode receiver which is synchronized to a source of standard
.Sm
on
where
-@kbd{t} is an integer
+@code{t} is an integer
denoting the clock type and
-@kbd{u} indicates the unit
+@code{u} indicates the unit
number in the range 0-3.
While it may seem overkill, it is in fact
sometimes useful to configure multiple reference clocks of the same
The
@code{server} command is used to configure a reference
clock, where the
-@kbd{address} argument in that command
+@code{address} argument in that command
is the clock address.
The
@code{key}, @code{version} and
enthusiasm than other reference clocks or peers.
Further
information on this option can be found in the
-"MitigationRulesandthepreferKeyword"
+"Mitigation Rules and the prefer Keyword"
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp})
-)
page.
The
@code{minpoll} and
immediately after the
@code{server} command.
The
-@kbd{address} argument specifies the clock address.
+@code{address} argument specifies the clock address.
The
@code{refid} and
@code{stratum} options can be used to
.Sm
on
[@code{prefer} ]
-[@code{mode} @code{Ar} @code{int} ]
-[@code{minpoll} @code{Ar} @code{int} ]
-[@code{maxpoll} @code{Ar} @code{int} ]
+[@code{mode} @code{int} ]
+[@code{minpoll} @code{int} ]
+[@code{maxpoll} @code{int} ]
This command can be used to configure reference clocks in
special ways.
The options are interpreted as follows:
equal, this host will be chosen for synchronization among a set of
correctly operating hosts.
See the
-"MitigationRulesandthepreferKeyword"
+"Mitigation Rules and the prefer Keyword"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp})
-)
for further information.
@item Cm
Specifies a mode number which is interpreted in a
u
.Sm
on
-[@code{time1} @code{Ar} @code{sec} ]
-[@code{time2} @code{Ar} @code{sec} ]
-[@code{stratum} @code{Ar} @code{int} ]
-[@code{refid} @code{Ar} @code{string} ]
-[@code{mode} @code{Ar} @code{int} ]
-[@code{flag1} @code{Cm} @code{0}\&| @code{Cm} @code{1} ]
-[@code{flag2} @code{Cm} @code{0}\&| @code{Cm} @code{1} ]
-[@code{flag3} @code{Cm} @code{0}\&| @code{Cm} @code{1} ]
-[@code{flag4} @code{Cm} @code{0}\&| @code{Cm} @code{1} ]
+[@code{time1} @code{sec} ]
+[@code{time2} @code{sec} ]
+[@code{stratum} @code{int} ]
+[@code{refid} @code{string} ]
+[@code{mode} @code{int} ]
+[@code{flag1} @code{Cm} @code{0} @code{\&|} @code{Cm} @code{1} ]
+[@code{flag2} @code{Cm} @code{0} @code{\&|} @code{Cm} @code{1} ]
+[@code{flag3} @code{Cm} @code{0} @code{\&|} @code{Cm} @code{1} ]
+[@code{flag4} @code{Cm} @code{0} @code{\&|} @code{Cm} @code{1} ]
This command can be used to configure reference clocks in
special ways.
It must immediately follow the
@ref{Miscellaneous}Miscellaneous
Options
page and operates as described in the
-"ReferenceClockDrivers"
+"Reference Clock Drivers"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp}).
-)
-.
@item Cm
Specifies a fixed-point decimal number in seconds, which is
interpreted in a driver-dependent way.
See the descriptions of
specific drivers in the
-"ReferenceClockDrivers"
+"Reference Clock Drivers"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp}).
-)
-.
@item Cm
Specifies the stratum number assigned to the driver, an integer
between 0 and 15.
Enables the pulse-per-second (PPS) signal when frequency and time is
disciplined by the precision time kernel modifications.
See the
-"AKernelModelforPrecisionTimekeeping"
+"A Kernel Model for Precision Timekeeping"
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp})
-)
page for further information.
The default for this flag is
@code{disable}. @item Cm
@code{logfile} log file.
By default, all output is turned on.
All
-@kbd{configkeyword} keywords can be prefixed with
-@quoteleft{}=,@quoteright{}
+@code{configkeyword} keywords can be prefixed with
+@quoteleft{}= ,@quoteright{}
@quoteleft{}+@quoteright{}
and
-@quoteleft{}-,@quoteright{}
+@quoteleft{}- ,@quoteright{}
where
@quoteleft{}=@quoteright{}
sets the
Ic
tinker
.Oo
-@code{allan} @code{Ar} @code{allan} | @code{dispersion} @code{Ar} @code{dispersion} | @code{freq} @code{Ar} @code{freq} | @code{huffpuff} @code{Ar} @code{huffpuff} | @code{panic} @code{Ar} @code{panic} | @code{step} @code{Ar} @code{srep} | @code{stepout} @code{Ar} @code{stepout} .Oc
+@code{allan} @code{allan} | @code{dispersion} @code{dispersion} | @code{freq} @code{freq} | @code{huffpuff} @code{huffpuff} | @code{panic} @code{panic} | @code{step} @code{srep} | @code{stepout} @code{stepout} .Oc
This command can be used to alter several system variables in
very exceptional circumstances.
It should occur in the
trap
Ar
host_address
-[@code{port} @code{Ar} @code{port_number} ]
-[@code{interface} @code{Ar} @code{interface_address} ]
+[@code{port} @code{port_number} ]
+[@code{interface} @code{interface_address} ]
This command configures a trap receiver at the given host
address and port number for sending messages with the specified
local interface address.
#
# EDIT THIS FILE WITH CAUTION (invoke-ntp.keys.texi)
#
-# It has been AutoGen-ed December 22, 2012 at 11:52:41 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 25, 2012 at 11:34:16 AM by AutoGen 5.16.2
# From the definitions ntp.keys.def
# and the template file agtexi-file.tpl
@end ignore
This document describes the format of an NTP symmetric key file.
For a description of the use of this type of file, see the
-"AuthenticationSupport"
+"Authentication Support"
section of the
@code{ntp.conf(5)}
page.
key
where
-@kbd{keyno} is a positive integer (between 1 and 65534),
-@kbd{type} is the message digest algorithm,
+@code{keyno} is a positive integer (between 1 and 65534),
+@code{type} is the message digest algorithm,
and
-@kbd{key} is the key itself.
+@code{key} is the key itself.
The
-@kbd{key} may be given in a format
+@code{key} may be given in a format
controlled by the
-@kbd{type} field.
+@code{type} field.
The
-@kbd{type} .Li
+@code{type} .Li
MD5
is always supported.
If
was built with the OpenSSL library
then any digest library supported by that library may be specified.
However, if compliance with FIPS 140-2 is required the
-@kbd{type} must be either
+@code{type} must be either
.Li
SHA
or
#
# EDIT THIS FILE WITH CAUTION (invoke-ntpd.texi)
#
-# It has been AutoGen-ed December 22, 2012 at 11:52:48 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 25, 2012 at 11:34:26 AM by AutoGen 5.16.2
# From the definitions ntpd-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-ntpd - NTP daemon program - Ver. 4.2.7p337
+ntpd - NTP daemon program - Ver. 4.2.7p338
USAGE: ntpd [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]... \
[ <server1> ... <serverN> ]
Flg Arg Option-Name Description
normal tracking mode.
In the most extreme cases
(the host
-time.ien.it comes to mind), there may be occasional
+@code{time.ien.it} comes to mind), there may be occasional
step/slew corrections and subsequent frequency corrections.
It
helps in these cases to use the
behavior at startup depends on whether the
frequency file, usually
@file{ntp.drift},
-,
exists.
This file
contains the latest estimate of clock frequency error.
utility can operate in any of several modes, including
symmetric active/passive, client/server broadcast/multicast and
manycast, as described in the
-"AssociationManagement"
+"Association Management"
page
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp}).
-)
-.
It normally operates continuously while
monitoring for small changes in frequency and trimming the clock
for the ultimate precision.
.
A snapshot of this documentation is available in HTML format in
@file{/usr/share/doc/ntp}.
-.
.Rs
.%A
David
-.TH ntp.conf 5man "22 Dec 2012" "4.2.7p337" "File Formats"
+.TH ntp.conf 5man "25 Dec 2012" "4.2.7p338" "File Formats"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:47:25 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:32:38 AM by AutoGen 5.16.2
.\" From the definitions ntp.conf.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTP_CONF 5mdoc File Formats
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:52:50 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:28 AM by AutoGen 5.16.2
.\" From the definitions ntp.conf.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
<p>This document describes the configuration file for the NTP Project's
<code>ntpd</code> program.
- <p>This document applies to version 4.2.7p337 of <code>ntp.conf</code>.
+ <p>This document applies to version 4.2.7p338 of <code>ntp.conf</code>.
<ul class="menu">
<li><a accesskey="1" href="#ntp_002econf-Description">ntp.conf Description</a>
-.TH ntp.conf 5 "22 Dec 2012" "4.2.7p337" "File Formats"
+.TH ntp.conf 5 "25 Dec 2012" "4.2.7p338" "File Formats"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:47:25 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:32:38 AM by AutoGen 5.16.2
.\" From the definitions ntp.conf.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTP_CONF 5 File Formats
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:52:50 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:28 AM by AutoGen 5.16.2
.\" From the definitions ntp.conf.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
-.TH ntp.keys 5man "22 Dec 2012" "4.2.7p337" "File Formats"
+.TH ntp.keys 5man "25 Dec 2012" "4.2.7p338" "File Formats"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:47:29 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:32:41 AM by AutoGen 5.16.2
.\" From the definitions ntp.keys.def
.\" and the template file agman-file.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTP_KEYS 5mdoc File Formats
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:52:52 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:30 AM by AutoGen 5.16.2
.\" From the definitions ntp.keys.def
.\" and the template file agmdoc-file.tpl
.Sh NAME
<p>This document describes the symmetric key file for the NTP Project's
<code>ntpd</code> program.
- <p>This document applies to version 4.2.7p337 of <code>ntp.keys</code>.
+ <p>This document applies to version 4.2.7p338 of <code>ntp.keys</code>.
<div class="shortcontents">
<h2>Short Contents</h2>
-.TH ntp.keys 5 "22 Dec 2012" "4.2.7p337" "File Formats"
+.TH ntp.keys 5 "25 Dec 2012" "4.2.7p338" "File Formats"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:47:29 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:32:41 AM by AutoGen 5.16.2
.\" From the definitions ntp.keys.def
.\" and the template file agman-file.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTP_KEYS 5 File Formats
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:52:52 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:30 AM by AutoGen 5.16.2
.\" From the definitions ntp.keys.def
.\" and the template file agmdoc-file.tpl
.Sh NAME
/*
* EDIT THIS FILE WITH CAUTION (ntpd-opts.c)
*
- * It has been AutoGen-ed December 22, 2012 at 11:46:28 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:31:45 AM by AutoGen 5.16.2
* From the definitions ntpd-opts.def
* and the template file options
*
* ntpd option static const strings
*/
static char const ntpd_opt_strs[2987] =
-/* 0 */ "ntpd 4.2.7p337\n"
+/* 0 */ "ntpd 4.2.7p338\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 2753 */ "Output version information and exit\0"
/* 2789 */ "version\0"
/* 2797 */ "NTPD\0"
-/* 2802 */ "ntpd - NTP daemon program - Ver. 4.2.7p337\n"
+/* 2802 */ "ntpd - NTP daemon program - Ver. 4.2.7p338\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \\\n"
"\t\t[ <server1> ... <serverN> ]\n\0"
/* 2935 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 2969 */ "\n\n\0"
-/* 2972 */ "ntpd 4.2.7p337";
+/* 2972 */ "ntpd 4.2.7p338";
/*
* ipv4 option description with
/*
* EDIT THIS FILE WITH CAUTION (ntpd-opts.h)
*
- * It has been AutoGen-ed December 22, 2012 at 11:46:27 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:31:44 AM by AutoGen 5.16.2
* From the definitions ntpd-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 37
-#define NTPD_VERSION "4.2.7p337"
-#define NTPD_FULL_VERSION "ntpd 4.2.7p337"
+#define NTPD_VERSION "4.2.7p338"
+#define NTPD_FULL_VERSION "ntpd 4.2.7p338"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntpd 1ntpdman "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH ntpd 1ntpdman "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:47:32 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:32:45 AM by AutoGen 5.16.2
.\" From the definitions ntpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTPD 1ntpdmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:52:54 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:32 AM by AutoGen 5.16.2
.\" From the definitions ntpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
used to select the program, defaulting to <span class="file">more</span>. Both will exit
with a status code of 0.
-<pre class="example">ntpd - NTP daemon program - Ver. 4.2.7p336
+<pre class="example">ntpd - NTP daemon program - Ver. 4.2.7p337
USAGE: ntpd [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \
[ <server1> ... <serverN> ]
Flg Arg Option-Name Description
-.TH ntpd @NTPD_MS@ "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH ntpd @NTPD_MS@ "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:47:32 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:32:45 AM by AutoGen 5.16.2
.\" From the definitions ntpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTPD @NTPD_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:52:54 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:32 AM by AutoGen 5.16.2
.\" From the definitions ntpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
#
# EDIT THIS FILE WITH CAUTION (invoke-ntpdc.texi)
#
-# It has been AutoGen-ed December 22, 2012 at 11:53:15 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 25, 2012 at 11:34:55 AM by AutoGen 5.16.2
# From the definitions ntpdc-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p337
+ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p338
USAGE: ntpdc [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]... [ host ...]
Flg Arg Option-Name Description
-4 no ipv4 Force IPv4 DNS name resolution
The output of a
command is normally sent to the standard output, but optionally the
output of individual commands may be sent to a file by appending a
-@quoteleft{}\&>,@quoteright{}
+@quoteleft{}\&> ,@quoteright{}
followed by a file name, to the command line.
A number of interactive format commands are executed entirely
@item Ic
@item Ic
A
-@quoteleft{}Ic\&?@quoteright{}
+@quoteleft{}Ic \&?@quoteright{}
will print a list of all the command
keywords known to this incarnation of
@code{ntpdc}.
A
-@quoteleft{}Ic\&?@quoteright{}
+@quoteleft{}Ic \&?@quoteright{}
followed by a command keyword will print function and usage
information about the command.
This command is probably a better
It may
be a host name, an IP address, a reference clock implementation
name with its parameter or
-.Fn
-REFCLK
-"implementation_number"
-"parameter"
-.
+@code{REFCLK}(@emph{implementation_number}@code{, }@emph{parameter}).
On
@code{hostnames} @code{no} only IP-addresses
will be displayed.
phase-lock loop and thus the speed at which it can adapt to
oscillator drift.
The
-@quoteleft{}watchdogtimer@quoteright{}
+@quoteleft{}watchdog timer@quoteright{}
value is the number
of seconds which have elapsed since the last sample offset was
given to the loop filter.
in the NTP Version 3 specification, RFC-1305.
The
-@quoteleft{}systemflags@quoteright{}
+@quoteleft{}system flags@quoteright{}
show various system flags, some of
which can be set and cleared by the
@code{enable} and
The following commands all make authenticated requests.
@table @samp
@item Xo
-[@kbd{keyid} ]
-[@kbd{version} ]
+[@code{keyid} ]
+[@code{version} ]
[@code{prefer} ]
Add a configured peer association at the given address and
operating in symmetric active mode.
executed, or may simply be converted to conform to the new
configuration, as appropriate.
If the optional
-@kbd{keyid} is a
+@code{keyid} is a
nonzero integer, all outgoing packets to the remote server will
have an authentication field attached encrypted with this key.
If
the value is 0 (or not given) no authentication will be done.
The
-@kbd{version} can be 1, 2 or 3 and defaults to 3.
+@code{version} can be 1, 2 or 3 and defaults to 3.
The
@code{prefer} keyword indicates a preferred peer (and thus will
be used primarily for clock synchronisation if possible).
the preferred peer is suitable for synchronisation so is the PPS
signal.
@item Xo
-[@kbd{keyid} ]
-[@kbd{version} ]
+[@code{keyid} ]
+[@code{version} ]
[@code{prefer} ]
Identical to the addpeer command, except that the operating
mode is client.
@item Xo
-[@kbd{keyid} ]
-[@kbd{version} ]
+[@code{keyid} ]
+[@code{version} ]
[@code{prefer} ]
Identical to the addpeer command, except that the operating
mode is broadcast.
In this case a valid key identifier and key are
required.
The
-@kbd{peer_address} parameter can be the broadcast
+@code{peer_address} parameter can be the broadcast
address of the local network or a multicast group address assigned
to NTP.
If a multicast address, a multicast-capable kernel is
@item Xo
[@code{time1} ]
[@code{time2} ]
-[@kbd{stratum} ]
-[@kbd{refid} ]
+[@code{stratum} ]
+[@code{refid} ]
This command provides a way to set certain data for a reference
clock.
See the source listing for further information.
Enables the pulse-per-second (PPS) signal when frequency
and time is disciplined by the precision time kernel modifications.
See the
-"AKernelModelforPrecisionTimekeeping"
+"A Kernel Model for Precision Timekeeping"
(available as part of the HTML documentation
provided in
@file{/usr/share/doc/ntp})
-)
page for further information.
The default for this flag is disable.
@item Cm
address
Ar
mask
-@kbd{flag} @kbd{Oo} @kbd{Ar}... @kbd{Oc} This command operates in the same way as the
+@code{flag} @code{Oo} @code{...} @code{Oc} This command operates in the same way as the
@code{restrict} configuration file commands of
@code{ntpd(8)}.
.It
address
Ar
mask
-@kbd{flag} @kbd{Oo} @kbd{Ar}... @kbd{Oc} Unrestrict the matching entry from the restrict list.
+@code{flag} @code{Oo} @code{...} @code{Oc} Unrestrict the matching entry from the restrict list.
.It
Xo
Ic
addtrap
Ar
address
-[@kbd{port} ]
-[@kbd{interface} ]
+[@code{port} ]
+[@code{interface} ]
Set a trap for asynchronous messages.
See the source listing
for further information.
clrtrap
Ar
address
-[@kbd{port} ]
-[@kbd{interface} ]
+[@code{port} ]
+[@code{interface} ]
Clear a trap for asynchronous messages.
See the source listing
for further information.
/*
* EDIT THIS FILE WITH CAUTION (ntpdc-opts.c)
*
- * It has been AutoGen-ed December 22, 2012 at 11:53:05 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:34:45 AM by AutoGen 5.16.2
* From the definitions ntpdc-opts.def
* and the template file options
*
* ntpdc option static const strings
*/
static char const ntpdc_opt_strs[1862] =
-/* 0 */ "ntpdc 4.2.7p337\n"
+/* 0 */ "ntpdc 4.2.7p338\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 1640 */ "no-load-opts\0"
/* 1653 */ "no\0"
/* 1656 */ "NTPDC\0"
-/* 1662 */ "ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p337\n"
+/* 1662 */ "ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p338\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]... [ host ...]\n\0"
/* 1794 */ "$HOME\0"
/* 1800 */ ".\0"
/* 1802 */ ".ntprc\0"
/* 1809 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 1843 */ "\n\n\0"
-/* 1846 */ "ntpdc 4.2.7p337";
+/* 1846 */ "ntpdc 4.2.7p338";
/*
* ipv4 option description with
/*
* EDIT THIS FILE WITH CAUTION (ntpdc-opts.h)
*
- * It has been AutoGen-ed December 22, 2012 at 11:53:04 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:34:45 AM by AutoGen 5.16.2
* From the definitions ntpdc-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 15
-#define NTPDC_VERSION "4.2.7p337"
-#define NTPDC_FULL_VERSION "ntpdc 4.2.7p337"
+#define NTPDC_VERSION "4.2.7p338"
+#define NTPDC_FULL_VERSION "ntpdc 4.2.7p338"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntpdc 1ntpdcman "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH ntpdc 1ntpdcman "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpdc-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:11 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:51 AM by AutoGen 5.16.2
.\" From the definitions ntpdc-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTPDC 1ntpdcmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpdc-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:17 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:57 AM by AutoGen 5.16.2
.\" From the definitions ntpdc-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
clock. Run as root, it can correct the system clock to this offset as
well. It can be run as an interactive command or from a cron job.
- <p>This document applies to version 4.2.7p337 of <code>ntpdc</code>.
+ <p>This document applies to version 4.2.7p338 of <code>ntpdc</code>.
<p>The program implements the SNTP protocol as defined by RFC 5905, the NTPv4
IETF specification.
used to select the program, defaulting to <span class="file">more</span>. Both will exit
with a status code of 0.
-<pre class="example">ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p337
+<pre class="example">ntpdc - vendor-specific NTPD control program - Ver. 4.2.7p338
USAGE: ntpdc [ -<flag> [<val>] | --<name>[{=| }<val>] ]... [ host ...]
Flg Arg Option-Name Description
-4 no ipv4 Force IPv4 DNS name resolution
The output of a
command is normally sent to the standard output, but optionally the
output of individual commands may be sent to a file by appending a
-\&>,
+\&> ,
followed by a file name, to the command line.
<p>A number of interactive format commands are executed entirely
following.
<dl>
<dt><span class="samp">Ic</span><br><dt><span class="samp">Ic</span><dd>A
-Ic\&?
+Ic \&?
will print a list of all the command
keywords known to this incarnation of
<code>ntpdc</code>.
A
-Ic\&?
+Ic \&?
followed by a command keyword will print function and usage
information about the command.
This command is probably a better
-.TH ntpdc @NTPDC_MS@ "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH ntpdc @NTPDC_MS@ "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpdc-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:11 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:51 AM by AutoGen 5.16.2
.\" From the definitions ntpdc-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTPDC @NTPDC_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpdc-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:17 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:34:57 AM by AutoGen 5.16.2
.\" From the definitions ntpdc-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
#
# EDIT THIS FILE WITH CAUTION (invoke-ntpq.texi)
#
-# It has been AutoGen-ed December 24, 2012 at 08:22:53 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 25, 2012 at 11:35:11 AM by AutoGen 5.16.2
# From the definitions ntpq-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
than this manual
page.
@item Ic
-... @item Ic
+@code{...} @item Ic
@item Ic
The data carried by NTP mode 6 messages consists of a list of
items of the form
-@quoteleft{}variable_name=value,@quoteright{}
+@quoteleft{}variable_name=value ,@quoteright{}
where the
@quoteleft{}=value@quoteright{}
is ignored, and can be omitted,
does not authenticate requests unless
they are write requests.
The command
-@quoteleft{}authenticateyes@quoteright{}
+@quoteleft{}authenticate yes@quoteright{}
causes
@code{ntpq}
to send authentication with all requests it
@code{ntpq}
thinks should have a decodable value but didn't are
marked with a trailing
-@quoteleft{}\&?.@quoteright{}
+@quoteleft{}\&? .@quoteright{}
@item Xo
@code{debug} .Oo
@code{more} | @code{less} | @code{off} .Oc
so this command may be obsolete.
@item Ic
Set the host to which future queries will be sent.
-@kbd{hostname} may be either a host name or a numeric address.
+@code{hostname} may be either a host name or a numeric address.
@item Ic
If
@code{yes} is specified, host names are printed in
@exampleindent 0
@example
-ntpq - standard NTP query program - Ver. 4.2.7p337
+ntpq - standard NTP query program - Ver. 4.2.7p338
USAGE: ntpq [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]... [ host ...]
Flg Arg Option-Name Description
-4 no ipv4 Force IPv4 DNS name resolution
/*
* EDIT THIS FILE WITH CAUTION (ntpq-opts.c)
*
- * It has been AutoGen-ed December 22, 2012 at 11:53:20 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:35:01 AM by AutoGen 5.16.2
* From the definitions ntpq-opts.def
* and the template file options
*
* ntpq option static const strings
*/
static char const ntpq_opt_strs[1833] =
-/* 0 */ "ntpq 4.2.7p337\n"
+/* 0 */ "ntpq 4.2.7p338\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 1627 */ "no-load-opts\0"
/* 1640 */ "no\0"
/* 1643 */ "NTPQ\0"
-/* 1648 */ "ntpq - standard NTP query program - Ver. 4.2.7p337\n"
+/* 1648 */ "ntpq - standard NTP query program - Ver. 4.2.7p338\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]... [ host ...]\n\0"
/* 1769 */ "$HOME\0"
/* 1775 */ ".\0"
/* 1777 */ ".ntprc\0"
/* 1784 */ "http://bugs.ntp.org, bugs@ntp.org\0"
-/* 1818 */ "ntpq 4.2.7p337";
+/* 1818 */ "ntpq 4.2.7p338";
/*
* ipv4 option description with
/*
* EDIT THIS FILE WITH CAUTION (ntpq-opts.h)
*
- * It has been AutoGen-ed December 22, 2012 at 11:53:20 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:35:00 AM by AutoGen 5.16.2
* From the definitions ntpq-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 14
-#define NTPQ_VERSION "4.2.7p337"
-#define NTPQ_FULL_VERSION "ntpq 4.2.7p337"
+#define NTPQ_VERSION "4.2.7p338"
+#define NTPQ_FULL_VERSION "ntpq 4.2.7p338"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntpq 1ntpqman "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH ntpq 1ntpqman "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpq-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:27 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:07 AM by AutoGen 5.16.2
.\" From the definitions ntpq-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTPQ 1ntpqmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpq-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:32 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:13 AM by AutoGen 5.16.2
.\" From the definitions ntpq-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
<title>ntpq: Network Time Protocol Query User's Manual</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="ntpq: Network Time Protocol Query User's Manual">
-<meta name="generator" content="makeinfo 4.13">
+<meta name="generator" content="makeinfo 4.7">
<link title="Top" rel="top" href="#Top">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<meta http-equiv="Content-Style-Type" content="text/css">
pre.smallformat { font-family:inherit; font-size:smaller }
pre.smallexample { font-size:smaller }
pre.smalllisp { font-size:smaller }
- span.sc { font-variant:small-caps }
- span.roman { font-family:serif; font-weight:normal; }
- span.sansserif { font-family:sans-serif; font-weight:normal; }
+ span.sc { font-variant:small-caps }
+ span.roman { font-family: serif; font-weight: normal; }
--></style>
</head>
<body>
<h1 class="settitle">ntpq: Network Time Protocol Query User's Manual</h1>
- <div class="shortcontents">
+
<div class="shortcontents">
<h2>Short Contents</h2>
<ul>
<a href="#Top">Top</a>
<div class="node">
-<a name="Top"></a>
<p><hr>
-Up: <a rel="up" accesskey="u" href="#dir">(dir)</a>
-
+
<a name="Top"></a>Up: <a rel="up" accesskey="u" href="#dir">(dir)</a>
+<br>
</div>
<h2 class="unnumbered">Top</h2>
</ul>
<div class="node">
-<a name="Top"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#ntpq-Description">ntpq Description</a>,
+
<a name="Top"></a>Next: <a rel="next" accesskey="n" href="#ntpq-Description">ntpq Description</a>,
Previous: <a rel="previous" accesskey="p" href="#dir">(dir)</a>,
Up: <a rel="up" accesskey="u" href="#dir">(dir)</a>
-
+<br>
</div>
<h2 class="unnumbered">ntpq: Network Time Protocol Query User Manual</h2>
</ul>
<div class="node">
-<a name="ntpq-Description"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#Usage">Usage</a>,
+
<a name="ntpq-Description"></a>Next: <a rel="next" accesskey="n" href="#Usage">Usage</a>,
Previous: <a rel="previous" accesskey="p" href="#Top">Top</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-
+<br>
</div>
<!-- node-name, next, previous, up -->
<p>For examples and usage, see the <a href="debug.html">NTP Debugging Techniques</a> page.
<div class="node">
-<a name="Usage"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#Internal-Commands">Internal Commands</a>,
+<a name="ntpq-Invocation"></a>
+<br>
+</div>
+
+<h3 class="section">Invoking ntpq</h3>
+
+<p><a name="index-ntpq-1"></a><a name="index-standard-NTP-query-program-2"></a>
+
+ <p>The
+<code>ntpq</code>
+utility program is used to query NTP servers which
+implement the standard NTP mode 6 control message formats defined
+in Appendix B of the NTPv3 specification RFC1305, requesting
+information about current state and/or changes in that state.
+The same formats are used in NTPv4, although some of the
+variables have changed and new ones added. The description on this
+page is for the NTPv4 variables.
+The program may be run either in interactive mode or controlled using
+command line arguments.
+Requests to read and write arbitrary
+variables can be assembled, with raw and pretty-printed output
+options being available.
+The
+<code>ntpq</code>
+utility can also obtain and print a
+list of peers in a common format by sending multiple queries to the
+server.
+
+ <p>If one or more request options is included on the command line
+when
+<code>ntpq</code>
+is executed, each of the requests will be sent
+to the NTP servers running on each of the hosts given as command
+line arguments, or on localhost by default.
+If no request options
+are given,
+<code>ntpq</code>
+will attempt to read commands from the
+standard input and execute these on the NTP server running on the
+first host given on the command line, again defaulting to localhost
+when no other host is specified.
+The
+<code>ntpq</code>
+utility will prompt for
+commands if the standard input is a terminal device.
+
+ <p><code>ntpq</code>
+uses NTP mode 6 packets to communicate with the
+NTP server, and hence can be used to query any compatible server on
+the network which permits it.
+Note that since NTP is a UDP protocol
+this communication will be somewhat unreliable, especially over
+large distances in terms of network topology.
+The
+<code>ntpq</code>
+utility makes
+one attempt to retransmit requests, and will time requests out if
+the remote host is not heard from within a suitable timeout
+time.
+
+ <p>Specifying a
+command line option other than
+<code>-i</code> or
+<code>-n</code> will
+cause the specified query (queries) to be sent to the indicated
+host(s) immediately.
+Otherwise,
+<code>ntpq</code>
+will attempt to read
+interactive format commands from the standard input.
+<div class="node">
+<p><hr>
+<a name="Internal-Commands"></a>
+<br>
+</div>
+
+<h3 class="section">Internal Commands</h3>
+
+<p>Internal Commands
+Interactive format commands consist of a keyword followed by zero
+to four arguments.
+Only enough characters of the full keyword to
+uniquely identify the command need be typed.
+
+ <p>A
+number of interactive format commands are executed entirely within
+the
+<code>ntpq</code>
+utility itself and do not result in NTP mode 6
+requests being sent to a server.
+These are described following.
+ <dl>
+<dt><span class="samp">Ic</span><br><dt><span class="samp">Ic</span><dd>A
+\&?
+by itself will print a list of all the command
+keywords known to this incarnation of
+<code>ntpq</code>.
+A
+\&?
+followed by a command keyword will print function and usage
+information about the command.
+This command is probably a better
+source of information about
+<code>ntpq</code>
+than this manual
+page.
+<br><dt><span class="samp">Ic</span><dd>... <br><dt><span class="samp">Ic</span><br><dt><span class="samp">Ic</span><dd>The data carried by NTP mode 6 messages consists of a list of
+items of the form
+variable_name=value,
+where the
+=value
+is ignored, and can be omitted,
+in requests to the server to read variables.
+The
+<code>ntpq</code>
+utility maintains an internal list in which data to be included in control
+messages can be assembled, and sent using the
+<code>readlist</code> and
+<code>writelist</code> commands described below.
+The
+<code>addvars</code> command allows variables and their optional values to be added to
+the list.
+If more than one variable is to be added, the list should
+be comma-separated and not contain white space.
+The
+<code>rmvars</code> command can be used to remove individual variables from the list,
+while the
+<code>clearlist</code> command removes all variables from the
+list.
+<br><dt><span class="samp">Ic</span><dd>Normally
+<code>ntpq</code>
+does not authenticate requests unless
+they are write requests.
+The command
+authenticateyes
+causes
+<code>ntpq</code>
+to send authentication with all requests it
+makes.
+Authenticated requests causes some servers to handle
+requests slightly differently, and can occasionally melt the CPU in
+fuzzballs if you turn authentication on before doing a
+<code>peer</code> display.
+The command
+authenticate
+causes
+<code>ntpq</code>
+to display whether or not
+<code>ntpq</code>
+is currently autheinticating requests.
+<br><dt><span class="samp">Ic</span><dd>Causes output from query commands to be "cooked", so that
+variables which are recognized by
+<code>ntpq</code>
+will have their
+values reformatted for human consumption.
+Variables which
+<code>ntpq</code>
+thinks should have a decodable value but didn't are
+marked with a trailing
+\&?.
+<br><dt><span class="samp">Xo</span><dd><code>debug</code> .Oo
+<code>more</code> | <code>less</code> | <code>off</code> .Oc
+With no argument, displays the current debug level.
+Otherwise, the debug level is changed to the indicated level.
+<br><dt><span class="samp">Ic</span><dd>Specify a time interval to be added to timestamps included in
+requests which require authentication.
+This is used to enable
+(unreliable) server reconfiguration over long delay network paths
+or between machines whose clocks are unsynchronized.
+Actually the
+server does not now require timestamps in authenticated requests,
+so this command may be obsolete.
+<br><dt><span class="samp">Ic</span><dd>Set the host to which future queries will be sent.
+<kbd>hostname</kbd> may be either a host name or a numeric address.
+<br><dt><span class="samp">Ic</span><dd>If
+<code>yes</code> is specified, host names are printed in
+information displays.
+If
+<code>no</code> is specified, numeric
+addresses are printed instead.
+The default is
+<code>yes</code>, unless
+modified using the command line
+<code>-n</code> switch.
+<br><dt><span class="samp">Ic</span><dd>This command allows the specification of a key number to be
+used to authenticate configuration requests.
+This must correspond
+to a key number the server has been configured to use for this
+purpose.
+<br><dt><span class="samp">Ic</span><dd><code>1</code> | <code>2</code> | <code>3</code> | <code>4</code> .Oc
+Sets the NTP version number which
+<code>ntpq</code>
+claims in
+packets.
+Defaults to 3, and note that mode 6 control messages (and
+modes, for that matter) didn't exist in NTP version 1.
+There appear
+to be no servers left which demand version 1.
+With no argument, displays the current NTP version that will be used
+when communicating with servers.
+<br><dt><span class="samp">Ic</span><dd>Exit
+<code>ntpq</code>
+<br><dt><span class="samp">Ic</span><dd>This command prompts you to type in a password (which will not
+be echoed) which will be used to authenticate configuration
+requests.
+The password must correspond to the key configured for
+use by the NTP server for this purpose if such requests are to be
+successful.
+<br><dt><span class="samp">Ic</span><dd>Causes all output from query commands is printed as received
+from the remote server.
+The only formating/interpretation done on
+the data is to transform nonascii data into a printable (but barely
+understandable) form.
+<br><dt><span class="samp">Ic</span><dd>Specify a timeout period for responses to server queries.
+The
+default is about 5000 milliseconds.
+Note that since
+<code>ntpq</code>
+retries each query once after a timeout, the total waiting time for
+a timeout will be twice the timeout value set.
+
+ <p>This section was generated by <strong>AutoGen</strong>,
+using the <code>agtexi-cmd</code> template and the option descriptions for the <code>ntpq</code> program.
+This software is released under the NTP license, <http://ntp.org/license>.
+
+ <ul class="menu">
+<li><a accesskey="1" href="#ntpq-usage">ntpq usage</a>: ntpq help/usage (<span class="option">--help</span>)
+<li><a accesskey="2" href="#ntpq-ipv4">ntpq ipv4</a>: ipv4 option (-4)
+<li><a accesskey="3" href="#ntpq-ipv6">ntpq ipv6</a>: ipv6 option (-6)
+<li><a accesskey="4" href="#ntpq-command">ntpq command</a>: command option (-c)
+<li><a accesskey="5" href="#ntpq-peers">ntpq peers</a>: peers option (-p)
+<li><a accesskey="6" href="#ntpq-interactive">ntpq interactive</a>: interactive option (-i)
+<li><a accesskey="7" href="#ntpq-numeric">ntpq numeric</a>: numeric option (-n)
+<li><a accesskey="8" href="#ntpq-old_002drv">ntpq old-rv</a>: old-rv option
+<li><a accesskey="9" href="#ntpq-config">ntpq config</a>: presetting/configuring ntpq
+<li><a href="#ntpq-exit-status">ntpq exit status</a>: exit status
+</ul>
+
+<div class="node">
+<p><hr>
+<a name="ntpq-usage"></a>Next: <a rel="next" accesskey="n" href="#ntpq-ipv4">ntpq ipv4</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">ntpq help/usage (<span class="option">--help</span>)</h4>
+
+ <p><a name="index-ntpq-help-3"></a>
+This is the automatically generated usage text for ntpq.
+
+ <p>The text printed is the same whether selected with the <code>help</code> option
+(<span class="option">--help</span>) or the <code>more-help</code> option (<span class="option">--more-help</span>). <code>more-help</code> will print
+the usage text by passing it through a pager program.
+<code>more-help</code> is disabled on platforms without a working
+<code>fork(2)</code> function. The <code>PAGER</code> environment variable is
+used to select the program, defaulting to <span class="file">more</span>. Both will exit
+with a status code of 0.
+
+ <pre class="example"> ntpq - standard NTP query program - Ver. 4.2.7p337
+ USAGE: ntpq [ -<flag> [<val>] | --<name>[{=| }<val>] ]... [ host ...]
+ Flg Arg Option-Name Description
+ -4 no ipv4 Force IPv4 DNS name resolution
+ - prohibits these options:
+ ipv6
+ -6 no ipv6 Force IPv6 DNS name resolution
+ - prohibits these options:
+ ipv4
+ -c Str command run a command and exit
+ - may appear multiple times
+ -d no debug-level Increase debug verbosity level
+ - may appear multiple times
+ -D Num set-debug-level Set the debug verbosity level
+ - may appear multiple times
+ -p no peers Print a list of the peers
+ - prohibits these options:
+ interactive
+ -i no interactive Force ntpq to operate in interactive mode
+ - prohibits these options:
+ command
+ peers
+ -n no numeric numeric host addresses
+ no old-rv Always output status line with readvar
+ opt version Output version information and exit
+ -? no help Display extended usage information and exit
+ -! no more-help Extended usage information passed thru pager
+ -> opt save-opts Save the option state to a config file
+ -< Str load-opts Load options from a config file
+ - disabled as --no-load-opts
+ - may appear multiple times
+
+ Options are specified by doubled hyphens and their name or by a single
+ hyphen and the flag character.
+
+ The following option preset mechanisms are supported:
+ - reading file $HOME/.ntprc
+ - reading file ./.ntprc
+ - examining environment variables named NTPQ_*
+
+ please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+</pre>
+ <div class="node">
+<p><hr>
+<a name="ntpq-ipv4"></a>Next: <a rel="next" accesskey="n" href="#ntpq-ipv6">ntpq ipv6</a>,
+Previous: <a rel="previous" accesskey="p" href="#ntpq-usage">ntpq usage</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">ipv4 option (-4)</h4>
+
+ <p><a name="index-ntpq_002dipv4-4"></a>
+This is the “force ipv4 dns name resolution” option.
+
+ <p class="noindent">This option has some usage constraints. It:
+ <ul>
+<li>must not appear in combination with any of the following options:
+ipv6.
+</ul>
+
+ <p>Force DNS resolution of following host names on the command line
+to the IPv4 namespace.
+<div class="node">
+<p><hr>
+<a name="ntpq-ipv6"></a>Next: <a rel="next" accesskey="n" href="#ntpq-command">ntpq command</a>,
+Previous: <a rel="previous" accesskey="p" href="#ntpq-ipv4">ntpq ipv4</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">ipv6 option (-6)</h4>
+
+ <p><a name="index-ntpq_002dipv6-5"></a>
+This is the “force ipv6 dns name resolution” option.
+
+ <p class="noindent">This option has some usage constraints. It:
+ <ul>
+<li>must not appear in combination with any of the following options:
+ipv4.
+</ul>
+
+ <p>Force DNS resolution of following host names on the command line
+to the IPv6 namespace.
+<div class="node">
+<p><hr>
+<a name="ntpq-command"></a>Next: <a rel="next" accesskey="n" href="#ntpq-peers">ntpq peers</a>,
+Previous: <a rel="previous" accesskey="p" href="#ntpq-ipv6">ntpq ipv6</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">command option (-c)</h4>
+
+ <p><a name="index-ntpq_002dcommand-6"></a>
+This is the “run a command and exit” option.
+This option takes an argument string <span class="file">cmd</span>.
+
+ <p class="noindent">This option has some usage constraints. It:
+ <ul>
+<li>may appear an unlimited number of times.
+</ul>
+
+ <p>The following argument is interpreted as an interactive format command
+and is added to the list of commands to be executed on the specified
+host(s).
+<div class="node">
+<p><hr>
+<a name="ntpq-peers"></a>Next: <a rel="next" accesskey="n" href="#ntpq-interactive">ntpq interactive</a>,
+Previous: <a rel="previous" accesskey="p" href="#ntpq-command">ntpq command</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">peers option (-p)</h4>
+
+ <p><a name="index-ntpq_002dpeers-7"></a>
+This is the “print a list of the peers” option.
+
+ <p class="noindent">This option has some usage constraints. It:
+ <ul>
+<li>must not appear in combination with any of the following options:
+interactive.
+</ul>
+
+ <p>Print a list of the peers known to the server as well as a summary
+of their state. This is equivalent to the 'peers' interactive command.
+<div class="node">
+<p><hr>
+<a name="ntpq-interactive"></a>Next: <a rel="next" accesskey="n" href="#ntpq-numeric">ntpq numeric</a>,
+Previous: <a rel="previous" accesskey="p" href="#ntpq-peers">ntpq peers</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">interactive option (-i)</h4>
+
+ <p><a name="index-ntpq_002dinteractive-8"></a>
+This is the “force ntpq to operate in interactive mode” option.
+
+ <p class="noindent">This option has some usage constraints. It:
+ <ul>
+<li>must not appear in combination with any of the following options:
+command, peers.
+</ul>
+
+ <p>Force ntpq to operate in interactive mode. Prompts will be written
+to the standard output and commands read from the standard input.
+<div class="node">
+<p><hr>
+<a name="ntpq-numeric"></a>Next: <a rel="next" accesskey="n" href="#ntpq-old_002drv">ntpq old-rv</a>,
+Previous: <a rel="previous" accesskey="p" href="#ntpq-interactive">ntpq interactive</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">numeric option (-n)</h4>
+
+ <p><a name="index-ntpq_002dnumeric-9"></a>
+This is the “numeric host addresses” option.
+Output all host addresses in dotted-quad numeric format rather than
+converting to the canonical host names.
+<div class="node">
+<p><hr>
+<a name="ntpq-old_002drv"></a>Next: <a rel="next" accesskey="n" href="#ntpq-config">ntpq config</a>,
+Previous: <a rel="previous" accesskey="p" href="#ntpq-numeric">ntpq numeric</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">old-rv option</h4>
+
+ <p><a name="index-ntpq_002dold_002drv-10"></a>
+This is the “always output status line with readvar” option.
+By default, ntpq now suppresses the associd=... line that
+precedes the output of "readvar" (alias "rv") when a single
+variable is requested, such as ntpq -c "rv 0 offset". This
+option causes ntpq to include both lines of output for a
+single-variable readvar. Using an environment variable to
+preset this option in a script will enable both older and
+newer ntpq to behave identically in this regard.
+
+<div class="node">
+<p><hr>
+<a name="ntpq-config"></a>Next: <a rel="next" accesskey="n" href="#ntpq-exit-status">ntpq exit status</a>,
+Previous: <a rel="previous" accesskey="p" href="#ntpq-old_002drv">ntpq old-rv</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">presetting/configuring ntpq</h4>
+
+ <p>Any option that is not marked as <i>not presettable</i> may be preset by
+loading values from configuration ("rc" or "ini") files, and values from environment variables named <code>NTPQ</code> and <code>NTPQ_<OPTION_NAME></code>. <code><OPTION_NAME></code> must be one of
+the options listed above in upper case and segmented with underscores.
+The <code>NTPQ</code> variable will be tokenized and parsed like
+the command line. The remaining variables are tested for existence and their
+values are treated like option arguments.
+
+ <p class="noindent"><code>libopts</code> will search in 2 places for configuration files:
+ <ul>
+<li>$HOME
+<li>$PWD
+</ul>
+ The environment variables <code>HOME</code>, and <code>PWD</code>
+are expanded and replaced when <span class="file">ntpq</span> runs.
+For any of these that are plain files, they are simply processed.
+For any that are directories, then a file named <span class="file">.ntprc</span> is searched for
+within that directory and processed.
+
+ <p>Configuration files may be in a wide variety of formats.
+The basic format is an option name followed by a value (argument) on the
+same line. Values may be separated from the option name with a colon,
+equal sign or simply white space. Values may be continued across multiple
+lines by escaping the newline with a backslash.
+
+ <p>Multiple programs may also share the same initialization file.
+Common options are collected at the top, followed by program specific
+segments. The segments are separated by lines like:
+ <pre class="example"> [NTPQ]
+ </pre>
+ <p class="noindent">or by
+ <pre class="example"> <?program ntpq>
+ </pre>
+ <p class="noindent">Do not mix these styles within one configuration file.
+
+ <p>Compound values and carefully constructed string values may also be
+specified using XML syntax:
+ <pre class="example"> <option-name>
+ <sub-opt>...&lt;...&gt;...</sub-opt>
+ </option-name>
+ </pre>
+ <p class="noindent">yielding an <code>option-name.sub-opt</code> string value of
+ <pre class="example"> "...<...>..."
+ </pre>
+ <p><code>AutoOpts</code> does not track suboptions. You simply note that it is a
+hierarchicly valued option. <code>AutoOpts</code> does provide a means for searching
+the associated name/value pair list (see: optionFindValue).
+
+ <p>The command line options relating to configuration and/or usage help are:
+
+<h5 class="subsubheading">version (-)</h5>
+
+ <p>Print the program version to standard out, optionally with licensing
+information, then exit 0. The optional argument specifies how much licensing
+detail to provide. The default is to print just the version. The licensing infomation may be selected with an option argument. Only the
+first letter of the argument is examined:
+
+ <dl>
+<dt><span class="samp">version</span><dd>Only print the version. This is the default.
+<br><dt><span class="samp">copyright</span><dd>Name the copyright usage licensing terms.
+<br><dt><span class="samp">verbose</span><dd>Print the full copyright usage licensing terms.
+</dl>
+
+<div class="node">
+<p><hr>
+<a name="ntpq-exit-status"></a>Previous: <a rel="previous" accesskey="p" href="#ntpq-config">ntpq config</a>,
+Up: <a rel="up" accesskey="u" href="#Internal-Commands">Internal Commands</a>
+<br>
+</div>
+
+<h4 class="subsection">ntpq exit status</h4>
+
+ <p>One of the following exit values will be returned:
+ <dl>
+<dt><span class="samp">0 (EXIT_SUCCESS)</span><dd>Successful program execution.
+<br><dt><span class="samp">1 (EXIT_FAILURE)</span><dd>The operation failed or the command syntax was not valid.
+<br><dt><span class="samp">66 (EX_NOINPUT)</span><dd>A specified configuration file could not be loaded.
+<br><dt><span class="samp">70 (EX_SOFTWARE)</span><dd>libopts had an internal operational error. Please report
+it to autogen-users@lists.sourceforge.net. Thank you.
+</dl>
+
+<div class="node">
+<p><hr>
+<a name="Usage"></a>Next: <a rel="next" accesskey="n" href="#Internal-Commands">Internal Commands</a>,
Previous: <a rel="previous" accesskey="p" href="#ntpq-Description">ntpq Description</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-
+<br>
</div>
-<!-- node-name, next, previous, up -->
+ <!-- node-name, next, previous, up -->
<h3 class="section">Usage</h3>
-<p><table summary=""><tr align="left"><th valign="top" width="23%">What </th><th valign="top" width="23%">Default </th><th valign="top" width="5%">Flag </th><th valign="top" width="15%">Option
+
<p><table summary=""><tr align="left"><th valign="top" width="23%">What </th><th valign="top" width="23%">Default </th><th valign="top" width="5%">Flag </th><th valign="top" width="15%">Option
<br></th></tr><tr align="left"><td valign="top" width="23%">configuration file
</td><td valign="top" width="23%"><code>/etc/ntp.conf</code>
</td><td valign="top" width="5%"><code>-c</code>
</td><td valign="top" width="15%"><code>keysdir</code>
<div class="node">
-<a name="Internal-Commands"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#Control-Message-Commands">Control Message Commands</a>,
+
<a name="Internal-Commands"></a>Next: <a rel="next" accesskey="n" href="#Control-Message-Commands">Control Message Commands</a>,
Previous: <a rel="previous" accesskey="p" href="#Usage">Usage</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-
+<br>
</div>
-<!-- node-name, next, previous, up -->
+ <!-- node-name, next, previous, up -->
<h3 class="section">Internal Commands</h3>
-<p>Interactive format commands consist of a keyword followed by zero to four arguments. Only enough characters of the full keyword to uniquely identify the command need be typed. The output of a command is normally sent to the standard output, but optionally the output of individual commands may be sent to a file by appending a <code>></code>, followed by a file name, to the command line. A number of interactive format commands are executed entirely within the <code>ntpq</code> program itself and do not result in NTP mode-6 requests being sent to a server. These are described following.
+
<p>Interactive format commands consist of a keyword followed by zero to four arguments. Only enough characters of the full keyword to uniquely identify the command need be typed. The output of a command is normally sent to the standard output, but optionally the output of individual commands may be sent to a file by appending a <code>></code>, followed by a file name, to the command line. A number of interactive format commands are executed entirely within the <code>ntpq</code> program itself and do not result in NTP mode-6 requests being sent to a server. These are described following.
- <dl>
-<dt><code><a name="help"></a>? [</code><kbd>command_keyword</kbd><code><dt>help [</code><kbd>command_keyword</kbd><code>]<dd>A ? by itself will print a list of all the command keywords known to ntpq. A ? followed by a command keyword will print function and usage information about the command.
+<dt><code><a name="help"></a> ? [</code><kbd>command_keyword</kbd><code><dt>help [</code><kbd>command_keyword</kbd><code>]<dd>A ? by itself will print a list of all the command keywords known to ntpq. A ? followed by a command keyword will print function and usage information about the command.
- <br><dt><a name="addvars"></a>>addvars </code><kbd>name</kbd><code> [ = </code><kbd>value</kbd><code>] [...]<dt>rmvars </code><kbd>name</kbd><code> [...]<dt>clearvars</dt><dd>The arguments to these commands consist of a list of items of the form
+ <br><dt><a name="addvars"></a> >addvars </code><kbd>name</kbd><code> [ = </code><kbd>value</kbd><code>] [...]<dt>rmvars </code><kbd>name</kbd><code> [...]<dt>clearvars</dt><dd>The arguments to these commands consist of a list of items of the form
</code><kbd>name</kbd><code> = </code><kbd>value</kbd><code>, where the = </code><kbd>value</kbd><code> is ignored,
and can be omitted in read requests.
ntpq maintains an internal list in which data to be included
from the list,
while the clearlist command removes all variables from the list.
- <br><dt><a name="cooked"></a>cooked<dd>Display server messages in prettyprint format.
+ <br><dt><a name="cooked"></a> cooked<dd>Display server messages in prettyprint format.
- <br><dt><a name="debug"></a>debug more | less | off<dd>Turns internal query program debugging on and off.
+ <br><dt><a name="debug"></a> debug more | less | off<dd>Turns internal query program debugging on and off.
- <br><dt><a name="delay"></a>delay </code><kbd>milliseconds</kbd><code><dd>Specify a time interval to be added to timestamps included in requests which require authentication. This is used to enable (unreliable) server reconfiguration over long delay network paths or between machines whose clocks are unsynchronized. Actually the server does not now require timestamps in authenticated requests, so this command may be obsolete.
+ <br><dt><a name="delay"></a> delay </code><kbd>milliseconds</kbd><code><dd>Specify a time interval to be added to timestamps included in requests which require authentication. This is used to enable (unreliable) server reconfiguration over long delay network paths or between machines whose clocks are unsynchronized. Actually the server does not now require timestamps in authenticated requests, so this command may be obsolete.
- <br><dt><a name="host"></a>host </code><kbd>name</kbd><code><dd>Set the host to which future queries will be sent.
+ <br><dt><a name="host"></a> host </code><kbd>name</kbd><code><dd>Set the host to which future queries will be sent.
The name may be either a DNS name or a numeric address.
- <br><dt><a name="hostnames"></a>hostnames [yes | no]<dd>If yes is specified, host names are printed in information displays.
+ <br><dt><a name="hostnames"></a> hostnames [yes | no]<dd>If yes is specified, host names are printed in information displays.
If no is specified, numeric addresses are printed instead.
The default is yes,
unless modified using the command line -n switch.
- <br><dt><a name="keyid"></a>keyid </code><kbd>keyid</kbd><code><dd>This command specifies the key number to be used
+ <br><dt><a name="keyid"></a> keyid </code><kbd>keyid</kbd><code><dd>This command specifies the key number to be used
to authenticate configuration requests.
This must correspond to a key ID configured in ntp.conf for this purpose.
- <br><dt><a name="keytype"></a>keytype<dd>Specify the digest algorithm to use for authenticated requests,
+ <br><dt><a name="keytype"></a> keytype<dd>Specify the digest algorithm to use for authenticated requests,
with default MD5.
If the OpenSSL library is installed,
digest can be be any message digest algorithm supported by the library.
The current selections are: MD2, MD4, MD5, MDC2, RIPEMD160, SHA and SHA1.
- <br><dt><a name="ntpversion"></a>ntpversion 1 | 2 | 3 | 4<dd>Sets the NTP version number which ntpq claims in packets.
+ <br><dt><a name="ntpversion"></a> ntpversion 1 | 2 | 3 | 4<dd>Sets the NTP version number which ntpq claims in packets.
Defaults to 2.
Note that mode-6 control messages (and modes, for that matter)
didn't exist in NTP version 1.
- <br><dt><a name="passwd"></a>passwd<dd>This command prompts for a password to authenticate requests.
+ <br><dt><a name="passwd"></a> passwd<dd>This command prompts for a password to authenticate requests.
The password must correspond to the key ID configured in ntp.conf for this purpose.
- <br><dt><a name="quit"></a>quit<dd>Exit ntpq.
+ <br><dt><a name="quit"></a> quit<dd>Exit ntpq.
- <br><dt><a name="raw"></a>raw<dd>Display server messages as received and without reformatting.
+ <br><dt><a name="raw"></a> raw<dd>Display server messages as received and without reformatting.
- <br><dt><a name="timeout"></a>timeout </code><kbd>millseconds</kbd><code><dd>Specify a timeout period for responses to server queries.
+ <br><dt><a name="timeout"></a> timeout </code><kbd>millseconds</kbd><code><dd>Specify a timeout period for responses to server queries.
The default is about 5000 milliseconds.
Note that since ntpq retries each query once after a timeout
the total waiting time for a timeout will be twice the timeout value set.
- </dl>
- <p></code><div class="node">
-<a name="Control-Message-Commands"></a>
+ </dl>
+ <p></code><div class="node">
<p><hr>
-Next: <a rel="next" accesskey="n" href="#Status-Words-and-Kiss-Codes">Status Words and Kiss Codes</a>,
+
<a name="Control-Message-Commands"></a>Next: <a rel="next" accesskey="n" href="#Status-Words-and-Kiss-Codes">Status Words and Kiss Codes</a>,
Previous: <a rel="previous" accesskey="p" href="#Internal-Commands">Internal Commands</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-
+<br>
</div>
-<!-- node-name, next, previous, up -->
+ <!-- node-name, next, previous, up -->
<h3 class="section">Control Message Commands</h3>
-<p>Association IDs are used to identify system, peer and clock variables.
+
<p>Association IDs are used to identify system, peer and clock variables.
System variables are assigned an association ID of zero and system name space,
while each association is assigned a nonzero association ID and peer namespace.
Most control commands send a single mode-6 message to the server
and the <code>mreadlist</code> and <code>mreadvar</code> commands,
which iterate over a range of associations.
- <p><a name="as"></a>
- <dl>
<dt><code>associations</code><dd>Display a list of mobilized associations in the form:
<br>
<code>ind assid status conf reach auth condition last_event cnt</code>
</dl>
- <p><br></td></tr><tr align="left"><th valign="top" width="23%">Variable </th><th valign="top" width="23%">Description
+
<p><br></td></tr><tr align="left"><th valign="top" width="23%">Variable </th><th valign="top" width="23%">Description
-<p><br></th></tr><tr align="left"><td valign="top" width="23%"><code>ind</code>
+
<p><br></th></tr><tr align="left"><td valign="top" width="23%"><code>ind</code>
</td><td valign="top" width="23%">index on this list
-<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>assid</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>assid</code>
</td><td valign="top" width="23%">association ID
-<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>status</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>status</code>
</td><td valign="top" width="23%"><a href="decode.html#peer">peer status word</a>
-<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>conf</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>conf</code>
</td><td valign="top" width="23%"><code>yes</code>: persistent, <code>no</code>: ephemeral
-<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>reach</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>reach</code>
</td><td valign="top" width="23%"><code>yes</code>: reachable, <code>no</code>: unreachable
-<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>auth</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>auth</code>
</td><td valign="top" width="23%"><code>ok</code>, <code>yes</code>, <code>bad</code> and <code>none</code>
-<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>condition</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>condition</code>
</td><td valign="top" width="23%">selection status (see the <code>select</code> field of the <a href="decode.html#peer">peer status word</a>)
-<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>last_event</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>last_event</code>
</td><td valign="top" width="23%">event report (see the <code>event</code> field of the <a href="decode.html#peer">peer status word</a>)
-<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>cnt</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="23%"><code>cnt</code>
event count (see the <code>count</code> field of the <a href="decode.html#peer">peer status word</a>)
- <br></td></tr></table>
+ <br></td></tr></table>
- <p><a name="cv"></a>clockvar <kbd>assocID</kbd> [<kbd>name</kbd> [ = <kbd>value</kbd> [...]] [...]]
+ <p><a name="cv"></a> clockvar <kbd>assocID</kbd> [<kbd>name</kbd> [ = <kbd>value</kbd> [...]] [...]]
cv <kbd>assocID</kbd> [<kbd>name</kbd> [ = <kbd>value</kbd> [...] ][...]]
Display a list of See <a href="#clock">clock variables</a> for those associations supporting a reference clock.
- <p><a name="g_t_003aconfig"></a>:config [...]
+ <p><a name="_003aconfig"></a> :config [...]
Send the remainder of the command line, including whitespace, to the server
as a run-time configuration command in the same format
as the configuration file.
This command is experimental until further notice and clarification.
Authentication is of course required.
- <p><a name="config_002dfrom_002dfile"></a>config-from-file <kbd>filename</kbd>
+ <p><a name="config_002dfrom_002dfile"></a> config-from-file <kbd>filename</kbd>
Send the each line of <kbd>filename</kbd> to the server as
run-time configuration commands in the same format as the configuration file.
This command is experimental until further notice and clarification.
Authentication is required.
- <p><a name="ifstats"></a>ifstats
+ <p><a name="ifstats"></a> ifstats
Display statistics for each local network address.
Authentication is required.
- <p><a name="iostats"></a>iostats
+ <p><a name="iostats"></a> iostats
Display network and reference clock I/O statistics.
- <p><a name="kerninfo"></a>kerninfo
+ <p><a name="kerninfo"></a> kerninfo
Display kernel loop and PPS statistics.
As with other ntpq output, times are in milliseconds.
The precision value displayed is in milliseconds as well,
unlike the precision system variable.
- <p><a name="lassoc"></a>lassociations
+ <p><a name="lassoc"></a> lassociations
Perform the same function as the associations command,
except display mobilized and unmobilized associations.
- <p><a name="monstats"></a>monstats
+ <p><a name="monstats"></a> monstats
Display monitor facility statistics.
- <p><a name="mrulist"></a>mrulist [limited | kod | mincount=<kbd>count</kbd> | laddr=<kbd>localaddr</kbd> | sort=<kbd>sortorder</kbd> | resany=<kbd>hexmask</kbd> | resall=<kbd>hexmask</kbd>]
+ <p><a name="mrulist"></a> mrulist [limited | kod | mincount=<kbd>count</kbd> | laddr=<kbd>localaddr</kbd> | sort=<kbd>sortorder</kbd> | resany=<kbd>hexmask</kbd> | resall=<kbd>hexmask</kbd>]
Obtain and print traffic counts collected and maintained by
the monitor facility.
With the exception of <code>sort=</code><kbd>sortorder</kbd>,
any of those preceded by a minus sign (hyphen) to reverse the sort order.
The output columns are:
- <p><table summary=""><tr align="left"><th valign="top" width="10%">Column </th><th valign="top" width="40%">Description
+
<p><table summary=""><tr align="left"><th valign="top" width="10%">Column </th><th valign="top" width="40%">Description
-<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>lstint</code>
+
<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>lstint</code>
</td><td valign="top" width="40%">
Interval in s between the receipt of the most recent packet from this
address and the completion of the retrieval of the MRU list by <code>ntpq</code>
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>avgint</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>avgint</code>
</td><td valign="top" width="40%">
Average interval in s between packets from this address.
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rstr</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rstr</code>
</td><td valign="top" width="40%">
Restriction flags associated with this address.
Most are copied unchanged from the matching <code>restrict</code> command,
however 0x400 (kod) and 0x20 (limited) flags are cleared unless
the last packet from this address triggered a rate control response.
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>r</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>r</code>
</td><td valign="top" width="40%">
Rate control indicator, either a period, <code>L</code> or <code>K</code> for
no rate control response, rate limiting by discarding, or
rate limiting with a KoD response, respectively.
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>m</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>m</code>
</td><td valign="top" width="40%">
Packet mode.
<br></td></tr><tr align="left"><td valign="top" width="10%"><code>v</code>
</td><td valign="top" width="40%">
Packet version number.
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>count</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>count</code>
</td><td valign="top" width="40%">
Packets received from this address.
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rport</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rport</code>
</td><td valign="top" width="40%">
Source port of last packet from this address.
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>remote address</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>remote address</code>
</td><td valign="top" width="40%">
DNS name, numeric address, or address followed by claimed DNS name which
could not be verified in parentheses.
- <br></td></tr></table>
+ <br></td></tr></table>
- <p><a name="mreadvar"></a><code>mreadvar </code><kbd>assocID</kbd> <kbd>assocID</kbd><code> [ </code><kbd>variable_name</kbd><code> [ = </code><kbd>value</kbd><code>[ ... ]</code>
- <a name="mrv"></a><code>mrv </code><kbd>assocID</kbd> <kbd>assocID</kbd><code> [ </code><kbd>variable_name</kbd><code> [ = </code><kbd>value</kbd><code>[ ... ]</code>
+ <p><a name="mreadvar"></a> <code>mreadvar </code><kbd>assocID</kbd> <kbd>assocID</kbd><code> [ </code><kbd>variable_name</kbd><code> [ = </code><kbd>value</kbd><code>[ ... ]</code>
+ <a name="mrv"></a> <code>mrv </code><kbd>assocID</kbd> <kbd>assocID</kbd><code> [ </code><kbd>variable_name</kbd><code> [ = </code><kbd>value</kbd><code>[ ... ]</code>
Perform the same function as the <code>readvar</code> command,
except for a range of association IDs.
This range is determined from the association list cached by
the most recent <code>associations</code> command.
- <p><a name="passoc"></a><code>passociations</code>
+ <p><a name="passoc"></a> <code>passociations</code>
Perform the same function as the <code>associations command</code>, except that
it uses previously stored data rather than making a new query.
- <p><a name="pe"></a><code>peers</code>
+ <p><a name="pe"></a> <code>peers</code>
Display a list of peers in the form:
<br>
<code>[tally]remote refid st t when pool reach delay offset jitter</code>
- <p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
+
<p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
<br></th></tr><tr align="left"><td valign="top" width="10%"><code>[tally]</code>
</td><td valign="top" width="20%">
single-character code indicating current value of the <code>select</code> field
of the <a href="decode.html#peer">peer status word</a>.
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>remote</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>remote</code>
</td><td valign="top" width="20%">
host name (or IP number) of peer
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>refid</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>refid</code>
</td><td valign="top" width="20%">
association ID or <a href="decode.html#kiss">kiss code</a>.
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>st</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>st</code>
</td><td valign="top" width="20%">
stratum
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>t</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>t</code>
</td><td valign="top" width="20%">
<code>u</code>: unicast or manycast client,
<code>b</code>: broadcast or multicast client,
<code>B</code>: broadcast server,
<code>M</code>: multicast server.
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>when</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>when</code>
</td><td valign="top" width="20%">
sec/min/hr since last received packet
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>poll</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>poll</code>
</td><td valign="top" width="20%">
poll interval (log(2) s)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>reach</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>reach</code>
</td><td valign="top" width="20%">
reach shift register (octal)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>delay</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>delay</code>
</td><td valign="top" width="20%">
roundtrip delay
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>offset</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>offset</code>
</td><td valign="top" width="20%">
offset of server relative to this host
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>jitter</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>jitter</code>
</td><td valign="top" width="20%">
jitter
- <br></td></tr></table>
+ <br></td></tr></table>
- <p><a name="rv"></a>readvar <kbd>assocID</kbd> <kbd>name</kbd> [ = <kbd>value</kbd> ] [,...]
+ <p><a name="rv"></a> readvar <kbd>assocID</kbd> <kbd>name</kbd> [ = <kbd>value</kbd> ] [,...]
rv <kbd>assocID</kbd> [ <kbd>name</kbd> ] [,...]
Display the specified variables.
If <kbd>assocID</kbd> is zero,
where YYYY is the year, MM the month of year, DD the day of month and
TTTT the time of day.
- <p><a name="saveconfig"></a><code>saveconfig </code><kbd>filename</kbd>
+ <p><a name="saveconfig"></a> <code>saveconfig </code><kbd>filename</kbd>
Write the current configuration, including any runtime modifications
given with <code>:config</code> or <code>config-from-file</code>,
to the ntpd host's file <kbd>filename</kbd>.
The filename used is stored in system variable <code>savedconfig</code>.
Authentication is required.
- <p><a name="writevar"></a>writevar <kbd>assocID</kbd> <kbd>name</kbd> = <kbd>value</kbd> [,...]
+ <p><a name="writevar"></a> writevar <kbd>assocID</kbd> <kbd>name</kbd> = <kbd>value</kbd> [,...]
Write the specified variables.
If the <kbd>assocID</kbd> is zero, the variables are from the
<a href="#system">system variables</a> name space, otherwise they are from the
The <kbd>assocID</kbd> is required,
as the same name can occur in both spaces.
- <p><a name="sysinfo_0022_003e_0040code_007bsysinfo_007d-Display-operational-summary_002e-_0040item-_0040anchor_007bsysstats_007d-_0040code_007bsysstats_007d-Print-statistics-counters-maintained-in-the-protocol-module_002e-_0040end-table-_0040node-Status-Words-and-Kiss-Codes"></a> System Variables, Control Message Commands, Top
+
<p><a name="sysinfo_0022_003e_0040code_007bsysinfo_007d-Display-operational-summary_002e-_0040item-_0040anchor_007bsysstats_007d-_0040code_007bsysstats_007d-Print-statistics-counters-maintained-in-the-protocol-module_002e-_0040end-table-_0040node-Status-Words-and-Kiss-Codes"></a> System Variables, Control Message Commands, Top
<!-- node-name, next, previous, up -->
<h3 class="section">Status Words and Kiss Codes</h3>
-<p>The current state of the operating program is shown
+
<p>The current state of the operating program is shown
in a set of status words maintained by the system
and each association separately.
These words are displayed in the <code>rv</code> and <code>as</code> commands
The page also includes a list of system and peer messages,
the code for the latest of which is included in the status word.
- <p>Information resulting from protocol machine state transitions
+
<p>Information resulting from protocol machine state transitions
is displayed using an informal set of ASCII strings called
<a href="decode.html#kiss">kiss codes</a>.
The original purpose was for kiss-o'-death (KoD) packets sent
in the reference identifier field in various billboards.
<div class="node">
-<a name="System-Variables"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#Peer-Variables">Peer Variables</a>,
+
<a name="System-Variables"></a>Next: <a rel="next" accesskey="n" href="#Peer-Variables">Peer Variables</a>,
Previous: <a rel="previous" accesskey="p" href="#Status-Words-and-Kiss-Codes">Status Words and Kiss Codes</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-
+<br>
</div>
-<!-- node-name, next, previous, up -->
+ <!-- node-name, next, previous, up -->
<h3 class="section">System Variables</h3>
-<p>The following system variables appear in the <code>rv</code> billboard.
+
<p>The following system variables appear in the <code>rv</code> billboard.
Not all variables are displayed in some configurations.
- <p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
+
<p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
-<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>status</code>
+
<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>status</code>
</td><td valign="top" width="20%">
<a href="decode.html#sys">system status word</a>
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>version</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>version</code>
</td><td valign="top" width="20%">
NTP software version and build time
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>processor</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>processor</code>
</td><td valign="top" width="20%">
hardware platform and version
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>system</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>system</code>
</td><td valign="top" width="20%">
operating system and version
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>leap</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>leap</code>
</td><td valign="top" width="20%">
leap warning indicator (0-3)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>stratum</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>stratum</code>
</td><td valign="top" width="20%">
stratum (1-15)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>precision</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>precision</code>
</td><td valign="top" width="20%">
precision (log(2) s)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rootdelay</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rootdelay</code>
</td><td valign="top" width="20%">
total roundtrip delay to the primary reference clock
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rootdisp</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rootdisp</code>
</td><td valign="top" width="20%">
total dispersion to the primary reference clock
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>peer</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>peer</code>
</td><td valign="top" width="20%">
system peer association ID
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>tc</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>tc</code>
time constant and poll exponent (log(2) s) (3-17)
- <p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>mintc</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>mintc</code>
minimum time constant (log(2) s) (3-10)
- <p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>clock</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>clock</code>
</td><td valign="top" width="20%">
date and time of day
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>refid</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>refid</code>
reference ID or <a href="decode.html#kiss">kiss code</a>
- <p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>reftime</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>reftime</code>
</td><td valign="top" width="20%">
reference time
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>offset</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>offset</code>
</td><td valign="top" width="20%">
combined offset of server relative to this host
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>sys_jitter</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>sys_jitter</code>
</td><td valign="top" width="20%">
combined system jitter
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>frequency</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>frequency</code>
</td><td valign="top" width="20%">
frequency offset (PPM) relative to hardware clock
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>clk_wander</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>clk_wander</code>
</td><td valign="top" width="20%">
clock frequency wander (PPM)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>clk_jitter</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>clk_jitter</code>
</td><td valign="top" width="20%">
clock jitter
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>tai</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>tai</code>
</td><td valign="top" width="20%">
TAI-UTC offset (s)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>leapsec</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>leapsec</code>
</td><td valign="top" width="20%">
NTP seconds when the next leap second is/was inserted
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>expire</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>expire</code>
</td><td valign="top" width="20%">
NTP seconds when the NIST leapseconds file expires
- <br></td></tr></table>
+ <br></td></tr></table>
- <p>The jitter and wander statistics are exponentially-weighted RMS averages.
+
<p>The jitter and wander statistics are exponentially-weighted RMS averages.
The system jitter is defined in the NTPv4 specification;
the clock jitter statistic is computed by the clock discipline module.
- <p>When the NTPv4 daemon is compiled with the OpenSSL software library,
+
<p>When the NTPv4 daemon is compiled with the OpenSSL software library,
additional system variables are displayed, including some or all of the
following, depending on the particular Autokey dance:
- <p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
+
<p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
-<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>host</code>
+
<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>host</code>
</td><td valign="top" width="20%">
Autokey host name for this host
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>ident</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>ident</code>
</td><td valign="top" width="20%">
Autokey group name for this host
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>flags</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>flags</code>
</td><td valign="top" width="20%">
host flags (see Autokey specification)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>digest</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>digest</code>
</td><td valign="top" width="20%">
OpenSSL message digest algorithm
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>signature</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>signature</code>
</td><td valign="top" width="20%">
OpenSSL digest/signature scheme
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>update</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>update</code>
</td><td valign="top" width="20%">
NTP seconds at last signature update
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>cert</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>cert</code>
</td><td valign="top" width="20%">
certificate subject, issuer and certificate flags
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>until</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>until</code>
</td><td valign="top" width="20%">
NTP seconds when the certificate expires
- <br></td></tr></table>
+ <br></td></tr></table>
<div class="node">
-<a name="Peer-Variables"></a>
<p><hr>
-Next: <a rel="next" accesskey="n" href="#Clock-Variables">Clock Variables</a>,
+
<a name="Peer-Variables"></a>Next: <a rel="next" accesskey="n" href="#Clock-Variables">Clock Variables</a>,
Previous: <a rel="previous" accesskey="p" href="#System-Variables">System Variables</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-
+<br>
</div>
-<!-- node-name, next, previous, up -->
+ <!-- node-name, next, previous, up -->
<h3 class="section">Peer Variables</h3>
-<p>The following peer variables appear in the <code>rv</code> billboard
+
<p>The following peer variables appear in the <code>rv</code> billboard
for each association.
Not all variables are displayed in some configurations.
- <p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
+
<p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
-<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>associd</code>
+
<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>associd</code>
</td><td valign="top" width="20%">
association ID
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>status</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>status</code>
</td><td valign="top" width="20%">
<a href="decode.html#peer">peer status word</a>
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>srcadr</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>srcadr</code>
<br></td></tr><tr align="left"><td valign="top" width="10%"><code>srcport</code>
</td><td valign="top" width="20%">
source (remote) IP address and port
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>dstadr</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>dstadr</code>
<br></td></tr><tr align="left"><td valign="top" width="10%"><code>dstport</code>
</td><td valign="top" width="20%">
destination (local) IP address and port
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>leap</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>leap</code>
</td><td valign="top" width="20%">
leap indicator (0-3)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>stratum</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>stratum</code>
</td><td valign="top" width="20%">
stratum (0-15)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>precision</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>precision</code>
</td><td valign="top" width="20%">
precision (log(2) s)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rootdelay</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rootdelay</code>
</td><td valign="top" width="20%">
total roundtrip delay to the primary reference clock
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rootdisp</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>rootdisp</code>
</td><td valign="top" width="20%">total root dispersion to the primary reference clock
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>refid</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>refid</code>
</td><td valign="top" width="20%">
reference ID or <a href="decode.html#kiss">kiss code</a>
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>reftime</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>reftime</code>
</td><td valign="top" width="20%">
reference time
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>reach</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>reach</code>
</td><td valign="top" width="20%">
reach register (octal)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>unreach</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>unreach</code>
</td><td valign="top" width="20%">
unreach counter
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>hmode</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>hmode</code>
</td><td valign="top" width="20%">
host mode (1-6)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>pmode</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>pmode</code>
</td><td valign="top" width="20%">
peer mode (1-5)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>hpoll</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>hpoll</code>
</td><td valign="top" width="20%">
host poll exponent (log(2) s) (3-17)
<br></td></tr><tr align="left"><td valign="top" width="10%"><code>ppoll</code>
</td><td valign="top" width="20%">
peer poll exponent (log(2) s) (3-17)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>headway</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>headway</code>
</td><td valign="top" width="20%">
headway (see <a href="rate.html">Rate Management and the Kiss-o'-Death Packet</a>)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>flash</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>flash</code>
</td><td valign="top" width="20%">
<a href="decode.html#flash">flash status word</a>
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>offset</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>offset</code>
</td><td valign="top" width="20%">
filter offset
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>delay</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>delay</code>
</td><td valign="top" width="20%">
filter delay
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>dispersion</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>dispersion</code>
</td><td valign="top" width="20%">
filter dispersion
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>jitter</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>jitter</code>
</td><td valign="top" width="20%">
filter jitter
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>ident</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>ident</code>
</td><td valign="top" width="20%">
Autokey group name for this association
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>bias</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>bias</code>
</td><td valign="top" width="20%">
unicast/broadcast bias
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>xleave</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>xleave</code>
</td><td valign="top" width="20%">
interleave delay (see <a href="xleave.html">NTP Interleaved Modes</a>)
- <br></td></tr></table>
+ <br></td></tr></table>
- <p>The bias variable is calculated when the first broadcast packet is received
+
<p>The bias variable is calculated when the first broadcast packet is received
after the calibration volley. It represents the offset of the broadcast
subgraph relative to the unicast subgraph. The xleave variable appears
only the interleaved symmetric and interleaved modes. It represents
the internal queuing, buffering and transmission delays for the preceding
packet.
- <p>When the NTPv4 daemon is compiled with the OpenSSL software library,
+
<p>When the NTPv4 daemon is compiled with the OpenSSL software library,
additional peer variables are displayed, including the following:
- <p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
+
<p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
-<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>flags</code>
+
<p><br></th></tr><tr align="left"><td valign="top" width="10%"><code>flags</code>
</td><td valign="top" width="20%">
peer flags (see Autokey specification)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>host</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>host</code>
</td><td valign="top" width="20%">
Autokey server name
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>flags</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>flags</code>
</td><td valign="top" width="20%">
peer flags (see Autokey specification)
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>signature</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>signature</code>
</td><td valign="top" width="20%">
OpenSSL digest/signature scheme
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>initsequence</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>initsequence</code>
</td><td valign="top" width="20%">
initial key ID
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>initkey</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>initkey</code>
</td><td valign="top" width="20%">
initial key index
-<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>timestamp</code>
+
<p><br></td></tr><tr align="left"><td valign="top" width="10%"><code>timestamp</code>
</td><td valign="top" width="20%">
Autokey signature timestamp
- <br></td></tr></table>
+ <br></td></tr></table>
<div class="node">
-<a name="Clock-Variables"></a>
<p><hr>
-Previous: <a rel="previous" accesskey="p" href="#Peer-Variables">Peer Variables</a>,
+
<a name="Clock-Variables"></a>Previous: <a rel="previous" accesskey="p" href="#Peer-Variables">Peer Variables</a>,
Up: <a rel="up" accesskey="u" href="#Top">Top</a>
-
+<br>
</div>
-<!-- node-name, next, previous, up -->
+ <!-- node-name, next, previous, up -->
<h3 class="section">Clock Variables</h3>
-<p>The following clock variables appear in the <code>cv</code> billboard for each association with a reference clock. Not all variables are displayed in some configurations.
+
<p>The following clock variables appear in the <code>cv</code> billboard for each association with a reference clock. Not all variables are displayed in some configurations.
- <p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
+
<p><table summary=""><tr align="left"><th valign="top" width="10%">Variable </th><th valign="top" width="20%">Description
<br></th></tr><tr align="left"><td valign="top" width="10%"><code>associd</code>
</td><td valign="top" width="20%">association ID
<br></td></tr><tr align="left"><td valign="top" width="10%"><code>status</code>
</td><td valign="top" width="20%">driver reference ID
<br></td></tr><tr align="left"><td valign="top" width="10%"><code>flags</code>
</td><td valign="top" width="20%">driver flags
- <br></td></tr></table>
+ <br></td></tr></table>
- <p>===
- <p><h4>Synopsis</h4>
+
<p><h4>Synopsis</h4>
<code>ntpq [-inp] [-c </code><kbd>command</kbd><code>] [</code><kbd>host</kbd><code>] [...]</code>
- <p><p>Command line options are described following. Specifying a command line option other than <code>-i</code> or <code>-n</code> will cause the specified query (queries) to be sent to the indicated host(s) immediately. Otherwise, <code>ntpq</code> will attempt to read interactive format commands from the standard input.</p>
+
<p><p>Command line options are described following. Specifying a command line option other than <code>-i</code> or <code>-n</code> will cause the specified query (queries) to be sent to the indicated host(s) immediately. Otherwise, <code>ntpq</code> will attempt to read interactive format commands from the standard input.</p>
<dl>
<dt><code>-4</code></dt>
<dd>Force DNS resolution of following host names on the command line to the IPv4 namespace.</dd>
-.TH ntpq @NTPQ_MS@ "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH ntpq @NTPQ_MS@ "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpq-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:27 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:07 AM by AutoGen 5.16.2
.\" From the definitions ntpq-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTPQ @NTPQ_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpq-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:32 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:13 AM by AutoGen 5.16.2
.\" From the definitions ntpq-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
#
# EDIT THIS FILE WITH CAUTION (invoke-ntpsnmpd.texi)
#
-# It has been AutoGen-ed December 22, 2012 at 11:53:47 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 25, 2012 at 11:35:26 AM by AutoGen 5.16.2
# From the definitions ntpsnmpd-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-ntpsnmpd - NTP SNMP MIB agent - Ver. 4.2.7p337
+ntpsnmpd - NTP SNMP MIB agent - Ver. 4.2.7p338
USAGE: ntpsnmpd [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]...
Flg Arg Option-Name Description
-n no nofork Do not fork
/*
* EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.c)
*
- * It has been AutoGen-ed December 22, 2012 at 11:53:35 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:35:16 AM by AutoGen 5.16.2
* From the definitions ntpsnmpd-opts.def
* and the template file options
*
* ntpsnmpd option static const strings
*/
static char const ntpsnmpd_opt_strs[1561] =
-/* 0 */ "ntpsnmpd 4.2.7p337\n"
+/* 0 */ "ntpsnmpd 4.2.7p338\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 1360 */ "no-load-opts\0"
/* 1373 */ "no\0"
/* 1376 */ "NTPSNMPD\0"
-/* 1385 */ "ntpsnmpd - NTP SNMP MIB agent - Ver. 4.2.7p337\n"
+/* 1385 */ "ntpsnmpd - NTP SNMP MIB agent - Ver. 4.2.7p338\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]...\n\0"
/* 1490 */ "$HOME\0"
/* 1496 */ ".\0"
/* 1498 */ ".ntprc\0"
/* 1505 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 1539 */ "\n\n\0"
-/* 1542 */ "ntpsnmpd 4.2.7p337";
+/* 1542 */ "ntpsnmpd 4.2.7p338";
/*
* nofork option description:
/*
* EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.h)
*
- * It has been AutoGen-ed December 22, 2012 at 11:53:35 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:35:16 AM by AutoGen 5.16.2
* From the definitions ntpsnmpd-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 8
-#define NTPSNMPD_VERSION "4.2.7p337"
-#define NTPSNMPD_FULL_VERSION "ntpsnmpd 4.2.7p337"
+#define NTPSNMPD_VERSION "4.2.7p338"
+#define NTPSNMPD_FULL_VERSION "ntpsnmpd 4.2.7p338"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntpsnmpd 1ntpsnmpdman "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH ntpsnmpd 1ntpsnmpdman "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:44 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:22 AM by AutoGen 5.16.2
.\" From the definitions ntpsnmpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTPSNMPD 1ntpsnmpdmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:49 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:28 AM by AutoGen 5.16.2
.\" From the definitions ntpsnmpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
-.TH ntpsnmpd @NTPSNMPD_MS@ "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH ntpsnmpd @NTPSNMPD_MS@ "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:44 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:22 AM by AutoGen 5.16.2
.\" From the definitions ntpsnmpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTPSNMPD @NTPSNMPD_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpsnmpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:53:49 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:28 AM by AutoGen 5.16.2
.\" From the definitions ntpsnmpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
# - Numeric values increment
# - empty 'increments' to 1
# - NEW 'increments' to empty
-point=337
+point=338
### betapoint is normally modified by script.
# ntp-stable Beta number (betapoint)
#
# EDIT THIS FILE WITH CAUTION (invoke-ntp-wait.texi)
#
-# It has been AutoGen-ed December 22, 2012 at 11:45:37 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 25, 2012 at 11:30:28 AM by AutoGen 5.16.2
# From the definitions ntp-wait-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@code{ntp-wait}
will send at most
-@kbd{num-tries} queries to
+@code{num-tries} queries to
@code{ntpd(8)},
sleeping for
-@kbd{secs-between-tries} after each status return that says
+@code{secs-between-tries} after each status return that says
@code{ntpd(8)}
has not yet produced a synchronized and stable system clock.
-.TH ntp-wait 1ntp-waitman "22 Dec 2012" "ntp (4.2.7p337)" "User Commands"
+.TH ntp-wait 1ntp-waitman "25 Dec 2012" "ntp (4.2.7p338)" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp-wait-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:45:34 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:30:24 AM by AutoGen 5.16.2
.\" From the definitions ntp-wait-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTP_WAIT 1ntp-waitmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp-wait-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:45:40 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:30:30 AM by AutoGen 5.16.2
.\" From the definitions ntp-wait-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
and only then start any applicaitons (like database servers) that require
accurate and stable time.
- <p>This document applies to version 4.2.7p337 of <code>ntp-wait</code>.
+ <p>This document applies to version 4.2.7p338 of <code>ntp-wait</code>.
<div class="shortcontents">
<h2>Short Contents</h2>
<p><code>ntp-wait</code>
will send at most
-<kbd>num-tries</kbd> queries to
+<code>num-tries</code> queries to
<code>ntpd(8)</code>,
sleeping for
-<kbd>secs-between-tries</kbd> after each status return that says
+<code>secs-between-tries</code> after each status return that says
<code>ntpd(8)</code>
has not yet produced a synchronized and stable system clock.
-.TH ntp-wait @NTP_WAIT_MS@ "22 Dec 2012" "ntp (4.2.7p337)" "User Commands"
+.TH ntp-wait @NTP_WAIT_MS@ "25 Dec 2012" "ntp (4.2.7p338)" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp-wait-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:45:34 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:30:24 AM by AutoGen 5.16.2
.\" From the definitions ntp-wait-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt NTP_WAIT @NTP_WAIT_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp-wait-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:45:40 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:30:30 AM by AutoGen 5.16.2
.\" From the definitions ntp-wait-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
#
# EDIT THIS FILE WITH CAUTION (invoke-sntp.texi)
#
-# It has been AutoGen-ed December 22, 2012 at 11:54:27 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 25, 2012 at 11:36:08 AM by AutoGen 5.16.2
# From the definitions sntp-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p337
+sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p338
USAGE: sntp [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]... \
[ hostname-or-IP ...]
Flg Arg Option-Name Description
/*
* EDIT THIS FILE WITH CAUTION (sntp-opts.c)
*
- * It has been AutoGen-ed December 22, 2012 at 11:42:53 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:26:58 AM by AutoGen 5.16.2
* From the definitions sntp-opts.def
* and the template file options
*
* sntp option static const strings
*/
static char const sntp_opt_strs[2500] =
-/* 0 */ "sntp 4.2.7p337\n"
+/* 0 */ "sntp 4.2.7p338\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 2244 */ "LOAD_OPTS\0"
/* 2254 */ "no-load-opts\0"
/* 2267 */ "SNTP\0"
-/* 2272 */ "sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p337\n"
+/* 2272 */ "sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p338\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \\\n"
"\t\t[ hostname-or-IP ...]\n\0"
/* 2433 */ "$HOME\0"
/* 2441 */ ".ntprc\0"
/* 2448 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 2482 */ "\n\n\0"
-/* 2485 */ "sntp 4.2.7p337";
+/* 2485 */ "sntp 4.2.7p338";
/*
* ipv4 option description with
/*
* EDIT THIS FILE WITH CAUTION (sntp-opts.h)
*
- * It has been AutoGen-ed December 22, 2012 at 11:42:52 AM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:26:57 AM by AutoGen 5.16.2
* From the definitions sntp-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 23
-#define SNTP_VERSION "4.2.7p337"
-#define SNTP_FULL_VERSION "sntp 4.2.7p337"
+#define SNTP_VERSION "4.2.7p338"
+#define SNTP_FULL_VERSION "sntp 4.2.7p338"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH sntp 1sntpman "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH sntp 1sntpman "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (sntp-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:54:23 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:36:03 AM by AutoGen 5.16.2
.\" From the definitions sntp-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt SNTP 1sntpmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (sntp-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:54:29 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:36:10 AM by AutoGen 5.16.2
.\" From the definitions sntp-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
clock. Run as root, it can correct the system clock to this offset as
well. It can be run as an interactive command or from a cron job.
- <p>This document applies to version 4.2.7p337 of <code>sntp</code>.
+ <p>This document applies to version 4.2.7p338 of <code>sntp</code>.
<p>The program implements the SNTP protocol as defined by RFC 5905, the NTPv4
IETF specification.
used to select the program, defaulting to <span class="file">more</span>. Both will exit
with a status code of 0.
-<pre class="example">sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p337
+<pre class="example">sntp - standard Simple Network Time Protocol client program - Ver. 4.2.7p338
USAGE: sntp [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \
[ hostname-or-IP ...]
Flg Arg Option-Name Description
-.TH sntp @SNTP_MS@ "22 Dec 2012" "4.2.7p337" "User Commands"
+.TH sntp @SNTP_MS@ "25 Dec 2012" "4.2.7p338" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (sntp-opts.man)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:54:23 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:36:03 AM by AutoGen 5.16.2
.\" From the definitions sntp-opts.def
.\" and the template file agman-cmd.tpl
.\"
-.Dd December 22 2012
+.Dd December 25 2012
.Dt SNTP @SNTP_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (sntp-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 22, 2012 at 11:54:29 AM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:36:10 AM by AutoGen 5.16.2
.\" From the definitions sntp-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
#
# EDIT THIS FILE WITH CAUTION (invoke-ntp-keygen.texi)
#
-# It has been AutoGen-ed December 25, 2012 at 01:50:28 AM by AutoGen 5.16.2
+# It has been AutoGen-ed December 25, 2012 at 11:35:45 AM by AutoGen 5.16.2
# From the definitions ntp-keygen-opts.def
# and the template file agtexi-cmd.tpl
@end ignore
@exampleindent 0
@example
-ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p337
+ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p338
USAGE: ntp-keygen [ -<flag> [<val>] | --<name>[@{=| @}<val>] ]...
Flg Arg Option-Name Description
-b Num imbits identity modulus bits
/*
* EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.c)
*
- * It has been AutoGen-ed December 24, 2012 at 12:08:08 PM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:35:32 AM by AutoGen 5.16.2
* From the definitions ntp-keygen-opts.def
* and the template file options
*
* ntp-keygen option static const strings
*/
static char const ntp_keygen_opt_strs[2358] =
-/* 0 */ "ntp-keygen (ntp) 4.2.7p337\n"
+/* 0 */ "ntp-keygen (ntp) 4.2.7p338\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"redistribution under the terms of the NTP License, copies of which\n"
/* 2136 */ "no-load-opts\0"
/* 2149 */ "no\0"
/* 2152 */ "NTP_KEYGEN\0"
-/* 2163 */ "ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p337\n"
+/* 2163 */ "ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p338\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]...\n\0"
/* 2279 */ "$HOME\0"
/* 2285 */ ".\0"
/* 2287 */ ".ntprc\0"
/* 2294 */ "http://bugs.ntp.org, bugs@ntp.org\0"
/* 2328 */ "\n\n\0"
-/* 2331 */ "ntp-keygen (ntp) 4.2.7p337";
+/* 2331 */ "ntp-keygen (ntp) 4.2.7p338";
/*
* imbits option description:
/*
* EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.h)
*
- * It has been AutoGen-ed December 24, 2012 at 12:08:08 PM by AutoGen 5.16.2
+ * It has been AutoGen-ed December 25, 2012 at 11:35:32 AM by AutoGen 5.16.2
* From the definitions ntp-keygen-opts.def
* and the template file options
*
} teOptIndex;
#define OPTION_CT 26
-#define NTP_KEYGEN_VERSION "4.2.7p337"
-#define NTP_KEYGEN_FULL_VERSION "ntp-keygen (ntp) 4.2.7p337"
+#define NTP_KEYGEN_VERSION "4.2.7p338"
+#define NTP_KEYGEN_FULL_VERSION "ntp-keygen (ntp) 4.2.7p338"
/*
* Interface defines for all options. Replace "n" with the UPPER_CASED
-.TH ntp-keygen 1ntp-keygenman "24 Dec 2012" "ntp (4.2.7p337)" "User Commands"
+.TH ntp-keygen 1ntp-keygenman "25 Dec 2012" "ntp (4.2.7p338)" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.man)
.\"
-.\" It has been AutoGen-ed December 24, 2012 at 12:08:20 PM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:40 AM by AutoGen 5.16.2
.\" From the definitions ntp-keygen-opts.def
.\" and the template file agman-cmd.tpl
.\"
All arguments must be options.
.PP
.SH DESCRIPTION
-This program generates cryptographic data files used by the NTPv4
-authentication and identification schemes.
-It generates MD5 key files used in symmetric key cryptography.
-In addition, if the OpenSSL software library has been installed,
-it generates keys, certificate and identity files used in public key
-cryptography.
-These files are used for cookie encryption,
-digital signature and challenge/response identification algorithms
-compatible with the Internet standard security infrastructure.
-.PP
-All files are in PEM-encoded printable ASCII format,
-so they can be embedded as MIME attachments in mail to other sites
-and certificate authorities.
-By default, files are not encrypted.
-.PP
-When used to generate message digest keys, the program produces a file
-containing ten pseudo-random printable ASCII strings suitable for the
-MD5 message digest algorithm included in the distribution.
-If the OpenSSL library is installed, it produces an additional ten
-hex-encoded random bit strings suitable for the SHA1 and other message
-digest algorithms.
-The message digest keys file must be distributed and stored
-using secure means beyond the scope of NTP itself.
-Besides the keys used for ordinary NTP associations, additional keys
-can be defined as passwords for the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-utility programs.
-.PP
-The remaining generated files are compatible with other OpenSSL
-applications and other Public Key Infrastructure (PKI) resources.
-Certificates generated by this program are compatible with extant
-industry practice, although some users might find the interpretation of
-X509v3 extension fields somewhat liberal.
-However, the identity keys are probably not compatible with anything
-other than Autokey.
-.PP
-Some files used by this program are encrypted using a private password.
-The
-p
-option specifies the password for local encrypted files and the
-q
-option the password for encrypted files sent to remote sites.
-If no password is specified, the host name returned by the Unix
-.Fn gethostname
-function, normally the DNS name of the host is used.
-.PP
-The
-\fIpw\fR
-option of the
-\fIcrypto\fR
-configuration command specifies the read
-password for previously encrypted local files.
-This must match the local password used by this program.
-If not specified, the host name is used.
-Thus, if files are generated by this program without password,
-they can be read back by
-\fIntpd\fR
-without password but only on the same host.
-.PP
-Normally, encrypted files for each host are generated by that host and
-used only by that host, although exceptions exist as noted later on
-this page.
-The symmetric keys file, normally called
-\fIntp.keys ,\fR
-is usually installed in
-.Pa /etc .
-Other files and links are usually installed in
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem in
-NFS-mounted networks and cannot be changed by shared clients.
-The location of the keys directory can be changed by the
-\fIkeysdir\fR
-configuration command in such cases.
-Normally, this is in
-.Pa /etc .
-.PP
-This program directs commentary and error messages to the standard
-error stream
-\fIstderr\fR
-and remote files to the standard output stream
-\fIstdout\fR
-where they can be piped to other applications or redirected to files.
-The names used for generated files and links all begin with the
-string
-\fIntpkey\fR
-and include the file type, generating host and filestamp,
-as described in the
-.Dq Cryptographic Data Files
-section below.
-.SS Running the Program
-To test and gain experience with Autokey concepts, log in as root and
-change to the keys directory, usually
-.Pa /usr/local/etc
-When run for the first time, or if all files with names beginning with
-\fIntpkey\fR
-have been removed, use the
-.B
-command without arguments to generate a
-default RSA host key and matching RSA-MD5 certificate with expiration
-date one year hence.
-If run again without options, the program uses the
-existing keys and parameters and generates only a new certificate with
-new expiration date one year hence.
-.PP
-Run the command on as many hosts as necessary.
-Designate one of them as the trusted host (TH) using
-.B
-with the
-T
-option and configure it to synchronize from reliable Internet servers.
-Then configure the other hosts to synchronize to the TH directly or
-indirectly.
-A certificate trail is created when Autokey asks the immediately
-ascendant host towards the TH to sign its certificate, which is then
-provided to the immediately descendant host on request.
-All group hosts should have acyclic certificate trails ending on the TH.
-.PP
-The host key is used to encrypt the cookie when required and so must be
-RSA type.
-By default, the host key is also the sign key used to encrypt
-signatures.
-A different sign key can be assigned using the
-S
-option and this can be either RSA or DSA type.
-By default, the signature
-message digest type is MD5, but any combination of sign key type and
-message digest type supported by the OpenSSL library can be specified
-using the
-c
-option.
-The rules say cryptographic media should be generated with proventic
-filestamps, which means the host should already be synchronized before
-this program is run.
-This of course creates a chicken-and-egg problem
-when the host is started for the first time.
-Accordingly, the host time
-should be set by some other means, such as eyeball-and-wristwatch, at
-least so that the certificate lifetime is within the current year.
-After that and when the host is synchronized to a proventic source, the
-certificate should be re-generated.
-.PP
-Additional information on trusted groups and identity schemes is on the
-.Dq Autokey Public-Key Authentication
-page.
-.PP
-The
-.Xr ntpd 1ntpdmdoc
-configuration command
-.Ic crypto pw Ar password
-specifies the read password for previously encrypted files.
-The daemon expires on the spot if the password is missing
-or incorrect.
-For convenience, if a file has been previously encrypted,
-the default read password is the name of the host running
-the program.
-If the previous write password is specified as the host name,
-these files can be read by that host with no explicit password.
-.PP
-File names begin with the prefix
-.Cm ntpkey_
-and end with the postfix
-\fI_hostname.filestamp ,\fR
-where
-\fIhostname\fR
-is the owner name, usually the string returned
-by the Unix gethostname() routine, and
-\fIfilestamp\fR
-is the NTP seconds when the file was generated, in decimal digits.
-This both guarantees uniqueness and simplifies maintenance
-procedures, since all files can be quickly removed
-by a
-.Ic rm ntpkey\&*
-command or all files generated
-at a specific time can be removed by a
-.Ic rm
-\fI\&*filestamp\fR
-command.
-To further reduce the risk of misconfiguration,
-the first two lines of a file contain the file name
-and generation date and time as comments.
-.PP
-All files are installed by default in the keys directory
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem
-in NFS-mounted networks.
-The actual location of the keys directory
-and each file can be overridden by configuration commands,
-but this is not recommended.
-Normally, the files for each host are generated by that host
-and used only by that host, although exceptions exist
-as noted later on this page.
-.PP
-Normally, files containing private values,
-including the host key, sign key and identification parameters,
-are permitted root read/write-only;
-while others containing public values are permitted world readable.
-Alternatively, files containing private values can be encrypted
-and these files permitted world readable,
-which simplifies maintenance in shared file systems.
-Since uniqueness is insured by the hostname and
-file name extensions, the files for a NFS server and
-dependent clients can all be installed in the same shared directory.
-.PP
-The recommended practice is to keep the file name extensions
-when installing a file and to install a soft link
-from the generic names specified elsewhere on this page
-to the generated files.
-This allows new file generations to be activated simply
-by changing the link.
-If a link is present, ntpd follows it to the file name
-to extract the filestamp.
-If a link is not present,
-.Xr ntpd 1ntpdmdoc
-extracts the filestamp from the file itself.
-This allows clients to verify that the file and generation times
-are always current.
-The
-.B
-program uses the same timestamp extension for all files generated
-at one time, so each generation is distinct and can be readily
-recognized in monitoring data.
-.SS Running the program
-The safest way to run the
-.B
-program is logged in directly as root.
-The recommended procedure is change to the keys directory,
-usually
-.Pa /usr/local/etc ,
-then run the program.
-When run for the first time,
-or if all
-.Cm ntpkey
-files have been removed,
-the program generates a RSA host key file and matching RSA-MD5 certificate file,
-which is all that is necessary in many cases.
-The program also generates soft links from the generic names
-to the respective files.
-If run again, the program uses the same host key file,
-but generates a new certificate file and link.
-.PP
-The host key is used to encrypt the cookie when required and so must be RSA type.
-By default, the host key is also the sign key used to encrypt signatures.
-When necessary, a different sign key can be specified and this can be
-either RSA or DSA type.
-By default, the message digest type is MD5, but any combination
-of sign key type and message digest type supported by the OpenSSL library
-can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
-and RIPE160 message digest algorithms.
-However, the scheme specified in the certificate must be compatible
-with the sign key.
-Certificates using any digest algorithm are compatible with RSA sign keys;
-however, only SHA and SHA1 certificates are compatible with DSA sign keys.
-.PP
-Private/public key files and certificates are compatible with
-other OpenSSL applications and very likely other libraries as well.
-Certificates or certificate requests derived from them should be compatible
-with extant industry practice, although some users might find
-the interpretation of X509v3 extension fields somewhat liberal.
-However, the identification parameter files, although encoded
-as the other files, are probably not compatible with anything other than Autokey.
-.PP
-Running the program as other than root and using the Unix
-.Ic su
-command
-to assume root may not work properly, since by default the OpenSSL library
-looks for the random seed file
-.Cm .rnd
-in the user home directory.
-However, there should be only one
-.Cm .rnd ,
-most conveniently
-in the root directory, so it is convenient to define the
-.Cm $RANDFILE
-environment variable used by the OpenSSL library as the path to
-.Cm /.rnd .
-.PP
-Installing the keys as root might not work in NFS-mounted
-shared file systems, as NFS clients may not be able to write
-to the shared keys directory, even as root.
-In this case, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-command.
-There is no need for one client to read the keys and certificates
-of other clients or servers, as these data are obtained automatically
-by the Autokey protocol.
-.PP
-Ordinarily, cryptographic files are generated by the host that uses them,
-but it is possible for a trusted agent (TA) to generate these files
-for other hosts; however, in such cases files should always be encrypted.
-The subject name and trusted name default to the hostname
-of the host generating the files, but can be changed by command line options.
-It is convenient to designate the owner name and trusted name
-as the subject and issuer fields, respectively, of the certificate.
-The owner name is also used for the host and sign key files,
-while the trusted name is used for the identity files.
-.PP
-All files are installed by default in the keys directory
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem
-in NFS-mounted networks.
-The actual location of the keys directory
-and each file can be overridden by configuration commands,
-but this is not recommended.
-Normally, the files for each host are generated by that host
-and used only by that host, although exceptions exist
-as noted later on this page.
-.PP
-Normally, files containing private values,
-including the host key, sign key and identification parameters,
-are permitted root read/write-only;
-while others containing public values are permitted world readable.
-Alternatively, files containing private values can be encrypted
-and these files permitted world readable,
-which simplifies maintenance in shared file systems.
-Since uniqueness is insured by the hostname and
-file name extensions, the files for a NFS server and
-dependent clients can all be installed in the same shared directory.
-.PP
-The recommended practice is to keep the file name extensions
-when installing a file and to install a soft link
-from the generic names specified elsewhere on this page
-to the generated files.
-This allows new file generations to be activated simply
-by changing the link.
-If a link is present, ntpd follows it to the file name
-to extract the filestamp.
-If a link is not present,
-.Xr ntpd 1ntpdmdoc
-extracts the filestamp from the file itself.
-This allows clients to verify that the file and generation times
-are always current.
-The
-.B
-program uses the same timestamp extension for all files generated
-at one time, so each generation is distinct and can be readily
-recognized in monitoring data.
-.SS Running the program
-The safest way to run the
-.B
-program is logged in directly as root.
-The recommended procedure is change to the keys directory,
-usually
-.Pa /usr/local/etc ,
-then run the program.
-When run for the first time,
-or if all
-.Cm ntpkey
-files have been removed,
-the program generates a RSA host key file and matching RSA-MD5 certificate file,
-which is all that is necessary in many cases.
-The program also generates soft links from the generic names
-to the respective files.
-If run again, the program uses the same host key file,
-but generates a new certificate file and link.
-.PP
-The host key is used to encrypt the cookie when required and so must be RSA type.
-By default, the host key is also the sign key used to encrypt signatures.
-When necessary, a different sign key can be specified and this can be
-either RSA or DSA type.
-By default, the message digest type is MD5, but any combination
-of sign key type and message digest type supported by the OpenSSL library
-can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
-and RIPE160 message digest algorithms.
-However, the scheme specified in the certificate must be compatible
-with the sign key.
-Certificates using any digest algorithm are compatible with RSA sign keys;
-however, only SHA and SHA1 certificates are compatible with DSA sign keys.
-.PP
-Private/public key files and certificates are compatible with
-other OpenSSL applications and very likely other libraries as well.
-Certificates or certificate requests derived from them should be compatible
-with extant industry practice, although some users might find
-the interpretation of X509v3 extension fields somewhat liberal.
-However, the identification parameter files, although encoded
-as the other files, are probably not compatible with anything other than Autokey.
-.PP
-Running the program as other than root and using the Unix
-.Ic su
-command
-to assume root may not work properly, since by default the OpenSSL library
-looks for the random seed file
-.Cm .rnd
-in the user home directory.
-However, there should be only one
-.Cm .rnd ,
-most conveniently
-in the root directory, so it is convenient to define the
-.Cm $RANDFILE
-environment variable used by the OpenSSL library as the path to
-.Cm /.rnd .
-.PP
-Installing the keys as root might not work in NFS-mounted
-shared file systems, as NFS clients may not be able to write
-to the shared keys directory, even as root.
-In this case, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-command.
-There is no need for one client to read the keys and certificates
-of other clients or servers, as these data are obtained automatically
-by the Autokey protocol.
-.PP
-Ordinarily, cryptographic files are generated by the host that uses them,
-but it is possible for a trusted agent (TA) to generate these files
-for other hosts; however, in such cases files should always be encrypted.
-The subject name and trusted name default to the hostname
-of the host generating the files, but can be changed by command line options.
-It is convenient to designate the owner name and trusted name
-as the subject and issuer fields, respectively, of the certificate.
-The owner name is also used for the host and sign key files,
-while the trusted name is used for the identity files.
-seconds.
-seconds.
-s Trusted Hosts and Groups
-Each cryptographic configuration involves selection of a signature scheme
-and identification scheme, called a cryptotype,
-as explained in the
-.Sx Authentication Options
-section of
-.Xr ntp.conf 5 .
-The default cryptotype uses RSA encryption, MD5 message digest
-and TC identification.
-First, configure a NTP subnet including one or more low-stratum
-trusted hosts from which all other hosts derive synchronization
-directly or indirectly.
-Trusted hosts have trusted certificates;
-all other hosts have nontrusted certificates.
-These hosts will automatically and dynamically build authoritative
-certificate trails to one or more trusted hosts.
-A trusted group is the set of all hosts that have, directly or indirectly,
-a certificate trail ending at a trusted host.
-The trail is defined by static configuration file entries
-or dynamic means described on the
-.Sx Automatic NTP Configuration Options
-section of
-.Xr ntp.conf 5 .
-.PP
-On each trusted host as root, change to the keys directory.
-To insure a fresh fileset, remove all
-.Cm ntpkey
-files.
-Then run
-.B
-T
-to generate keys and a trusted certificate.
-On all other hosts do the same, but leave off the
-T
-flag to generate keys and nontrusted certificates.
-When complete, start the NTP daemons beginning at the lowest stratum
-and working up the tree.
-It may take some time for Autokey to instantiate the certificate trails
-throughout the subnet, but setting up the environment is completely automatic.
-.PP
-If it is necessary to use a different sign key or different digest/signature
-scheme than the default, run
-.B
-with the
-S Ar type
-option, where
-\fItype\fR
-is either
-.Cm RSA
-or
-.Cm DSA .
-The most often need to do this is when a DSA-signed certificate is used.
-If it is necessary to use a different certificate scheme than the default,
-run
-.B
-with the
-c Ar scheme
-option and selected
-\fIscheme\fR
-as needed.
-f
-.B
-is run again without these options, it generates a new certificate
-using the same scheme and sign key.
-.PP
-After setting up the environment it is advisable to update certificates
-from time to time, if only to extend the validity interval.
-Simply run
-.B
-with the same flags as before to generate new certificates
-using existing keys.
-However, if the host or sign key is changed,
-.Xr ntpd 1ntpdmdoc
-should be restarted.
-When
-.Xr ntpd 1ntpdmdoc
-is restarted, it loads any new files and restarts the protocol.
-Other dependent hosts will continue as usual until signatures are refreshed,
-at which time the protocol is restarted.
-.SS Identity Schemes
-As mentioned on the Autonomous Authentication page,
-the default TC identity scheme is vulnerable to a middleman attack.
-However, there are more secure identity schemes available,
-including PC, IFF, GQ and MV described on the
-.Qq Identification Schemes
-page
-(maybe available at
-.Li http://www.eecis.udel.edu/%7emills/keygen.html ) .
-These schemes are based on a TA, one or more trusted hosts
-and some number of nontrusted hosts.
-Trusted hosts prove identity using values provided by the TA,
-while the remaining hosts prove identity using values provided
-by a trusted host and certificate trails that end on that host.
-The name of a trusted host is also the name of its sugroup
-and also the subject and issuer name on its trusted certificate.
-The TA is not necessarily a trusted host in this sense, but often is.
-.PP
-In some schemes there are separate keys for servers and clients.
-A server can also be a client of another server,
-but a client can never be a server for another client.
-In general, trusted hosts and nontrusted hosts that operate
-as both server and client have parameter files that contain
-both server and client keys.
-Hosts that operate
-only as clients have key files that contain only client keys.
-.PP
-The PC scheme supports only one trusted host in the group.
-On trusted host alice run
-.B
-P
-p Ar password
-to generate the host key file
-.Pa ntpkey_RSAkey_ Ns Ar alice.filestamp
-and trusted private certificate file
-.Pa ntpkey_RSA-MD5_cert_ Ns Ar alice.filestamp .
-Copy both files to all group hosts;
-they replace the files which would be generated in other schemes.
-On each host bob install a soft link from the generic name
-.Pa ntpkey_host_ Ns Ar bob
-to the host key file and soft link
-.Pa ntpkey_cert_ Ns Ar bob
-to the private certificate file.
-Note the generic links are on bob, but point to files generated
-by trusted host alice.
-In this scheme it is not possible to refresh
-either the keys or certificates without copying them
-to all other hosts in the group.
-.PP
-For the IFF scheme proceed as in the TC scheme to generate keys
-and certificates for all group hosts, then for every trusted host in the group,
-generate the IFF parameter file.
-On trusted host alice run
-.B
-T
-I
-p Ar password
-to produce her parameter file
-.Pa ntpkey_IFFpar_ Ns Ar alice.filestamp ,
-which includes both server and client keys.
-Copy this file to all group hosts that operate as both servers
-and clients and install a soft link from the generic
-.Pa ntpkey_iff_ Ns Ar alice
-to this file.
-If there are no hosts restricted to operate only as clients,
-there is nothing further to do.
-As the IFF scheme is independent
-of keys and certificates, these files can be refreshed as needed.
-.PP
-If a rogue client has the parameter file, it could masquerade
-as a legitimate server and present a middleman threat.
-To eliminate this threat, the client keys can be extracted
-from the parameter file and distributed to all restricted clients.
-After generating the parameter file, on alice run
-.B
-e
-and pipe the output to a file or mail program.
-Copy or mail this file to all restricted clients.
-On these clients install a soft link from the generic
-.Pa ntpkey_iff_ Ns Ar alice
-to this file.
-To further protect the integrity of the keys,
-each file can be encrypted with a secret password.
-.PP
-For the GQ scheme proceed as in the TC scheme to generate keys
-and certificates for all group hosts, then for every trusted host
-in the group, generate the IFF parameter file.
-On trusted host alice run
-.B
-T
-G
-p Ar password
-to produce her parameter file
-.Pa ntpkey_GQpar_ Ns Ar alice.filestamp ,
-which includes both server and client keys.
-Copy this file to all group hosts and install a soft link
-from the generic
-.Pa ntpkey_gq_ Ns Ar alice
-to this file.
-In addition, on each host bob install a soft link
-from generic
-.Pa ntpkey_gq_ Ns Ar bob
-to this file.
-As the GQ scheme updates the GQ parameters file and certificate
-at the same time, keys and certificates can be regenerated as needed.
-.PP
-For the MV scheme, proceed as in the TC scheme to generate keys
-and certificates for all group hosts.
-For illustration assume trish is the TA, alice one of several trusted hosts
-and bob one of her clients.
-On TA trish run
-.B
-V Ar n
-p Ar password ,
-where
-\fIn\fR
-is the number of revokable keys (typically 5) to produce
-the parameter file
-.Pa ntpkeys_MVpar_ Ns Ar trish.filestamp
-and client key files
-.Pa ntpkeys_MVkeyd_ Ns Ar trish.filestamp
-where
-\fId\fR
-is the key number (0 \&<
-\fId\fR
-\&<
-\fIn ) .\fR
-Copy the parameter file to alice and install a soft link
-from the generic
-.Pa ntpkey_mv_ Ns Ar alice
-to this file.
-Copy one of the client key files to alice for later distribution
-to her clients.
-It doesn't matter which client key file goes to alice,
-since they all work the same way.
-Alice copies the client key file to all of her cliens.
-On client bob install a soft link from generic
-.Pa ntpkey_mvkey_ Ns Ar bob
-to the client key file.
-As the MV scheme is independent of keys and certificates,
-these files can be refreshed as needed.
-.SS Command Line Options
-.TP
-.BR Fl c Ar scheme
-Select certificate message digest/signature encryption scheme.
-The
-\fIscheme\fR
-can be one of the following:
-. Cm RSA-MD2 , RSA-MD5 , RSA-SHA , RSA-SHA1 , RSA-MDC2 , RSA-RIPEMD160 , DSA-SHA ,
-or
-.Cm DSA-SHA1 .
-Note that RSA schemes must be used with a RSA sign key and DSA
-schemes must be used with a DSA sign key.
-The default without this option is
-.Cm RSA-MD5 .
-.TP
-.BR Fl d
-Enable debugging.
-This option displays the cryptographic data produced in eye-friendly billboards.
-.TP
-.BR Fl e
-Write the IFF client keys to the standard output.
-This is intended for automatic key distribution by mail.
-.TP
-.BR Fl G
-Generate parameters and keys for the GQ identification scheme,
-obsoleting any that may exist.
-.TP
-.BR Fl g
-Generate keys for the GQ identification scheme
-using the existing GQ parameters.
-If the GQ parameters do not yet exist, create them first.
-.TP
-.BR Fl H
-Generate new host keys, obsoleting any that may exist.
-.TP
-.BR Fl I
-Generate parameters for the IFF identification scheme,
-obsoleting any that may exist.
-.TP
-.BR Fl i Ar name
-Set the suject name to
-\fIname .\fR
-This is used as the subject field in certificates
-and in the file name for host and sign keys.
-.TP
-.BR Fl M
-Generate MD5 keys, obsoleting any that may exist.
-.TP
-.BR Fl P
-Generate a private certificate.
-By default, the program generates public certificates.
-.TP
-.BR Fl p Ar password
-Encrypt generated files containing private data with
-\fIpassword\fR
-and the DES-CBC algorithm.
-.TP
-.BR Fl q
-Set the password for reading files to password.
-.TP
-.BR Fl S Oo Cm RSA | DSA Oc
-Generate a new sign key of the designated type,
-obsoleting any that may exist.
-By default, the program uses the host key as the sign key.
-.TP
-.BR Fl s Ar name
-Set the issuer name to
-\fIname .\fR
-This is used for the issuer field in certificates
-and in the file name for identity files.
-.TP
-.BR Fl T
-Generate a trusted certificate.
-By default, the program generates a non-trusted certificate.
-.TP
-.BR Fl V Ar nkeys
-Generate parameters and keys for the Mu-Varadharajan (MV) identification scheme.
-.SS Random Seed File
-All cryptographically sound key generation schemes must have means
-to randomize the entropy seed used to initialize
-the internal pseudo-random number generator used
-by the library routines.
-The OpenSSL library uses a designated random seed file for this purpose.
-The file must be available when starting the NTP daemon and
-.B
-program.
-If a site supports OpenSSL or its companion OpenSSH,
-it is very likely that means to do this are already available.
-.PP
-It is important to understand that entropy must be evolved
-for each generation, for otherwise the random number sequence
-would be predictable.
-Various means dependent on external events, such as keystroke intervals,
-can be used to do this and some systems have built-in entropy sources.
-Suitable means are described in the OpenSSL software documentation,
-but are outside the scope of this page.
-.PP
-The entropy seed used by the OpenSSL library is contained in a file,
-usually called
-.Cm .rnd ,
-which must be available when starting the NTP daemon
-or the
-.B
-program.
-The NTP daemon will first look for the file
-using the path specified by the
-.Ic randfile
-subcommand of the
-.Ic crypto
-configuration command.
-If not specified in this way, or when starting the
-.B
-program,
-the OpenSSL library will look for the file using the path specified
-by the
-.Ev RANDFILE
-environment variable in the user home directory,
-whether root or some other user.
-If the
-.Ev RANDFILE
-environment variable is not present,
-the library will look for the
-.Cm .rnd
-file in the user home directory.
-If the file is not available or cannot be written,
-the daemon exits with a message to the system log and the program
-exits with a suitable error message.
-.SS Cryptographic Data Files
-All other file formats begin with two lines.
-The first contains the file name, including the generated host name
-and filestamp.
-The second contains the datestamp in conventional Unix date format.
-Lines beginning with # are considered comments and ignored by the
-.B
-program and
-.Xr ntpd 1ntpdmdoc
-daemon.
-Cryptographic values are encoded first using ASN.1 rules,
-then encrypted if necessary, and finally written PEM-encoded
-printable ASCII format preceded and followed by MIME content identifier lines.
-.PP
-The format of the symmetric keys file is somewhat different
-than the other files in the interest of backward compatibility.
-Since DES-CBC is deprecated in NTPv4, the only key format of interest
-is MD5 alphanumeric strings.
-Following hte heard the keys are
-entered one per line in the format
-.D1 Ar keyno type key
-where
-\fIkeyno\fR
-is a positive integer in the range 1-65,535,
-\fItype\fR
-is the string MD5 defining the key format and
-\fIkey\fR
-is the key itself,
-which is a printable ASCII string 16 characters or less in length.
-Each character is chosen from the 93 printable characters
-in the range 0x21 through 0x7f excluding space and the
-.Ql #
-character.
-.PP
-Note that the keys used by the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-programs
-are checked against passwords requested by the programs
-and entered by hand, so it is generally appropriate to specify these keys
-in human readable ASCII format.
-.PP
-The
-.B
-program generates a MD5 symmetric keys file
-.Pa ntpkey_MD5key_ Ns Ar hostname.filestamp .
-Since the file contains private shared keys,
-it should be visible only to root and distributed by secure means
-to other subnet hosts.
-The NTP daemon loads the file
-.Pa ntp.keys ,
-so
-.B
-installs a soft link from this name to the generated file.
-Subsequently, similar soft links must be installed by manual
-or automated means on the other subnet hosts.
-While this file is not used with the Autokey Version 2 protocol,
-it is needed to authenticate some remote configuration commands
-used by the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-utilities.
.SH "OPTIONS"
.TP
.BR \-b " \fIimbits\fP, " \-\-imbits "=" \fIimbits\fP
If any of these are directories, then the file \fI.ntprc\fP
is searched for within those directories.
.SH USAGE
-The
-p Ar password
-option specifies the write password and
-q Ar password
-option the read password for previously encrypted files.
-The
-.B
-program prompts for the password if it reads an encrypted file
-and the password is missing or incorrect.
-If an encrypted file is read successfully and
-no write password is specified, the read password is used
-as the write password by default.
.SH "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.SH "FILES"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.SH BUGS
-It can take quite a while to generate some cryptographic values,
-from one to several minutes with modern architectures
-such as UltraSPARC and up to tens of minutes to an hour
-with older architectures such as SPARC IPC.
-.PP
-Please report bugs to http://bugs.ntp.org .Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-This document corresponds to version @VERSION@ of NTP.
-Portions of this document came from FreeBSD.
.PP
This manual page was \fIAutoGen\fP-erated from the \fBntp-keygen\fP
option definitions.
-.Dd December 24 2012
+.Dd December 25 2012
.Dt NTP_KEYGEN 1ntp-keygenmdoc User Commands
-.Os FreeBSD 6.4-STABLE
+.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 24, 2012 at 12:08:14 PM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:47 AM by AutoGen 5.16.2
.\" From the definitions ntp-keygen-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
All arguments must be options.
.Pp
.Sh DESCRIPTION
-This program generates cryptographic data files used by the NTPv4
-authentication and identification schemes.
-It generates MD5 key files used in symmetric key cryptography.
-In addition, if the OpenSSL software library has been installed,
-it generates keys, certificate and identity files used in public key
-cryptography.
-These files are used for cookie encryption,
-digital signature and challenge/response identification algorithms
-compatible with the Internet standard security infrastructure.
-.Pp
-All files are in PEM-encoded printable ASCII format,
-so they can be embedded as MIME attachments in mail to other sites
-and certificate authorities.
-By default, files are not encrypted.
-.Pp
-When used to generate message digest keys, the program produces a file
-containing ten pseudo-random printable ASCII strings suitable for the
-MD5 message digest algorithm included in the distribution.
-If the OpenSSL library is installed, it produces an additional ten
-hex-encoded random bit strings suitable for the SHA1 and other message
-digest algorithms.
-The message digest keys file must be distributed and stored
-using secure means beyond the scope of NTP itself.
-Besides the keys used for ordinary NTP associations, additional keys
-can be defined as passwords for the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-utility programs.
-.Pp
-The remaining generated files are compatible with other OpenSSL
-applications and other Public Key Infrastructure (PKI) resources.
-Certificates generated by this program are compatible with extant
-industry practice, although some users might find the interpretation of
-X509v3 extension fields somewhat liberal.
-However, the identity keys are probably not compatible with anything
-other than Autokey.
-.Pp
-Some files used by this program are encrypted using a private password.
-The
-.Fl p
-option specifies the password for local encrypted files and the
-.Fl q
-option the password for encrypted files sent to remote sites.
-If no password is specified, the host name returned by the Unix
-.Fn gethostname
-function, normally the DNS name of the host is used.
-.Pp
-The
-.Ar pw
-option of the
-.Ar crypto
-configuration command specifies the read
-password for previously encrypted local files.
-This must match the local password used by this program.
-If not specified, the host name is used.
-Thus, if files are generated by this program without password,
-they can be read back by
-.Ar ntpd
-without password but only on the same host.
-.Pp
-Normally, encrypted files for each host are generated by that host and
-used only by that host, although exceptions exist as noted later on
-this page.
-The symmetric keys file, normally called
-.Ar ntp.keys ,
-is usually installed in
-.Pa /etc .
-Other files and links are usually installed in
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem in
-NFS-mounted networks and cannot be changed by shared clients.
-The location of the keys directory can be changed by the
-.Ar keysdir
-configuration command in such cases.
-Normally, this is in
-.Pa /etc .
-.Pp
-This program directs commentary and error messages to the standard
-error stream
-.Ar stderr
-and remote files to the standard output stream
-.Ar stdout
-where they can be piped to other applications or redirected to files.
-The names used for generated files and links all begin with the
-string
-.Ar ntpkey
-and include the file type, generating host and filestamp,
-as described in the
-.Dq Cryptographic Data Files
-section below.
-.Ss Running the Program
-To test and gain experience with Autokey concepts, log in as root and
-change to the keys directory, usually
-.Pa /usr/local/etc
-When run for the first time, or if all files with names beginning with
-.Ar ntpkey
-have been removed, use the
-.Nm
-command without arguments to generate a
-default RSA host key and matching RSA-MD5 certificate with expiration
-date one year hence.
-If run again without options, the program uses the
-existing keys and parameters and generates only a new certificate with
-new expiration date one year hence.
-.Pp
-Run the command on as many hosts as necessary.
-Designate one of them as the trusted host (TH) using
-.Nm
-with the
-.Fl T
-option and configure it to synchronize from reliable Internet servers.
-Then configure the other hosts to synchronize to the TH directly or
-indirectly.
-A certificate trail is created when Autokey asks the immediately
-ascendant host towards the TH to sign its certificate, which is then
-provided to the immediately descendant host on request.
-All group hosts should have acyclic certificate trails ending on the TH.
-.Pp
-The host key is used to encrypt the cookie when required and so must be
-RSA type.
-By default, the host key is also the sign key used to encrypt
-signatures.
-A different sign key can be assigned using the
-.Fl S
-option and this can be either RSA or DSA type.
-By default, the signature
-message digest type is MD5, but any combination of sign key type and
-message digest type supported by the OpenSSL library can be specified
-using the
-.Fl c
-option.
-The rules say cryptographic media should be generated with proventic
-filestamps, which means the host should already be synchronized before
-this program is run.
-This of course creates a chicken-and-egg problem
-when the host is started for the first time.
-Accordingly, the host time
-should be set by some other means, such as eyeball-and-wristwatch, at
-least so that the certificate lifetime is within the current year.
-After that and when the host is synchronized to a proventic source, the
-certificate should be re-generated.
-.Pp
-Additional information on trusted groups and identity schemes is on the
-.Dq Autokey Public-Key Authentication
-page.
-.Pp
-The
-.Xr ntpd 1ntpdmdoc
-configuration command
-.Ic crypto pw Ar password
-specifies the read password for previously encrypted files.
-The daemon expires on the spot if the password is missing
-or incorrect.
-For convenience, if a file has been previously encrypted,
-the default read password is the name of the host running
-the program.
-If the previous write password is specified as the host name,
-these files can be read by that host with no explicit password.
-.Pp
-File names begin with the prefix
-.Cm ntpkey_
-and end with the postfix
-.Ar _hostname.filestamp ,
-where
-.Ar hostname
-is the owner name, usually the string returned
-by the Unix gethostname() routine, and
-.Ar filestamp
-is the NTP seconds when the file was generated, in decimal digits.
-This both guarantees uniqueness and simplifies maintenance
-procedures, since all files can be quickly removed
-by a
-.Ic rm ntpkey\&*
-command or all files generated
-at a specific time can be removed by a
-.Ic rm
-.Ar \&*filestamp
-command.
-To further reduce the risk of misconfiguration,
-the first two lines of a file contain the file name
-and generation date and time as comments.
-.Pp
-All files are installed by default in the keys directory
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem
-in NFS-mounted networks.
-The actual location of the keys directory
-and each file can be overridden by configuration commands,
-but this is not recommended.
-Normally, the files for each host are generated by that host
-and used only by that host, although exceptions exist
-as noted later on this page.
-.Pp
-Normally, files containing private values,
-including the host key, sign key and identification parameters,
-are permitted root read/write-only;
-while others containing public values are permitted world readable.
-Alternatively, files containing private values can be encrypted
-and these files permitted world readable,
-which simplifies maintenance in shared file systems.
-Since uniqueness is insured by the hostname and
-file name extensions, the files for a NFS server and
-dependent clients can all be installed in the same shared directory.
-.Pp
-The recommended practice is to keep the file name extensions
-when installing a file and to install a soft link
-from the generic names specified elsewhere on this page
-to the generated files.
-This allows new file generations to be activated simply
-by changing the link.
-If a link is present, ntpd follows it to the file name
-to extract the filestamp.
-If a link is not present,
-.Xr ntpd 1ntpdmdoc
-extracts the filestamp from the file itself.
-This allows clients to verify that the file and generation times
-are always current.
-The
-.Nm
-program uses the same timestamp extension for all files generated
-at one time, so each generation is distinct and can be readily
-recognized in monitoring data.
-.Ss Running the program
-The safest way to run the
-.Nm
-program is logged in directly as root.
-The recommended procedure is change to the keys directory,
-usually
-.Pa /usr/local/etc ,
-then run the program.
-When run for the first time,
-or if all
-.Cm ntpkey
-files have been removed,
-the program generates a RSA host key file and matching RSA-MD5 certificate file,
-which is all that is necessary in many cases.
-The program also generates soft links from the generic names
-to the respective files.
-If run again, the program uses the same host key file,
-but generates a new certificate file and link.
-.Pp
-The host key is used to encrypt the cookie when required and so must be RSA type.
-By default, the host key is also the sign key used to encrypt signatures.
-When necessary, a different sign key can be specified and this can be
-either RSA or DSA type.
-By default, the message digest type is MD5, but any combination
-of sign key type and message digest type supported by the OpenSSL library
-can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
-and RIPE160 message digest algorithms.
-However, the scheme specified in the certificate must be compatible
-with the sign key.
-Certificates using any digest algorithm are compatible with RSA sign keys;
-however, only SHA and SHA1 certificates are compatible with DSA sign keys.
-.Pp
-Private/public key files and certificates are compatible with
-other OpenSSL applications and very likely other libraries as well.
-Certificates or certificate requests derived from them should be compatible
-with extant industry practice, although some users might find
-the interpretation of X509v3 extension fields somewhat liberal.
-However, the identification parameter files, although encoded
-as the other files, are probably not compatible with anything other than Autokey.
-.Pp
-Running the program as other than root and using the Unix
-.Ic su
-command
-to assume root may not work properly, since by default the OpenSSL library
-looks for the random seed file
-.Cm .rnd
-in the user home directory.
-However, there should be only one
-.Cm .rnd ,
-most conveniently
-in the root directory, so it is convenient to define the
-.Cm $RANDFILE
-environment variable used by the OpenSSL library as the path to
-.Cm /.rnd .
-.Pp
-Installing the keys as root might not work in NFS-mounted
-shared file systems, as NFS clients may not be able to write
-to the shared keys directory, even as root.
-In this case, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-command.
-There is no need for one client to read the keys and certificates
-of other clients or servers, as these data are obtained automatically
-by the Autokey protocol.
-.Pp
-Ordinarily, cryptographic files are generated by the host that uses them,
-but it is possible for a trusted agent (TA) to generate these files
-for other hosts; however, in such cases files should always be encrypted.
-The subject name and trusted name default to the hostname
-of the host generating the files, but can be changed by command line options.
-It is convenient to designate the owner name and trusted name
-as the subject and issuer fields, respectively, of the certificate.
-The owner name is also used for the host and sign key files,
-while the trusted name is used for the identity files.
-.Pp
-All files are installed by default in the keys directory
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem
-in NFS-mounted networks.
-The actual location of the keys directory
-and each file can be overridden by configuration commands,
-but this is not recommended.
-Normally, the files for each host are generated by that host
-and used only by that host, although exceptions exist
-as noted later on this page.
-.Pp
-Normally, files containing private values,
-including the host key, sign key and identification parameters,
-are permitted root read/write-only;
-while others containing public values are permitted world readable.
-Alternatively, files containing private values can be encrypted
-and these files permitted world readable,
-which simplifies maintenance in shared file systems.
-Since uniqueness is insured by the hostname and
-file name extensions, the files for a NFS server and
-dependent clients can all be installed in the same shared directory.
-.Pp
-The recommended practice is to keep the file name extensions
-when installing a file and to install a soft link
-from the generic names specified elsewhere on this page
-to the generated files.
-This allows new file generations to be activated simply
-by changing the link.
-If a link is present, ntpd follows it to the file name
-to extract the filestamp.
-If a link is not present,
-.Xr ntpd 1ntpdmdoc
-extracts the filestamp from the file itself.
-This allows clients to verify that the file and generation times
-are always current.
-The
-.Nm
-program uses the same timestamp extension for all files generated
-at one time, so each generation is distinct and can be readily
-recognized in monitoring data.
-.Ss Running the program
-The safest way to run the
-.Nm
-program is logged in directly as root.
-The recommended procedure is change to the keys directory,
-usually
-.Pa /usr/local/etc ,
-then run the program.
-When run for the first time,
-or if all
-.Cm ntpkey
-files have been removed,
-the program generates a RSA host key file and matching RSA-MD5 certificate file,
-which is all that is necessary in many cases.
-The program also generates soft links from the generic names
-to the respective files.
-If run again, the program uses the same host key file,
-but generates a new certificate file and link.
-.Pp
-The host key is used to encrypt the cookie when required and so must be RSA type.
-By default, the host key is also the sign key used to encrypt signatures.
-When necessary, a different sign key can be specified and this can be
-either RSA or DSA type.
-By default, the message digest type is MD5, but any combination
-of sign key type and message digest type supported by the OpenSSL library
-can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
-and RIPE160 message digest algorithms.
-However, the scheme specified in the certificate must be compatible
-with the sign key.
-Certificates using any digest algorithm are compatible with RSA sign keys;
-however, only SHA and SHA1 certificates are compatible with DSA sign keys.
-.Pp
-Private/public key files and certificates are compatible with
-other OpenSSL applications and very likely other libraries as well.
-Certificates or certificate requests derived from them should be compatible
-with extant industry practice, although some users might find
-the interpretation of X509v3 extension fields somewhat liberal.
-However, the identification parameter files, although encoded
-as the other files, are probably not compatible with anything other than Autokey.
-.Pp
-Running the program as other than root and using the Unix
-.Ic su
-command
-to assume root may not work properly, since by default the OpenSSL library
-looks for the random seed file
-.Cm .rnd
-in the user home directory.
-However, there should be only one
-.Cm .rnd ,
-most conveniently
-in the root directory, so it is convenient to define the
-.Cm $RANDFILE
-environment variable used by the OpenSSL library as the path to
-.Cm /.rnd .
-.Pp
-Installing the keys as root might not work in NFS-mounted
-shared file systems, as NFS clients may not be able to write
-to the shared keys directory, even as root.
-In this case, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-command.
-There is no need for one client to read the keys and certificates
-of other clients or servers, as these data are obtained automatically
-by the Autokey protocol.
-.Pp
-Ordinarily, cryptographic files are generated by the host that uses them,
-but it is possible for a trusted agent (TA) to generate these files
-for other hosts; however, in such cases files should always be encrypted.
-The subject name and trusted name default to the hostname
-of the host generating the files, but can be changed by command line options.
-It is convenient to designate the owner name and trusted name
-as the subject and issuer fields, respectively, of the certificate.
-The owner name is also used for the host and sign key files,
-while the trusted name is used for the identity files.
-seconds.
-seconds.
-s Trusted Hosts and Groups
-Each cryptographic configuration involves selection of a signature scheme
-and identification scheme, called a cryptotype,
-as explained in the
-.Sx Authentication Options
-section of
-.Xr ntp.conf 5 .
-The default cryptotype uses RSA encryption, MD5 message digest
-and TC identification.
-First, configure a NTP subnet including one or more low-stratum
-trusted hosts from which all other hosts derive synchronization
-directly or indirectly.
-Trusted hosts have trusted certificates;
-all other hosts have nontrusted certificates.
-These hosts will automatically and dynamically build authoritative
-certificate trails to one or more trusted hosts.
-A trusted group is the set of all hosts that have, directly or indirectly,
-a certificate trail ending at a trusted host.
-The trail is defined by static configuration file entries
-or dynamic means described on the
-.Sx Automatic NTP Configuration Options
-section of
-.Xr ntp.conf 5 .
-.Pp
-On each trusted host as root, change to the keys directory.
-To insure a fresh fileset, remove all
-.Cm ntpkey
-files.
-Then run
-.Nm
-.Fl T
-to generate keys and a trusted certificate.
-On all other hosts do the same, but leave off the
-.Fl T
-flag to generate keys and nontrusted certificates.
-When complete, start the NTP daemons beginning at the lowest stratum
-and working up the tree.
-It may take some time for Autokey to instantiate the certificate trails
-throughout the subnet, but setting up the environment is completely automatic.
-.Pp
-If it is necessary to use a different sign key or different digest/signature
-scheme than the default, run
-.Nm
-with the
-.Fl S Ar type
-option, where
-.Ar type
-is either
-.Cm RSA
-or
-.Cm DSA .
-The most often need to do this is when a DSA-signed certificate is used.
-If it is necessary to use a different certificate scheme than the default,
-run
-.Nm
-with the
-.Fl c Ar scheme
-option and selected
-.Ar scheme
-as needed.
-f
-.Nm
-is run again without these options, it generates a new certificate
-using the same scheme and sign key.
-.Pp
-After setting up the environment it is advisable to update certificates
-from time to time, if only to extend the validity interval.
-Simply run
-.Nm
-with the same flags as before to generate new certificates
-using existing keys.
-However, if the host or sign key is changed,
-.Xr ntpd 1ntpdmdoc
-should be restarted.
-When
-.Xr ntpd 1ntpdmdoc
-is restarted, it loads any new files and restarts the protocol.
-Other dependent hosts will continue as usual until signatures are refreshed,
-at which time the protocol is restarted.
-.Ss Identity Schemes
-As mentioned on the Autonomous Authentication page,
-the default TC identity scheme is vulnerable to a middleman attack.
-However, there are more secure identity schemes available,
-including PC, IFF, GQ and MV described on the
-.Qq Identification Schemes
-page
-(maybe available at
-.Li http://www.eecis.udel.edu/%7emills/keygen.html ) .
-These schemes are based on a TA, one or more trusted hosts
-and some number of nontrusted hosts.
-Trusted hosts prove identity using values provided by the TA,
-while the remaining hosts prove identity using values provided
-by a trusted host and certificate trails that end on that host.
-The name of a trusted host is also the name of its sugroup
-and also the subject and issuer name on its trusted certificate.
-The TA is not necessarily a trusted host in this sense, but often is.
-.Pp
-In some schemes there are separate keys for servers and clients.
-A server can also be a client of another server,
-but a client can never be a server for another client.
-In general, trusted hosts and nontrusted hosts that operate
-as both server and client have parameter files that contain
-both server and client keys.
-Hosts that operate
-only as clients have key files that contain only client keys.
-.Pp
-The PC scheme supports only one trusted host in the group.
-On trusted host alice run
-.Nm
-.Fl P
-.Fl p Ar password
-to generate the host key file
-.Pa ntpkey_RSAkey_ Ns Ar alice.filestamp
-and trusted private certificate file
-.Pa ntpkey_RSA-MD5_cert_ Ns Ar alice.filestamp .
-Copy both files to all group hosts;
-they replace the files which would be generated in other schemes.
-On each host bob install a soft link from the generic name
-.Pa ntpkey_host_ Ns Ar bob
-to the host key file and soft link
-.Pa ntpkey_cert_ Ns Ar bob
-to the private certificate file.
-Note the generic links are on bob, but point to files generated
-by trusted host alice.
-In this scheme it is not possible to refresh
-either the keys or certificates without copying them
-to all other hosts in the group.
-.Pp
-For the IFF scheme proceed as in the TC scheme to generate keys
-and certificates for all group hosts, then for every trusted host in the group,
-generate the IFF parameter file.
-On trusted host alice run
-.Nm
-.Fl T
-.Fl I
-.Fl p Ar password
-to produce her parameter file
-.Pa ntpkey_IFFpar_ Ns Ar alice.filestamp ,
-which includes both server and client keys.
-Copy this file to all group hosts that operate as both servers
-and clients and install a soft link from the generic
-.Pa ntpkey_iff_ Ns Ar alice
-to this file.
-If there are no hosts restricted to operate only as clients,
-there is nothing further to do.
-As the IFF scheme is independent
-of keys and certificates, these files can be refreshed as needed.
-.Pp
-If a rogue client has the parameter file, it could masquerade
-as a legitimate server and present a middleman threat.
-To eliminate this threat, the client keys can be extracted
-from the parameter file and distributed to all restricted clients.
-After generating the parameter file, on alice run
-.Nm
-.Fl e
-and pipe the output to a file or mail program.
-Copy or mail this file to all restricted clients.
-On these clients install a soft link from the generic
-.Pa ntpkey_iff_ Ns Ar alice
-to this file.
-To further protect the integrity of the keys,
-each file can be encrypted with a secret password.
-.Pp
-For the GQ scheme proceed as in the TC scheme to generate keys
-and certificates for all group hosts, then for every trusted host
-in the group, generate the IFF parameter file.
-On trusted host alice run
-.Nm
-.Fl T
-.Fl G
-.Fl p Ar password
-to produce her parameter file
-.Pa ntpkey_GQpar_ Ns Ar alice.filestamp ,
-which includes both server and client keys.
-Copy this file to all group hosts and install a soft link
-from the generic
-.Pa ntpkey_gq_ Ns Ar alice
-to this file.
-In addition, on each host bob install a soft link
-from generic
-.Pa ntpkey_gq_ Ns Ar bob
-to this file.
-As the GQ scheme updates the GQ parameters file and certificate
-at the same time, keys and certificates can be regenerated as needed.
-.Pp
-For the MV scheme, proceed as in the TC scheme to generate keys
-and certificates for all group hosts.
-For illustration assume trish is the TA, alice one of several trusted hosts
-and bob one of her clients.
-On TA trish run
-.Nm
-.Fl V Ar n
-.Fl p Ar password ,
-where
-.Ar n
-is the number of revokable keys (typically 5) to produce
-the parameter file
-.Pa ntpkeys_MVpar_ Ns Ar trish.filestamp
-and client key files
-.Pa ntpkeys_MVkeyd_ Ns Ar trish.filestamp
-where
-.Ar d
-is the key number (0 \&<
-.Ar d
-\&<
-.Ar n ) .
-Copy the parameter file to alice and install a soft link
-from the generic
-.Pa ntpkey_mv_ Ns Ar alice
-to this file.
-Copy one of the client key files to alice for later distribution
-to her clients.
-It doesn't matter which client key file goes to alice,
-since they all work the same way.
-Alice copies the client key file to all of her cliens.
-On client bob install a soft link from generic
-.Pa ntpkey_mvkey_ Ns Ar bob
-to the client key file.
-As the MV scheme is independent of keys and certificates,
-these files can be refreshed as needed.
-.Ss Command Line Options
-.Bl -tag -width indent
-.It Fl c Ar scheme
-Select certificate message digest/signature encryption scheme.
-The
-.Ar scheme
-can be one of the following:
-. Cm RSA-MD2 , RSA-MD5 , RSA-SHA , RSA-SHA1 , RSA-MDC2 , RSA-RIPEMD160 , DSA-SHA ,
-or
-.Cm DSA-SHA1 .
-Note that RSA schemes must be used with a RSA sign key and DSA
-schemes must be used with a DSA sign key.
-The default without this option is
-.Cm RSA-MD5 .
-.It Fl d
-Enable debugging.
-This option displays the cryptographic data produced in eye-friendly billboards.
-.It Fl e
-Write the IFF client keys to the standard output.
-This is intended for automatic key distribution by mail.
-.It Fl G
-Generate parameters and keys for the GQ identification scheme,
-obsoleting any that may exist.
-.It Fl g
-Generate keys for the GQ identification scheme
-using the existing GQ parameters.
-If the GQ parameters do not yet exist, create them first.
-.It Fl H
-Generate new host keys, obsoleting any that may exist.
-.It Fl I
-Generate parameters for the IFF identification scheme,
-obsoleting any that may exist.
-.It Fl i Ar name
-Set the suject name to
-.Ar name .
-This is used as the subject field in certificates
-and in the file name for host and sign keys.
-.It Fl M
-Generate MD5 keys, obsoleting any that may exist.
-.It Fl P
-Generate a private certificate.
-By default, the program generates public certificates.
-.It Fl p Ar password
-Encrypt generated files containing private data with
-.Ar password
-and the DES-CBC algorithm.
-.It Fl q
-Set the password for reading files to password.
-.It Fl S Oo Cm RSA | DSA Oc
-Generate a new sign key of the designated type,
-obsoleting any that may exist.
-By default, the program uses the host key as the sign key.
-.It Fl s Ar name
-Set the issuer name to
-.Ar name .
-This is used for the issuer field in certificates
-and in the file name for identity files.
-.It Fl T
-Generate a trusted certificate.
-By default, the program generates a non-trusted certificate.
-.It Fl V Ar nkeys
-Generate parameters and keys for the Mu-Varadharajan (MV) identification scheme.
-.El
-.Ss Random Seed File
-All cryptographically sound key generation schemes must have means
-to randomize the entropy seed used to initialize
-the internal pseudo-random number generator used
-by the library routines.
-The OpenSSL library uses a designated random seed file for this purpose.
-The file must be available when starting the NTP daemon and
-.Nm
-program.
-If a site supports OpenSSL or its companion OpenSSH,
-it is very likely that means to do this are already available.
-.Pp
-It is important to understand that entropy must be evolved
-for each generation, for otherwise the random number sequence
-would be predictable.
-Various means dependent on external events, such as keystroke intervals,
-can be used to do this and some systems have built-in entropy sources.
-Suitable means are described in the OpenSSL software documentation,
-but are outside the scope of this page.
-.Pp
-The entropy seed used by the OpenSSL library is contained in a file,
-usually called
-.Cm .rnd ,
-which must be available when starting the NTP daemon
-or the
-.Nm
-program.
-The NTP daemon will first look for the file
-using the path specified by the
-.Ic randfile
-subcommand of the
-.Ic crypto
-configuration command.
-If not specified in this way, or when starting the
-.Nm
-program,
-the OpenSSL library will look for the file using the path specified
-by the
-.Ev RANDFILE
-environment variable in the user home directory,
-whether root or some other user.
-If the
-.Ev RANDFILE
-environment variable is not present,
-the library will look for the
-.Cm .rnd
-file in the user home directory.
-If the file is not available or cannot be written,
-the daemon exits with a message to the system log and the program
-exits with a suitable error message.
-.Ss Cryptographic Data Files
-All other file formats begin with two lines.
-The first contains the file name, including the generated host name
-and filestamp.
-The second contains the datestamp in conventional Unix date format.
-Lines beginning with # are considered comments and ignored by the
-.Nm
-program and
-.Xr ntpd 1ntpdmdoc
-daemon.
-Cryptographic values are encoded first using ASN.1 rules,
-then encrypted if necessary, and finally written PEM-encoded
-printable ASCII format preceded and followed by MIME content identifier lines.
-.Pp
-The format of the symmetric keys file is somewhat different
-than the other files in the interest of backward compatibility.
-Since DES-CBC is deprecated in NTPv4, the only key format of interest
-is MD5 alphanumeric strings.
-Following hte heard the keys are
-entered one per line in the format
-.D1 Ar keyno type key
-where
-.Ar keyno
-is a positive integer in the range 1-65,535,
-.Ar type
-is the string MD5 defining the key format and
-.Ar key
-is the key itself,
-which is a printable ASCII string 16 characters or less in length.
-Each character is chosen from the 93 printable characters
-in the range 0x21 through 0x7f excluding space and the
-.Ql #
-character.
-.Pp
-Note that the keys used by the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-programs
-are checked against passwords requested by the programs
-and entered by hand, so it is generally appropriate to specify these keys
-in human readable ASCII format.
-.Pp
-The
-.Nm
-program generates a MD5 symmetric keys file
-.Pa ntpkey_MD5key_ Ns Ar hostname.filestamp .
-Since the file contains private shared keys,
-it should be visible only to root and distributed by secure means
-to other subnet hosts.
-The NTP daemon loads the file
-.Pa ntp.keys ,
-so
-.Nm
-installs a soft link from this name to the generated file.
-Subsequently, similar soft links must be installed by manual
-or automated means on the other subnet hosts.
-While this file is not used with the Autokey Version 2 protocol,
-it is needed to authenticate some remote configuration commands
-used by the
-.Xr ntpq 1ntpqmdoc
-and
-.Xr ntpdc 1ntpdcmdoc
-utilities.
.Sh "OPTIONS"
.Bl -tag
.It \-b " \fIimbits\fP, " \-\-imbits "=" \fIimbits\fP
If any of these are directories, then the file \fI.ntprc\fP
is searched for within those directories.
.Sh USAGE
-The
-.Fl p Ar password
-option specifies the write password and
-.Fl q Ar password
-option the read password for previously encrypted files.
-The
-.Nm
-program prompts for the password if it reads an encrypted file
-and the password is missing or incorrect.
-If an encrypted file is read successfully and
-no write password is specified, the read password is used
-as the write password by default.
.Sh "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.Sh "FILES"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.Sh BUGS
-It can take quite a while to generate some cryptographic values,
-from one to several minutes with modern architectures
-such as UltraSPARC and up to tens of minutes to an hour
-with older architectures such as SPARC IPC.
-.Pp
-Please report bugs to http://bugs.ntp.org .Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-This document corresponds to version @VERSION@ of NTP.
-Portions of this document came from FreeBSD.
.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntp-keygen\fP
option definitions.
<p>This document describes the use of the NTP Project's <code>ntp-keygen</code>
program, that generates cryptographic data files used by the NTPv4
authentication and identity schemes.
-It can generate message digest
-keys used in symmetric key cryptography and, if the OpenSSL software
+It can generate message digest keys used in symmetric key cryptography and,
+if the OpenSSL software
library has been installed, it can generate host keys, sign keys,
certificates, and identity keys and parameters used by the Autokey
public key cryptography.
printable ASCII format so they can be embedded as MIME attachments in
mail to other sites.
- <p>This document applies to version 4.2.7p337 of <code>ntp-keygen</code>.
+ <p>This document applies to version 4.2.7p338 of <code>ntp-keygen</code>.
<div class="node">
<p><hr>
<p>When used to generate message digest keys, the program produces a file
containing ten pseudo-random printable ASCII strings suitable for the
-MD5 message digest algorithm included in the distribution. If the
+MD5 message digest algorithm included in the distribution.
+If the
OpenSSL library is installed, it produces an additional ten hex-encoded
random bit strings suitable for the SHA1 and other message digest
-algorithms. The message digest keys file must be distributed and stored
-using secure means beyond the scope of NTP itself. Besides the keys
+algorithms.
+The message digest keys file must be distributed and stored
+using secure means beyond the scope of NTP itself.
+Besides the keys
used for ordinary NTP associations, additional keys can be defined as
passwords for the ntpq and ntpdc utility programs.
applications and other Public Key Infrastructure (PKI) resources.
Certificates generated by this program are compatible with extant
industry practice, although some users might find the interpretation of
-X509v3 extension fields somewhat liberal. However, the identity keys
+X509v3 extension fields somewhat liberal.
+However, the identity keys
are probably not compatible with anything other than Autokey.
<p>Some files used by this program are encrypted using a private password.
-The -p option specifies the password for local encrypted files and the
--q option the password for encrypted files sent to remote sites. If no
-password is specified, the host name returned by the Unix gethostname()
-function, normally the DNS name of the host, is used.
-
- <p>The pw option of the crypto configuration command specifies the read
-password for previously encrypted local files. This must match the
-local password used by this program. If not specified, the host name is
-used. Thus, if files are generated by this program without password,
+The <code>-p</code> option specifies the password for local encrypted files and the
+<code>-q</code> option the password for encrypted files sent to remote sites.
+If no password is specified, the host name returned by the Unix
+<code>gethostname()</code> function, normally the DNS name of the host, is used.
+
+ <p>The <kbd>pw</kbd> option of the <code>crypto</code> configuration command
+specifies the read password for previously encrypted local files.
+This must match the local password used by this program.
+If not specified, the host name is used.
+Thus, if files are generated by this program without password,
they can be read back by ntpd without password, but only on the same
host.
<p>Normally, encrypted files for each host are generated by that host and
used only by that host, although exceptions exist as noted later on
-this page. The symmetric keys file, normally called ntp.keys, is
-usually installed in /etc. Other files and links are usually installed
-in /usr/local/etc, which is normally in a shared filesystem in
-NFS-mounted networks and cannot be changed by shared clients. The
-location of the keys directory can be changed by the keysdir
-configuration command in such cases. Normally, this is in /etc.
+this page.
+The symmetric keys file, normally called <code>ntp.keys</code>, is
+usually installed in <code>/etc</code>.
+Other files and links are usually installed
+in <code>/usr/local/etc</code>, which is normally in a shared filesystem in
+NFS-mounted networks and cannot be changed by shared clients.
+The location of the keys directory can be changed by the keysdir
+configuration command in such cases.
+Normally, this is in <code>/etc</code>.
<p>This program directs commentary and error messages to the standard
-error stream stderr and remote files to the standard output stream
-stdout where they can be piped to other applications or redirected to
-files. The names used for generated files and links all begin with the
-string ntpkey and include the file type, generating host and filestamp,
-as described in the Cryptographic Data Files section below.
+error stream <code>stderr</code> and remote files to the standard output stream
+<code>stdout</code> where they can be piped to other applications or redirected to
+files.
+The names used for generated files and links all begin with the
+string <code>ntpkey</code> and include the file type,
+generating host and filestamp,
+as described in the <a href="#Cryptographic-Data-Files">Cryptographic Data Files</a> section below.
<div class="node">
<p><hr>
<h3 class="section">Running the Program</h3>
<p>To test and gain experience with Autokey concepts, log in as root and
-change to the keys directory, usually /usr/local/etc. When run for the
-first time, or if all files with names beginning ntpkey have been
-removed, use the ntp-keygen command without arguments to generate a
+change to the keys directory, usually <code>/usr/local/etc</code>.
+When run for the
+first time, or if all files with names beginning <code>ntpkey</code>] have been
+removed, use the <code>ntp-keygen</code> command without arguments to generate a
default RSA host key and matching RSA-MD5 certificate with expiration
-date one year hence. If run again without options, the program uses the
+date one year hence.
+If run again without options, the program uses the
existing keys and parameters and generates only a new certificate with
new expiration date one year hence.
- <p>Run the command on as many hosts as necessary. Designate one of them as
-the trusted host (TH) using ntp-keygen with the -T option and configure
-it to synchronize from reliable Internet servers. Then configure the
-other hosts to synchronize to the TH directly or indirectly. A
-certificate trail is created when Autokey asks the immediately
+ <p>Run the command on as many hosts as necessary.
+Designate one of them as the trusted host (TH) using <code>ntp-keygen</code>
+with the <code>-T</code> option and configure
+it to synchronize from reliable Internet servers.
+Then configure the other hosts to synchronize to the TH directly or indirectly.
+A certificate trail is created when Autokey asks the immediately
ascendant host towards the TH to sign its certificate, which is then
-provided to the immediately descendant host on request. All group hosts
-should have acyclic certificate trails ending on the TH.
+provided to the immediately descendant host on request.
+All group hosts should have acyclic certificate trails ending on the TH.
<p>The host key is used to encrypt the cookie when required and so must be
-RSA type. By default, the host key is also the sign key used to encrypt
-signatures. A different sign key can be assigned using the -S option
-and this can be either RSA or DSA type. By default, the signature
+RSA type.
+By default, the host key is also the sign key used to encrypt signatures.
+A different sign key can be assigned using the <code>-S</code> option
+and this can be either RSA or DSA type.
+By default, the signature
message digest type is MD5, but any combination of sign key type and
message digest type supported by the OpenSSL library can be specified
-using the -c option.
+using the <code>-c</code> option.
<p>The rules say cryptographic media should be generated with proventic
filestamps, which means the host should already be synchronized before
-this program is run. This of course creates a chicken-and-egg problem
-when the host is started for the first time. Accordingly, the host time
+this program is run.
+This of course creates a chicken-and-egg problem
+when the host is started for the first time.
+Accordingly, the host time
should be set by some other means, such as eyeball-and-wristwatch, at
least so that the certificate lifetime is within the current year.
After that and when the host is synchronized to a proventic source, the
certificate should be re-generated.
<p>Additional information on trusted groups and identity schemes is on the
-Autokey Public-Key Authentication
-page.
+Autokey Public-Key Authentication page.
<div class="node">
<p><hr>
The message digest keys file must be distributed and stored
using secure means beyond the scope of NTP itself.
Besides the keys used for ordinary NTP associations, additional keys
-can be defined as passwords for the ntpq and ntpdc utility programs.
+can be defined as passwords for the
+<code>ntpq(1ntpqmdoc)</code>
+and
+<code>ntpdc(1ntpdcmdoc)</code>
+utility programs.
<p>The remaining generated files are compatible with other OpenSSL
applications and other Public Key Infrastructure (PKI) resources.
<p>Some files used by this program are encrypted using a private password.
The
-<code>--p</code> option specifies the password for local encrypted files and the
-<code>--q</code> option the password for encrypted files sent to remote sites.
+<code>-p</code> option specifies the password for local encrypted files and the
+<code>-q</code> option the password for encrypted files sent to remote sites.
If no password is specified, the host name returned by the Unix
-.Fn
-gethostname
+<code>gethostname</code>()
function, normally the DNS name of the host is used.
<p>The
-<kbd>pw</kbd> option of the
-<kbd>crypto</kbd> configuration command specifies the read
+<code>pw</code> option of the
+<code>crypto</code> configuration command specifies the read
password for previously encrypted local files.
This must match the local password used by this program.
If not specified, the host name is used.
Thus, if files are generated by this program without password,
they can be read back by
-<kbd>ntpd</kbd> without password but only on the same host.
+<code>ntpd</code> without password but only on the same host.
<p>Normally, encrypted files for each host are generated by that host and
used only by that host, although exceptions exist as noted later on
this page.
The symmetric keys file, normally called
-ntp.keys, is usually installed in
+<code>ntp.keys</code>, is usually installed in
<span class="file">/etc</span>.
-.
Other files and links are usually installed in
<span class="file">/usr/local/etc</span>,
-,
which is normally in a shared filesystem in
NFS-mounted networks and cannot be changed by shared clients.
The location of the keys directory can be changed by the
-<kbd>keysdir</kbd> configuration command in such cases.
+<code>keysdir</code> configuration command in such cases.
Normally, this is in
-<span class="file">/etc</span>.
-.
+<span class="file">/etc</span>.
<p>This program directs commentary and error messages to the standard
error stream
-<kbd>stderr</kbd> and remote files to the standard output stream
-<kbd>stdout</kbd> where they can be piped to other applications or redirected to files.
+<code>stderr</code> and remote files to the standard output stream
+<code>stdout</code> where they can be piped to other applications or redirected to files.
The names used for generated files and links all begin with the
string
-<kbd>ntpkey</kbd> and include the file type, generating host and filestamp,
+<code>ntpkey</code> and include the file type, generating host and filestamp,
as described in the
-CryptographicDataFiles
+Cryptographic Data Files
section below.
<div class="node">
<p><hr>
change to the keys directory, usually
<span class="file">/usr/local/etc</span>
When run for the first time, or if all files with names beginning with
-<kbd>ntpkey</kbd> have been removed, use the
+<code>ntpkey</code> have been removed, use the
<code>ntp-keygen</code>
command without arguments to generate a
default RSA host key and matching RSA-MD5 certificate with expiration
certificate should be re-generated.
<p>Additional information on trusted groups and identity schemes is on the
-AutokeyPublic-KeyAuthentication
+Autokey Public-Key Authentication
page.
<p>The
-<code>ntpd(8)</code>
+<code>ntpd(1ntpdmdoc)</code>
configuration command
-<code>crypto</code> <code>pw</code> <code>Ar</code> <code>password</code> specifies the read password for previously encrypted files.
+<code>crypto</code> <code>pw</code> <code>password</code> specifies the read password for previously encrypted files.
The daemon expires on the spot if the password is missing
or incorrect.
For convenience, if a file has been previously encrypted,
<p>File names begin with the prefix
<code>ntpkey_</code> and end with the postfix
-_hostname.filestamp, where
-<kbd>hostname</kbd> is the owner name, usually the string returned
+<code>_hostname.filestamp</code>, where
+<code>hostname</code> is the owner name, usually the string returned
by the Unix gethostname() routine, and
-<kbd>filestamp</kbd> is the NTP seconds when the file was generated, in decimal digits.
+<code>filestamp</code> is the NTP seconds when the file was generated, in decimal digits.
This both guarantees uniqueness and simplifies maintenance
procedures, since all files can be quickly removed
by a
-<code>rm</code>ntpkey\&* command or all files generated
+<code>rm</code> <code>ntpkey\&*</code> command or all files generated
at a specific time can be removed by a
-<code>rm</code> \&*filestamp command.
+<code>rm</code> <code>\&*filestamp</code> command.
To further reduce the risk of misconfiguration,
the first two lines of a file contain the file name
and generation date and time as comments.
<p>All files are installed by default in the keys directory
<span class="file">/usr/local/etc</span>,
-,
which is normally in a shared filesystem
in NFS-mounted networks.
The actual location of the keys directory
If a link is present, ntpd follows it to the file name
to extract the filestamp.
If a link is not present,
-<code>ntpd(8)</code>
+<code>ntpd(1ntpdmdoc)</code>
extracts the filestamp from the file itself.
This allows clients to verify that the file and generation times
are always current.
The recommended procedure is change to the keys directory,
usually
<span class="file">/usr/local/etc</span>,
-,
then run the program.
When run for the first time,
or if all
<code>su</code> command
to assume root may not work properly, since by default the OpenSSL library
looks for the random seed file
-.rnd in the user home directory.
+<code>.rnd</code> in the user home directory.
However, there should be only one
-.rnd, most conveniently
+<code>.rnd</code>, most conveniently
in the root directory, so it is convenient to define the
-$RANDFILE environment variable used by the OpenSSL library as the path to
-/.rnd.
+<code>$RANDFILE</code> environment variable used by the OpenSSL library as the path to
+<code>/.rnd</code>.
Installing the keys as root might not work in NFS-mounted
shared file systems, as NFS clients may not be able to write
to the shared keys directory, even as root.
<p>All files are installed by default in the keys directory
<span class="file">/usr/local/etc</span>,
-,
which is normally in a shared filesystem
in NFS-mounted networks.
The actual location of the keys directory
If a link is present, ntpd follows it to the file name
to extract the filestamp.
If a link is not present,
-<code>ntpd(8)</code>
+<code>ntpd(1ntpdmdoc)</code>
extracts the filestamp from the file itself.
This allows clients to verify that the file and generation times
are always current.
The recommended procedure is change to the keys directory,
usually
<span class="file">/usr/local/etc</span>,
-,
then run the program.
When run for the first time,
or if all
<code>su</code> command
to assume root may not work properly, since by default the OpenSSL library
looks for the random seed file
-.rnd in the user home directory.
+<code>.rnd</code> in the user home directory.
However, there should be only one
-.rnd, most conveniently
+<code>.rnd</code>, most conveniently
in the root directory, so it is convenient to define the
-$RANDFILE environment variable used by the OpenSSL library as the path to
-/.rnd.
+<code>$RANDFILE</code> environment variable used by the OpenSSL library as the path to
+<code>/.rnd</code>.
Installing the keys as root might not work in NFS-mounted
shared file systems, as NFS clients may not be able to write
to the shared keys directory, even as root.
scheme than the default, run
<code>ntp-keygen</code>
with the
-<code>-S</code> <code>-Ar</code> <code>-type</code> option, where
-<kbd>type</kbd> is either
+<code>-S</code> <code>-type</code> option, where
+<code>type</code> is either
<code>RSA</code> or
<code>DSA</code>. The most often need to do this is when a DSA-signed certificate is used.
If it is necessary to use a different certificate scheme than the default,
run
<code>ntp-keygen</code>
with the
-<code>-c</code> <code>-Ar</code> <code>-scheme</code> option and selected
-<kbd>scheme</kbd> as needed.
+<code>-c</code> <code>-scheme</code> option and selected
+<code>scheme</code> as needed.
f
<code>ntp-keygen</code>
is run again without these options, it generates a new certificate
with the same flags as before to generate new certificates
using existing keys.
However, if the host or sign key is changed,
-<code>ntpd(8)</code>
+<code>ntpd(1ntpdmdoc)</code>
should be restarted.
When
-<code>ntpd(8)</code>
+<code>ntpd(1ntpdmdoc)</code>
is restarted, it loads any new files and restarts the protocol.
Other dependent hosts will continue as usual until signatures are refreshed,
at which time the protocol is restarted.
the default TC identity scheme is vulnerable to a middleman attack.
However, there are more secure identity schemes available,
including PC, IFF, GQ and MV described on the
-"IdentificationSchemes"
+"Identification Schemes"
page
(maybe available at
.Li
<p>The PC scheme supports only one trusted host in the group.
On trusted host alice run
<code>ntp-keygen</code>
-<code>-P</code> <code>-p</code> <code>-Ar</code> <code>-password</code> to generate the host key file
+<code>-P</code> <code>-p</code> <code>-password</code> to generate the host key file
<span class="file">ntpkey_RSAkey_</span>NsAralice.filestamp
-Ns
-Ar
-alice.filestamp
and trusted private certificate file
<span class="file">ntpkey_RSA-MD5_cert_</span>NsAralice.filestamp.
-Ns
-Ar
-alice.filestamp
-.
Copy both files to all group hosts;
they replace the files which would be generated in other schemes.
On each host bob install a soft link from the generic name
<span class="file">ntpkey_host_</span>NsArbob
-Ns
-Ar
-bob
to the host key file and soft link
<span class="file">ntpkey_cert_</span>NsArbob
-Ns
-Ar
-bob
to the private certificate file.
Note the generic links are on bob, but point to files generated
by trusted host alice.
generate the IFF parameter file.
On trusted host alice run
<code>ntp-keygen</code>
-<code>-T</code> <code>-I</code> <code>-p</code> <code>-Ar</code> <code>-password</code> to produce her parameter file
+<code>-T</code> <code>-I</code> <code>-p</code> <code>-password</code> to produce her parameter file
<span class="file">ntpkey_IFFpar_</span>NsAralice.filestamp,
-Ns
-Ar
-alice.filestamp
-,
which includes both server and client keys.
Copy this file to all group hosts that operate as both servers
and clients and install a soft link from the generic
<span class="file">ntpkey_iff_</span>NsAralice
-Ns
-Ar
-alice
to this file.
If there are no hosts restricted to operate only as clients,
there is nothing further to do.
Copy or mail this file to all restricted clients.
On these clients install a soft link from the generic
<span class="file">ntpkey_iff_</span>NsAralice
-Ns
-Ar
-alice
to this file.
To further protect the integrity of the keys,
each file can be encrypted with a secret password.
in the group, generate the IFF parameter file.
On trusted host alice run
<code>ntp-keygen</code>
-<code>-T</code> <code>-G</code> <code>-p</code> <code>-Ar</code> <code>-password</code> to produce her parameter file
+<code>-T</code> <code>-G</code> <code>-p</code> <code>-password</code> to produce her parameter file
<span class="file">ntpkey_GQpar_</span>NsAralice.filestamp,
-Ns
-Ar
-alice.filestamp
-,
which includes both server and client keys.
Copy this file to all group hosts and install a soft link
from the generic
<span class="file">ntpkey_gq_</span>NsAralice
-Ns
-Ar
-alice
to this file.
In addition, on each host bob install a soft link
from generic
<span class="file">ntpkey_gq_</span>NsArbob
-Ns
-Ar
-bob
to this file.
As the GQ scheme updates the GQ parameters file and certificate
at the same time, keys and certificates can be regenerated as needed.
and bob one of her clients.
On TA trish run
<code>ntp-keygen</code>
-<code>-V</code> <code>-Ar</code> <code>-n</code> <code>-p</code> <code>-Ar</code> <code>-password</code>, where
-<kbd>n</kbd> is the number of revokable keys (typically 5) to produce
+<code>-V</code> <code>-n</code> <code>-p</code> <code>-password</code>, where
+<code>n</code> is the number of revokable keys (typically 5) to produce
the parameter file
<span class="file">ntpkeys_MVpar_</span>NsArtrish.filestamp
-Ns
-Ar
-trish.filestamp
and client key files
<span class="file">ntpkeys_MVkeyd_</span>NsArtrish.filestamp
-Ns
-Ar
-trish.filestamp
where
-<kbd>d</kbd> is the key number (0 \&<
-<kbd>d</kbd> \&<
-<kbd>n</kbd>). Copy the parameter file to alice and install a soft link
+<code>d</code> is the key number (0 \&<
+<code>d</code> \&<
+<code>n</code>). Copy the parameter file to alice and install a soft link
from the generic
<span class="file">ntpkey_mv_</span>NsAralice
-Ns
-Ar
-alice
to this file.
Copy one of the client key files to alice for later distribution
to her clients.
Alice copies the client key file to all of her cliens.
On client bob install a soft link from generic
<span class="file">ntpkey_mvkey_</span>NsArbob
-Ns
-Ar
-bob
to the client key file.
As the MV scheme is independent of keys and certificates,
these files can be refreshed as needed.
<dl>
<dt><span class="samp">Fl</span><dd>Select certificate message digest/signature encryption scheme.
The
-<kbd>scheme</kbd> can be one of the following:
+<code>scheme</code> can be one of the following:
.
Cm
RSA-MD2
<br><dt><span class="samp">Fl</span><dd>Generate parameters for the IFF identification scheme,
obsoleting any that may exist.
<br><dt><span class="samp">Fl</span><dd>Set the suject name to
-<kbd>name</kbd>. This is used as the subject field in certificates
+<code>name</code>. This is used as the subject field in certificates
and in the file name for host and sign keys.
<br><dt><span class="samp">Fl</span><dd>Generate MD5 keys, obsoleting any that may exist.
<br><dt><span class="samp">Fl</span><dd>Generate a private certificate.
By default, the program generates public certificates.
<br><dt><span class="samp">Fl</span><dd>Encrypt generated files containing private data with
-<kbd>password</kbd> and the DES-CBC algorithm.
+<code>password</code> and the DES-CBC algorithm.
<br><dt><span class="samp">Fl</span><dd>Set the password for reading files to password.
<br><dt><span class="samp">Fl</span><dd>Generate a new sign key of the designated type,
obsoleting any that may exist.
By default, the program uses the host key as the sign key.
<br><dt><span class="samp">Fl</span><dd>Set the issuer name to
-<kbd>name</kbd>. This is used for the issuer field in certificates
+<code>name</code>. This is used for the issuer field in certificates
and in the file name for identity files.
<br><dt><span class="samp">Fl</span><dd>Generate a trusted certificate.
By default, the program generates a non-trusted certificate.
<p>The entropy seed used by the OpenSSL library is contained in a file,
usually called
-.rnd, which must be available when starting the NTP daemon
+<code>.rnd</code>, which must be available when starting the NTP daemon
or the
<code>ntp-keygen</code>
program.
RANDFILE
environment variable is not present,
the library will look for the
-.rnd file in the user home directory.
+<code>.rnd</code> file in the user home directory.
If the file is not available or cannot be written,
the daemon exits with a message to the system log and the program
exits with a suitable error message.
Lines beginning with # are considered comments and ignored by the
<code>ntp-keygen</code>
program and
-<code>ntpd(8)</code>
+<code>ntpd(1ntpdmdoc)</code>
daemon.
Cryptographic values are encoded first using ASN.1 rules,
then encrypted if necessary, and finally written PEM-encoded
type
key
where
-<kbd>keyno</kbd> is a positive integer in the range 1-65,535,
-<kbd>type</kbd> is the string MD5 defining the key format and
-<kbd>key</kbd> is the key itself,
+<code>keyno</code> is a positive integer in the range 1-65,535,
+<code>type</code> is the string MD5 defining the key format and
+<code>key</code> is the key itself,
which is a printable ASCII string 16 characters or less in length.
Each character is chosen from the 93 printable characters
in the range 0x21 through 0x7f excluding space and the
character.
<p>Note that the keys used by the
-<code>ntpq(8)</code>
+<code>ntpq(1ntpqmdoc)</code>
and
-<code>ntpdc(8)</code>
+<code>ntpdc(1ntpdcmdoc)</code>
programs
are checked against passwords requested by the programs
and entered by hand, so it is generally appropriate to specify these keys
<code>ntp-keygen</code>
program generates a MD5 symmetric keys file
<span class="file">ntpkey_MD5key_</span>NsArhostname.filestamp.
-Ns
-Ar
-hostname.filestamp
-.
Since the file contains private shared keys,
it should be visible only to root and distributed by secure means
to other subnet hosts.
The NTP daemon loads the file
<span class="file">ntp.keys</span>,
-,
so
<code>ntp-keygen</code>
installs a soft link from this name to the generated file.
While this file is not used with the Autokey Version 2 protocol,
it is needed to authenticate some remote configuration commands
used by the
-<code>ntpq(8)</code>
+<code>ntpq(1ntpqmdoc)</code>
and
-<code>ntpdc(8)</code>
+<code>ntpdc(1ntpdcmdoc)</code>
utilities.
<p>This section was generated by <strong>AutoGen</strong>,
used to select the program, defaulting to <span class="file">more</span>. Both will exit
with a status code of 0.
- <pre class="example"> ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p336
+ <pre class="example"> ntp-keygen (ntp) - Create a NTP host key - Ver. 4.2.7p337
USAGE: ntp-keygen [ -<flag> [<val>] | --<name>[{=| }<val>] ]...
Flg Arg Option-Name Description
-b Num imbits identity modulus bits
<p>Select the cipher which is used to encrypt the files containing
private keys. The default is three-key triple DES in CBC mode,
-equivalent to "-C des-ede3-cbc". The openssl tool lists ciphers
+equivalent to "<code>-C des-ede3-cbc". The openssl tool lists ciphers
available in "openssl -h" output.
-<div class="node">
+</code><div class="node">
<p><hr>
<a name="ntp_002dkeygen-id_002dkey"></a>Next: <a rel="next" accesskey="n" href="#ntp_002dkeygen-gq_002dparams">ntp-keygen gq-params</a>,
Previous: <a rel="previous" accesskey="p" href="#ntp_002dkeygen-cipher">ntp-keygen cipher</a>,
<p>Set the optional Autokey group name to name. This is used in
the file name of IFF, GQ, and MV client parameters files. In
that role, the default is the host name if this option is not
-provided. The group name, if specified using -i/–ident or
-using -s/–subject-name following an '´character, is also a
-part of the self-signed host certificate's subject and issuer
-names in the form host
- <p>or 'server ident' configuration in ntpd's configuration file.
-<div class="node">
+provided. The group name, if specified using <code>-i/--ident</code> or
+using <code>-s/--subject-name</code> following an '<code>}' character,
+is also a part of the self-signed host certificate's subject and
+issuer names in the form host
+ <p>'crypto ident' or 'server ident' configuration in
+ntpd's configuration file.
+</code><div class="node">
<p><hr>
<a name="ntp_002dkeygen-lifetime"></a>Next: <a rel="next" accesskey="n" href="#ntp_002dkeygen-md5key">ntp-keygen md5key</a>,
Previous: <a rel="previous" accesskey="p" href="#ntp_002dkeygen-ident">ntp-keygen ident</a>,
<h4 class="subsection">lifetime option (-l)</h4>
<p><a name="index-ntp_002dkeygen_002dlifetime-12"></a>
-This is the “set certificate lifetime” option.
+This is the ``set certificate lifetime'' option.
This option takes an argument number <span class="file">lifetime</span>.
<p class="noindent">This option has some usage constraints. It:
<h4 class="subsection">md5key option (-M)</h4>
<p><a name="index-ntp_002dkeygen_002dmd5key-13"></a>
-This is the “generate md5 keys” option.
+This is the ``generate md5 keys'' option.
Generate MD5 keys, obsoleting any that may exist.
<div class="node">
<p><hr>
<h4 class="subsection">modulus option (-m)</h4>
<p><a name="index-ntp_002dkeygen_002dmodulus-14"></a>
-This is the “modulus” option.
+This is the ``modulus'' option.
This option takes an argument number <span class="file">modulus</span>.
<p class="noindent">This option has some usage constraints. It:
<h4 class="subsection">pvt-cert option (-P)</h4>
<p><a name="index-ntp_002dkeygen_002dpvt_002dcert-15"></a>
-This is the “generate pc private certificate” option.
+This is the ``generate pc private certificate'' option.
<p class="noindent">This option has some usage constraints. It:
<ul>
<h4 class="subsection">pvt-passwd option (-p)</h4>
<p><a name="index-ntp_002dkeygen_002dpvt_002dpasswd-16"></a>
-This is the “output private password” option.
+This is the ``output private password'' option.
This option takes an argument string <span class="file">passwd</span>.
<p class="noindent">This option has some usage constraints. It:
</ul>
<p>Encrypt generated files containing private data with the specified
-password and the cipher selected with -C/–cipher.
+password and the cipher selected with <code>-C/--cipher</code>.
<div class="node">
<p><hr>
<a name="ntp_002dkeygen-get_002dpvt_002dpasswd"></a>Next: <a rel="next" accesskey="n" href="#ntp_002dkeygen-sign_002dkey">ntp-keygen sign-key</a>,
<h4 class="subsection">get-pvt-passwd option (-q)</h4>
<p><a name="index-ntp_002dkeygen_002dget_002dpvt_002dpasswd-17"></a>
-This is the “input private password” option.
+This is the ``input private password'' option.
This option takes an argument string <span class="file">passwd</span>.
<p class="noindent">This option has some usage constraints. It:
<h4 class="subsection">sign-key option (-S)</h4>
<p><a name="index-ntp_002dkeygen_002dsign_002dkey-18"></a>
-This is the “generate sign key (rsa or dsa)” option.
+This is the ``generate sign key (rsa or dsa)'' option.
This option takes an argument string <span class="file">sign</span>.
<p class="noindent">This option has some usage constraints. It:
<h4 class="subsection">subject-name option (-s)</h4>
<p><a name="index-ntp_002dkeygen_002dsubject_002dname-19"></a>
-This is the “set host and optionally group name” option.
+This is the ``set host and optionally group name'' option.
This option takes an argument string <span class="file">host@group</span>.
<p class="noindent">This option has some usage constraints. It:
</ul>
<p>Set the Autokey host name, and optionally, group name specified
-following an '´character. The host name is used in the file
+following an '<code>}' character. The host name is used in the file
name of generated host and signing certificates, without the
group name. The host name, and if provided, group name are used
in host
- <p>fields. Specifying '-s is allowed, and results in
-leaving the host name unchanged while appending
+ <p>fields. Specifying '-s
+ <p>leaving the host name unchanged while appending
<p>subject and issuer fields, as with -i group. The group name, or
if not provided, the host name are also used in the file names
of IFF, GQ, and MV client parameter files.
-<div class="node">
+</code><div class="node">
<p><hr>
<a name="ntp_002dkeygen-trusted_002dcert"></a>Next: <a rel="next" accesskey="n" href="#ntp_002dkeygen-mv_002dparams">ntp-keygen mv-params</a>,
Previous: <a rel="previous" accesskey="p" href="#ntp_002dkeygen-subject_002dname">ntp-keygen subject-name</a>,
<h4 class="subsection">trusted-cert option (-T)</h4>
<p><a name="index-ntp_002dkeygen_002dtrusted_002dcert-20"></a>
-This is the “trusted certificate (tc scheme)” option.
+This is the ``trusted certificate (tc scheme)'' option.
<p class="noindent">This option has some usage constraints. It:
<ul>
<h4 class="subsection">mv-params option (-V)</h4>
<p><a name="index-ntp_002dkeygen_002dmv_002dparams-21"></a>
-This is the “generate <num> mv parameters” option.
+This is the ``generate <num> mv parameters'' option.
This option takes an argument number <span class="file">num</span>.
<p class="noindent">This option has some usage constraints. It:
<h4 class="subsection">mv-keys option (-v)</h4>
<p><a name="index-ntp_002dkeygen_002dmv_002dkeys-22"></a>
-This is the “update <num> mv keys” option.
+This is the ``update <num> mv keys'' option.
This option takes an argument number <span class="file">num</span>.
<p class="noindent">This option has some usage constraints. It:
<h4 class="subsection">ntp-keygen Usage</h4>
<p>The
-<code>-p</code> <code>-Ar</code> <code>-password</code> option specifies the write password and
-<code>-q</code> <code>-Ar</code> <code>-password</code> option the read password for previously encrypted files.
+<code>-p</code> <code>-password</code> option specifies the write password and
+<code>-q</code> <code>-password</code> option the read password for previously encrypted files.
The
<code>ntp-keygen</code>
program prompts for the password if it reads an encrypted file
<p>All cryptographically sound key generation schemes must have means to
randomize the entropy seed used to initialize the internal
-pseudo-random number generator used by the OpenSSL library routines. If
-a site supports ssh, it is very likely that means to do this are
-already available. The entropy seed used by the OpenSSL library is
-contained in a file, usually called .rnd, which must be available when
-starting the ntp-keygen program or ntpd daemon.
+pseudo-random number generator used by the OpenSSL library routines.
+If a site supports ssh, it is very likely that means to do this are
+already available.
+The entropy seed used by the OpenSSL library is contained in a file,
+usually called <code>.rnd</code>, which must be available when
+starting the <code>ntp-keygen</code> program or <code>ntpd</code> daemon.
<p>The OpenSSL library looks for the file using the path specified by the
-RANDFILE environment variable in the user home directory, whether root
-or some other user. If the RANDFILE environment variable is not
-present, the library looks for the .rnd file in the user home
-directory. Since both the ntp-keygen program and ntpd daemon must run
-as root, the logical place to put this file is in /.rnd or /root/.rnd.
+<code>RANDFILE</code> environment variable in the user home directory, whether root
+or some other user.
+If the <code>RANDFILE</code> environment variable is not
+present, the library looks for the <code>.rnd</code> file in the user home
+directory.
+Since both the <code>ntp-keygen</code> program and <code>ntpd</code> daemon must run
+as root, the logical place to put this file is in <code>/.rnd</code> or
+<code>/root/.rnd</code>.
If the file is not available or cannot be written, the program exits
with a message to the system log.
<!-- node-name, next, previous, up -->
<h3 class="section">Cryptographic Data Files</h3>
- <p>File and link names are in the form ntpkey_key_name.fstamp, where key
-is the key or parameter type, name is the host or group name and fstamp
-is the filestamp (NTP seconds) when the file was created). By
-convention, key names in generated file names include both upper and
+ <p>File and link names are in the <code>form ntpkey_key_name.fstamp</code>,
+where <code>key</code> is the key or parameter type,
+<code>name</code> is the host or group name and
+<code>fstamp</code> is the filestamp (NTP seconds) when the file was created).
+By convention, key names in generated file names include both upper and
lower case characters, while key names in generated link names include
only lower case characters. The filestamp is not used in generated link
names.
- <p>The key name is a string defining the cryptographic key type. Key types
-include public/private keys host and sign, certificate cert and several
-challenge/response key types. By convention, client files used for
+ <p>The key name is a string defining the cryptographic key type.
+Key types include public/private keys host and sign, certificate cert
+and several challenge/response key types.
+By convention, client files used for
challenges have a par subtype, as in the IFF challenge IFFpar, while
server files for responses have a key subtype, as in the GQ response
GQkey.
<p>All files begin with two nonencrypted lines. The first line contains
-the file name in the format ntpkey_key_host.fstamp. The second line
-contains the datestamp in conventional Unix date format. Lines
-beginning with # are ignored.
+the file name in the format <code>ntpkey_key_host.fstamp</code>.
+The second line contains the datestamp in conventional Unix date format.
+Lines beginning with <code>#</code> are ignored.
<p>The remainder of the file contains cryptographic data encoded first
using ASN.1 rules, then encrypted using the DES-CBC algorithm with
given password and finally written in PEM-encoded printable ASCII text
preceded and followed by MIME content identifier lines.
- <p>The format of the symmetric keys file, ordinarily named ntp.keys, is
-somewhat different than the other files in the interest of backward
-compatibility. Ordinarily, the file is generated by this program, but
+ <p>The format of the symmetric keys file, ordinarily named <code>ntp.keys</code>,
+is somewhat different than the other files in the interest of backward
+compatibility.
+Ordinarily, the file is generated by this program, but
it can be constructed and edited using an ordinary text editor.
<pre class="example"> # ntpkey_MD5key_hms.local.3564038757
<p>Figure 1. Typical Symmetric Key File
<p>Figure 1 shows a typical symmetric keys file used by the reference
-implementation. Each line of the file contains three fields, first an
+implementation.
+Each line of the file contains three fields, first an
integer between 1 and 65534, inclusive, representing the key identifier
-used in the server and peer configuration commands. Next is the key
-type for the message digest algorithm, which in the absence of the
+used in the server and peer configuration commands.
+Next is the key type for the message digest algorithm,
+which in the absence of the
OpenSSL library must be MD5 to designate the MD5 message digest
-algorithm. If the OpenSSL library is installed, the key type can be any
-message digest algorithm supported by that library. However, if
+algorithm.
+If the OpenSSL library is installed, the key type can be any
+message digest algorithm supported by that library.
+However, if
compatibility with FIPS 140-2 is required, the key type must be either
-SHA or SHA1. The key type can be changed using an ASCII text editor.
+SHA or SHA1.
+The key type can be changed using an ASCII text editor.
<p>An MD5 key consists of a printable ASCII string less than or equal to
-16 characters and terminated by whitespace or a # character. An OpenSSL
+16 characters and terminated by whitespace or a # character.
+An OpenSSL
key consists of a hex-encoded ASCII string of 40 characters, which is
truncated as necessary.
- <p>Note that the keys used by the ntpq and ntpdc programs are checked
-against passwords requested by the programs and entered by hand, so it
+ <p>Note that the keys used by the <code>ntpq</code> and <code>ntpdc</code> programs are
+checked against passwords requested by the programs and entered by hand,
+so it
is generally appropriate to specify these keys in human readable ASCII
format.
<p>The <code>ntp-keygen</code> program generates a MD5 symmetric keys file
-<code>ntpkey_MD5key_hostname.filestamp</code>. Since the file contains private
+<code>ntpkey_MD5key_hostname.filestamp</code>.
+Since the file contains private
shared keys, it should be visible only to root and distributed by
-secure means to other subnet hosts. The NTP daemon loads the file
-<code>ntp.keys</code>, so <code>ntp-keygen</code> installs a soft link from this name to the
-generated file. Subsequently, similar soft links must be installed by
-manual or automated means on the other subnet hosts. While this file is
+secure means to other subnet hosts.
+The NTP daemon loads the file <code>ntp.keys</code>, so <code>ntp-keygen</code>
+installs a soft link from this name to the generated file.
+Subsequently, similar soft links must be installed by
+manual or automated means on the other subnet hosts.
+While this file is
not used with the Autokey Version 2 protocol, it is needed to
authenticate some remote configuration commands used by the <code>ntpq</code> and
<code>ntpdc</code> utilities.
-.TH ntp-keygen @NTP_KEYGEN_MS@ "24 Dec 2012" "ntp (4.2.7p337)" "User Commands"
+.TH ntp-keygen @NTP_KEYGEN_MS@ "25 Dec 2012" "ntp (4.2.7p338)" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.man)
.\"
-.\" It has been AutoGen-ed December 24, 2012 at 12:08:20 PM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:40 AM by AutoGen 5.16.2
.\" From the definitions ntp-keygen-opts.def
.\" and the template file agman-cmd.tpl
.\"
All arguments must be options.
.PP
.SH DESCRIPTION
-This program generates cryptographic data files used by the NTPv4
-authentication and identification schemes.
-It generates MD5 key files used in symmetric key cryptography.
-In addition, if the OpenSSL software library has been installed,
-it generates keys, certificate and identity files used in public key
-cryptography.
-These files are used for cookie encryption,
-digital signature and challenge/response identification algorithms
-compatible with the Internet standard security infrastructure.
-.PP
-All files are in PEM-encoded printable ASCII format,
-so they can be embedded as MIME attachments in mail to other sites
-and certificate authorities.
-By default, files are not encrypted.
-.PP
-When used to generate message digest keys, the program produces a file
-containing ten pseudo-random printable ASCII strings suitable for the
-MD5 message digest algorithm included in the distribution.
-If the OpenSSL library is installed, it produces an additional ten
-hex-encoded random bit strings suitable for the SHA1 and other message
-digest algorithms.
-The message digest keys file must be distributed and stored
-using secure means beyond the scope of NTP itself.
-Besides the keys used for ordinary NTP associations, additional keys
-can be defined as passwords for the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-utility programs.
-.PP
-The remaining generated files are compatible with other OpenSSL
-applications and other Public Key Infrastructure (PKI) resources.
-Certificates generated by this program are compatible with extant
-industry practice, although some users might find the interpretation of
-X509v3 extension fields somewhat liberal.
-However, the identity keys are probably not compatible with anything
-other than Autokey.
-.PP
-Some files used by this program are encrypted using a private password.
-The
-p
-option specifies the password for local encrypted files and the
-q
-option the password for encrypted files sent to remote sites.
-If no password is specified, the host name returned by the Unix
-.Fn gethostname
-function, normally the DNS name of the host is used.
-.PP
-The
-\fIpw\fR
-option of the
-\fIcrypto\fR
-configuration command specifies the read
-password for previously encrypted local files.
-This must match the local password used by this program.
-If not specified, the host name is used.
-Thus, if files are generated by this program without password,
-they can be read back by
-\fIntpd\fR
-without password but only on the same host.
-.PP
-Normally, encrypted files for each host are generated by that host and
-used only by that host, although exceptions exist as noted later on
-this page.
-The symmetric keys file, normally called
-\fIntp.keys ,\fR
-is usually installed in
-.Pa /etc .
-Other files and links are usually installed in
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem in
-NFS-mounted networks and cannot be changed by shared clients.
-The location of the keys directory can be changed by the
-\fIkeysdir\fR
-configuration command in such cases.
-Normally, this is in
-.Pa /etc .
-.PP
-This program directs commentary and error messages to the standard
-error stream
-\fIstderr\fR
-and remote files to the standard output stream
-\fIstdout\fR
-where they can be piped to other applications or redirected to files.
-The names used for generated files and links all begin with the
-string
-\fIntpkey\fR
-and include the file type, generating host and filestamp,
-as described in the
-.Dq Cryptographic Data Files
-section below.
-.SS Running the Program
-To test and gain experience with Autokey concepts, log in as root and
-change to the keys directory, usually
-.Pa /usr/local/etc
-When run for the first time, or if all files with names beginning with
-\fIntpkey\fR
-have been removed, use the
-.B
-command without arguments to generate a
-default RSA host key and matching RSA-MD5 certificate with expiration
-date one year hence.
-If run again without options, the program uses the
-existing keys and parameters and generates only a new certificate with
-new expiration date one year hence.
-.PP
-Run the command on as many hosts as necessary.
-Designate one of them as the trusted host (TH) using
-.B
-with the
-T
-option and configure it to synchronize from reliable Internet servers.
-Then configure the other hosts to synchronize to the TH directly or
-indirectly.
-A certificate trail is created when Autokey asks the immediately
-ascendant host towards the TH to sign its certificate, which is then
-provided to the immediately descendant host on request.
-All group hosts should have acyclic certificate trails ending on the TH.
-.PP
-The host key is used to encrypt the cookie when required and so must be
-RSA type.
-By default, the host key is also the sign key used to encrypt
-signatures.
-A different sign key can be assigned using the
-S
-option and this can be either RSA or DSA type.
-By default, the signature
-message digest type is MD5, but any combination of sign key type and
-message digest type supported by the OpenSSL library can be specified
-using the
-c
-option.
-The rules say cryptographic media should be generated with proventic
-filestamps, which means the host should already be synchronized before
-this program is run.
-This of course creates a chicken-and-egg problem
-when the host is started for the first time.
-Accordingly, the host time
-should be set by some other means, such as eyeball-and-wristwatch, at
-least so that the certificate lifetime is within the current year.
-After that and when the host is synchronized to a proventic source, the
-certificate should be re-generated.
-.PP
-Additional information on trusted groups and identity schemes is on the
-.Dq Autokey Public-Key Authentication
-page.
-.PP
-The
-.Xr ntpd @NTPD_MS@
-configuration command
-.Ic crypto pw Ar password
-specifies the read password for previously encrypted files.
-The daemon expires on the spot if the password is missing
-or incorrect.
-For convenience, if a file has been previously encrypted,
-the default read password is the name of the host running
-the program.
-If the previous write password is specified as the host name,
-these files can be read by that host with no explicit password.
-.PP
-File names begin with the prefix
-.Cm ntpkey_
-and end with the postfix
-\fI_hostname.filestamp ,\fR
-where
-\fIhostname\fR
-is the owner name, usually the string returned
-by the Unix gethostname() routine, and
-\fIfilestamp\fR
-is the NTP seconds when the file was generated, in decimal digits.
-This both guarantees uniqueness and simplifies maintenance
-procedures, since all files can be quickly removed
-by a
-.Ic rm ntpkey\&*
-command or all files generated
-at a specific time can be removed by a
-.Ic rm
-\fI\&*filestamp\fR
-command.
-To further reduce the risk of misconfiguration,
-the first two lines of a file contain the file name
-and generation date and time as comments.
-.PP
-All files are installed by default in the keys directory
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem
-in NFS-mounted networks.
-The actual location of the keys directory
-and each file can be overridden by configuration commands,
-but this is not recommended.
-Normally, the files for each host are generated by that host
-and used only by that host, although exceptions exist
-as noted later on this page.
-.PP
-Normally, files containing private values,
-including the host key, sign key and identification parameters,
-are permitted root read/write-only;
-while others containing public values are permitted world readable.
-Alternatively, files containing private values can be encrypted
-and these files permitted world readable,
-which simplifies maintenance in shared file systems.
-Since uniqueness is insured by the hostname and
-file name extensions, the files for a NFS server and
-dependent clients can all be installed in the same shared directory.
-.PP
-The recommended practice is to keep the file name extensions
-when installing a file and to install a soft link
-from the generic names specified elsewhere on this page
-to the generated files.
-This allows new file generations to be activated simply
-by changing the link.
-If a link is present, ntpd follows it to the file name
-to extract the filestamp.
-If a link is not present,
-.Xr ntpd @NTPD_MS@
-extracts the filestamp from the file itself.
-This allows clients to verify that the file and generation times
-are always current.
-The
-.B
-program uses the same timestamp extension for all files generated
-at one time, so each generation is distinct and can be readily
-recognized in monitoring data.
-.SS Running the program
-The safest way to run the
-.B
-program is logged in directly as root.
-The recommended procedure is change to the keys directory,
-usually
-.Pa /usr/local/etc ,
-then run the program.
-When run for the first time,
-or if all
-.Cm ntpkey
-files have been removed,
-the program generates a RSA host key file and matching RSA-MD5 certificate file,
-which is all that is necessary in many cases.
-The program also generates soft links from the generic names
-to the respective files.
-If run again, the program uses the same host key file,
-but generates a new certificate file and link.
-.PP
-The host key is used to encrypt the cookie when required and so must be RSA type.
-By default, the host key is also the sign key used to encrypt signatures.
-When necessary, a different sign key can be specified and this can be
-either RSA or DSA type.
-By default, the message digest type is MD5, but any combination
-of sign key type and message digest type supported by the OpenSSL library
-can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
-and RIPE160 message digest algorithms.
-However, the scheme specified in the certificate must be compatible
-with the sign key.
-Certificates using any digest algorithm are compatible with RSA sign keys;
-however, only SHA and SHA1 certificates are compatible with DSA sign keys.
-.PP
-Private/public key files and certificates are compatible with
-other OpenSSL applications and very likely other libraries as well.
-Certificates or certificate requests derived from them should be compatible
-with extant industry practice, although some users might find
-the interpretation of X509v3 extension fields somewhat liberal.
-However, the identification parameter files, although encoded
-as the other files, are probably not compatible with anything other than Autokey.
-.PP
-Running the program as other than root and using the Unix
-.Ic su
-command
-to assume root may not work properly, since by default the OpenSSL library
-looks for the random seed file
-.Cm .rnd
-in the user home directory.
-However, there should be only one
-.Cm .rnd ,
-most conveniently
-in the root directory, so it is convenient to define the
-.Cm $RANDFILE
-environment variable used by the OpenSSL library as the path to
-.Cm /.rnd .
-.PP
-Installing the keys as root might not work in NFS-mounted
-shared file systems, as NFS clients may not be able to write
-to the shared keys directory, even as root.
-In this case, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-command.
-There is no need for one client to read the keys and certificates
-of other clients or servers, as these data are obtained automatically
-by the Autokey protocol.
-.PP
-Ordinarily, cryptographic files are generated by the host that uses them,
-but it is possible for a trusted agent (TA) to generate these files
-for other hosts; however, in such cases files should always be encrypted.
-The subject name and trusted name default to the hostname
-of the host generating the files, but can be changed by command line options.
-It is convenient to designate the owner name and trusted name
-as the subject and issuer fields, respectively, of the certificate.
-The owner name is also used for the host and sign key files,
-while the trusted name is used for the identity files.
-.PP
-All files are installed by default in the keys directory
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem
-in NFS-mounted networks.
-The actual location of the keys directory
-and each file can be overridden by configuration commands,
-but this is not recommended.
-Normally, the files for each host are generated by that host
-and used only by that host, although exceptions exist
-as noted later on this page.
-.PP
-Normally, files containing private values,
-including the host key, sign key and identification parameters,
-are permitted root read/write-only;
-while others containing public values are permitted world readable.
-Alternatively, files containing private values can be encrypted
-and these files permitted world readable,
-which simplifies maintenance in shared file systems.
-Since uniqueness is insured by the hostname and
-file name extensions, the files for a NFS server and
-dependent clients can all be installed in the same shared directory.
-.PP
-The recommended practice is to keep the file name extensions
-when installing a file and to install a soft link
-from the generic names specified elsewhere on this page
-to the generated files.
-This allows new file generations to be activated simply
-by changing the link.
-If a link is present, ntpd follows it to the file name
-to extract the filestamp.
-If a link is not present,
-.Xr ntpd @NTPD_MS@
-extracts the filestamp from the file itself.
-This allows clients to verify that the file and generation times
-are always current.
-The
-.B
-program uses the same timestamp extension for all files generated
-at one time, so each generation is distinct and can be readily
-recognized in monitoring data.
-.SS Running the program
-The safest way to run the
-.B
-program is logged in directly as root.
-The recommended procedure is change to the keys directory,
-usually
-.Pa /usr/local/etc ,
-then run the program.
-When run for the first time,
-or if all
-.Cm ntpkey
-files have been removed,
-the program generates a RSA host key file and matching RSA-MD5 certificate file,
-which is all that is necessary in many cases.
-The program also generates soft links from the generic names
-to the respective files.
-If run again, the program uses the same host key file,
-but generates a new certificate file and link.
-.PP
-The host key is used to encrypt the cookie when required and so must be RSA type.
-By default, the host key is also the sign key used to encrypt signatures.
-When necessary, a different sign key can be specified and this can be
-either RSA or DSA type.
-By default, the message digest type is MD5, but any combination
-of sign key type and message digest type supported by the OpenSSL library
-can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
-and RIPE160 message digest algorithms.
-However, the scheme specified in the certificate must be compatible
-with the sign key.
-Certificates using any digest algorithm are compatible with RSA sign keys;
-however, only SHA and SHA1 certificates are compatible with DSA sign keys.
-.PP
-Private/public key files and certificates are compatible with
-other OpenSSL applications and very likely other libraries as well.
-Certificates or certificate requests derived from them should be compatible
-with extant industry practice, although some users might find
-the interpretation of X509v3 extension fields somewhat liberal.
-However, the identification parameter files, although encoded
-as the other files, are probably not compatible with anything other than Autokey.
-.PP
-Running the program as other than root and using the Unix
-.Ic su
-command
-to assume root may not work properly, since by default the OpenSSL library
-looks for the random seed file
-.Cm .rnd
-in the user home directory.
-However, there should be only one
-.Cm .rnd ,
-most conveniently
-in the root directory, so it is convenient to define the
-.Cm $RANDFILE
-environment variable used by the OpenSSL library as the path to
-.Cm /.rnd .
-.PP
-Installing the keys as root might not work in NFS-mounted
-shared file systems, as NFS clients may not be able to write
-to the shared keys directory, even as root.
-In this case, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-command.
-There is no need for one client to read the keys and certificates
-of other clients or servers, as these data are obtained automatically
-by the Autokey protocol.
-.PP
-Ordinarily, cryptographic files are generated by the host that uses them,
-but it is possible for a trusted agent (TA) to generate these files
-for other hosts; however, in such cases files should always be encrypted.
-The subject name and trusted name default to the hostname
-of the host generating the files, but can be changed by command line options.
-It is convenient to designate the owner name and trusted name
-as the subject and issuer fields, respectively, of the certificate.
-The owner name is also used for the host and sign key files,
-while the trusted name is used for the identity files.
-seconds.
-seconds.
-s Trusted Hosts and Groups
-Each cryptographic configuration involves selection of a signature scheme
-and identification scheme, called a cryptotype,
-as explained in the
-.Sx Authentication Options
-section of
-.Xr ntp.conf 5 .
-The default cryptotype uses RSA encryption, MD5 message digest
-and TC identification.
-First, configure a NTP subnet including one or more low-stratum
-trusted hosts from which all other hosts derive synchronization
-directly or indirectly.
-Trusted hosts have trusted certificates;
-all other hosts have nontrusted certificates.
-These hosts will automatically and dynamically build authoritative
-certificate trails to one or more trusted hosts.
-A trusted group is the set of all hosts that have, directly or indirectly,
-a certificate trail ending at a trusted host.
-The trail is defined by static configuration file entries
-or dynamic means described on the
-.Sx Automatic NTP Configuration Options
-section of
-.Xr ntp.conf 5 .
-.PP
-On each trusted host as root, change to the keys directory.
-To insure a fresh fileset, remove all
-.Cm ntpkey
-files.
-Then run
-.B
-T
-to generate keys and a trusted certificate.
-On all other hosts do the same, but leave off the
-T
-flag to generate keys and nontrusted certificates.
-When complete, start the NTP daemons beginning at the lowest stratum
-and working up the tree.
-It may take some time for Autokey to instantiate the certificate trails
-throughout the subnet, but setting up the environment is completely automatic.
-.PP
-If it is necessary to use a different sign key or different digest/signature
-scheme than the default, run
-.B
-with the
-S Ar type
-option, where
-\fItype\fR
-is either
-.Cm RSA
-or
-.Cm DSA .
-The most often need to do this is when a DSA-signed certificate is used.
-If it is necessary to use a different certificate scheme than the default,
-run
-.B
-with the
-c Ar scheme
-option and selected
-\fIscheme\fR
-as needed.
-f
-.B
-is run again without these options, it generates a new certificate
-using the same scheme and sign key.
-.PP
-After setting up the environment it is advisable to update certificates
-from time to time, if only to extend the validity interval.
-Simply run
-.B
-with the same flags as before to generate new certificates
-using existing keys.
-However, if the host or sign key is changed,
-.Xr ntpd @NTPD_MS@
-should be restarted.
-When
-.Xr ntpd @NTPD_MS@
-is restarted, it loads any new files and restarts the protocol.
-Other dependent hosts will continue as usual until signatures are refreshed,
-at which time the protocol is restarted.
-.SS Identity Schemes
-As mentioned on the Autonomous Authentication page,
-the default TC identity scheme is vulnerable to a middleman attack.
-However, there are more secure identity schemes available,
-including PC, IFF, GQ and MV described on the
-.Qq Identification Schemes
-page
-(maybe available at
-.Li http://www.eecis.udel.edu/%7emills/keygen.html ) .
-These schemes are based on a TA, one or more trusted hosts
-and some number of nontrusted hosts.
-Trusted hosts prove identity using values provided by the TA,
-while the remaining hosts prove identity using values provided
-by a trusted host and certificate trails that end on that host.
-The name of a trusted host is also the name of its sugroup
-and also the subject and issuer name on its trusted certificate.
-The TA is not necessarily a trusted host in this sense, but often is.
-.PP
-In some schemes there are separate keys for servers and clients.
-A server can also be a client of another server,
-but a client can never be a server for another client.
-In general, trusted hosts and nontrusted hosts that operate
-as both server and client have parameter files that contain
-both server and client keys.
-Hosts that operate
-only as clients have key files that contain only client keys.
-.PP
-The PC scheme supports only one trusted host in the group.
-On trusted host alice run
-.B
-P
-p Ar password
-to generate the host key file
-.Pa ntpkey_RSAkey_ Ns Ar alice.filestamp
-and trusted private certificate file
-.Pa ntpkey_RSA-MD5_cert_ Ns Ar alice.filestamp .
-Copy both files to all group hosts;
-they replace the files which would be generated in other schemes.
-On each host bob install a soft link from the generic name
-.Pa ntpkey_host_ Ns Ar bob
-to the host key file and soft link
-.Pa ntpkey_cert_ Ns Ar bob
-to the private certificate file.
-Note the generic links are on bob, but point to files generated
-by trusted host alice.
-In this scheme it is not possible to refresh
-either the keys or certificates without copying them
-to all other hosts in the group.
-.PP
-For the IFF scheme proceed as in the TC scheme to generate keys
-and certificates for all group hosts, then for every trusted host in the group,
-generate the IFF parameter file.
-On trusted host alice run
-.B
-T
-I
-p Ar password
-to produce her parameter file
-.Pa ntpkey_IFFpar_ Ns Ar alice.filestamp ,
-which includes both server and client keys.
-Copy this file to all group hosts that operate as both servers
-and clients and install a soft link from the generic
-.Pa ntpkey_iff_ Ns Ar alice
-to this file.
-If there are no hosts restricted to operate only as clients,
-there is nothing further to do.
-As the IFF scheme is independent
-of keys and certificates, these files can be refreshed as needed.
-.PP
-If a rogue client has the parameter file, it could masquerade
-as a legitimate server and present a middleman threat.
-To eliminate this threat, the client keys can be extracted
-from the parameter file and distributed to all restricted clients.
-After generating the parameter file, on alice run
-.B
-e
-and pipe the output to a file or mail program.
-Copy or mail this file to all restricted clients.
-On these clients install a soft link from the generic
-.Pa ntpkey_iff_ Ns Ar alice
-to this file.
-To further protect the integrity of the keys,
-each file can be encrypted with a secret password.
-.PP
-For the GQ scheme proceed as in the TC scheme to generate keys
-and certificates for all group hosts, then for every trusted host
-in the group, generate the IFF parameter file.
-On trusted host alice run
-.B
-T
-G
-p Ar password
-to produce her parameter file
-.Pa ntpkey_GQpar_ Ns Ar alice.filestamp ,
-which includes both server and client keys.
-Copy this file to all group hosts and install a soft link
-from the generic
-.Pa ntpkey_gq_ Ns Ar alice
-to this file.
-In addition, on each host bob install a soft link
-from generic
-.Pa ntpkey_gq_ Ns Ar bob
-to this file.
-As the GQ scheme updates the GQ parameters file and certificate
-at the same time, keys and certificates can be regenerated as needed.
-.PP
-For the MV scheme, proceed as in the TC scheme to generate keys
-and certificates for all group hosts.
-For illustration assume trish is the TA, alice one of several trusted hosts
-and bob one of her clients.
-On TA trish run
-.B
-V Ar n
-p Ar password ,
-where
-\fIn\fR
-is the number of revokable keys (typically 5) to produce
-the parameter file
-.Pa ntpkeys_MVpar_ Ns Ar trish.filestamp
-and client key files
-.Pa ntpkeys_MVkeyd_ Ns Ar trish.filestamp
-where
-\fId\fR
-is the key number (0 \&<
-\fId\fR
-\&<
-\fIn ) .\fR
-Copy the parameter file to alice and install a soft link
-from the generic
-.Pa ntpkey_mv_ Ns Ar alice
-to this file.
-Copy one of the client key files to alice for later distribution
-to her clients.
-It doesn't matter which client key file goes to alice,
-since they all work the same way.
-Alice copies the client key file to all of her cliens.
-On client bob install a soft link from generic
-.Pa ntpkey_mvkey_ Ns Ar bob
-to the client key file.
-As the MV scheme is independent of keys and certificates,
-these files can be refreshed as needed.
-.SS Command Line Options
-.TP
-.BR Fl c Ar scheme
-Select certificate message digest/signature encryption scheme.
-The
-\fIscheme\fR
-can be one of the following:
-. Cm RSA-MD2 , RSA-MD5 , RSA-SHA , RSA-SHA1 , RSA-MDC2 , RSA-RIPEMD160 , DSA-SHA ,
-or
-.Cm DSA-SHA1 .
-Note that RSA schemes must be used with a RSA sign key and DSA
-schemes must be used with a DSA sign key.
-The default without this option is
-.Cm RSA-MD5 .
-.TP
-.BR Fl d
-Enable debugging.
-This option displays the cryptographic data produced in eye-friendly billboards.
-.TP
-.BR Fl e
-Write the IFF client keys to the standard output.
-This is intended for automatic key distribution by mail.
-.TP
-.BR Fl G
-Generate parameters and keys for the GQ identification scheme,
-obsoleting any that may exist.
-.TP
-.BR Fl g
-Generate keys for the GQ identification scheme
-using the existing GQ parameters.
-If the GQ parameters do not yet exist, create them first.
-.TP
-.BR Fl H
-Generate new host keys, obsoleting any that may exist.
-.TP
-.BR Fl I
-Generate parameters for the IFF identification scheme,
-obsoleting any that may exist.
-.TP
-.BR Fl i Ar name
-Set the suject name to
-\fIname .\fR
-This is used as the subject field in certificates
-and in the file name for host and sign keys.
-.TP
-.BR Fl M
-Generate MD5 keys, obsoleting any that may exist.
-.TP
-.BR Fl P
-Generate a private certificate.
-By default, the program generates public certificates.
-.TP
-.BR Fl p Ar password
-Encrypt generated files containing private data with
-\fIpassword\fR
-and the DES-CBC algorithm.
-.TP
-.BR Fl q
-Set the password for reading files to password.
-.TP
-.BR Fl S Oo Cm RSA | DSA Oc
-Generate a new sign key of the designated type,
-obsoleting any that may exist.
-By default, the program uses the host key as the sign key.
-.TP
-.BR Fl s Ar name
-Set the issuer name to
-\fIname .\fR
-This is used for the issuer field in certificates
-and in the file name for identity files.
-.TP
-.BR Fl T
-Generate a trusted certificate.
-By default, the program generates a non-trusted certificate.
-.TP
-.BR Fl V Ar nkeys
-Generate parameters and keys for the Mu-Varadharajan (MV) identification scheme.
-.SS Random Seed File
-All cryptographically sound key generation schemes must have means
-to randomize the entropy seed used to initialize
-the internal pseudo-random number generator used
-by the library routines.
-The OpenSSL library uses a designated random seed file for this purpose.
-The file must be available when starting the NTP daemon and
-.B
-program.
-If a site supports OpenSSL or its companion OpenSSH,
-it is very likely that means to do this are already available.
-.PP
-It is important to understand that entropy must be evolved
-for each generation, for otherwise the random number sequence
-would be predictable.
-Various means dependent on external events, such as keystroke intervals,
-can be used to do this and some systems have built-in entropy sources.
-Suitable means are described in the OpenSSL software documentation,
-but are outside the scope of this page.
-.PP
-The entropy seed used by the OpenSSL library is contained in a file,
-usually called
-.Cm .rnd ,
-which must be available when starting the NTP daemon
-or the
-.B
-program.
-The NTP daemon will first look for the file
-using the path specified by the
-.Ic randfile
-subcommand of the
-.Ic crypto
-configuration command.
-If not specified in this way, or when starting the
-.B
-program,
-the OpenSSL library will look for the file using the path specified
-by the
-.Ev RANDFILE
-environment variable in the user home directory,
-whether root or some other user.
-If the
-.Ev RANDFILE
-environment variable is not present,
-the library will look for the
-.Cm .rnd
-file in the user home directory.
-If the file is not available or cannot be written,
-the daemon exits with a message to the system log and the program
-exits with a suitable error message.
-.SS Cryptographic Data Files
-All other file formats begin with two lines.
-The first contains the file name, including the generated host name
-and filestamp.
-The second contains the datestamp in conventional Unix date format.
-Lines beginning with # are considered comments and ignored by the
-.B
-program and
-.Xr ntpd @NTPD_MS@
-daemon.
-Cryptographic values are encoded first using ASN.1 rules,
-then encrypted if necessary, and finally written PEM-encoded
-printable ASCII format preceded and followed by MIME content identifier lines.
-.PP
-The format of the symmetric keys file is somewhat different
-than the other files in the interest of backward compatibility.
-Since DES-CBC is deprecated in NTPv4, the only key format of interest
-is MD5 alphanumeric strings.
-Following hte heard the keys are
-entered one per line in the format
-.D1 Ar keyno type key
-where
-\fIkeyno\fR
-is a positive integer in the range 1-65,535,
-\fItype\fR
-is the string MD5 defining the key format and
-\fIkey\fR
-is the key itself,
-which is a printable ASCII string 16 characters or less in length.
-Each character is chosen from the 93 printable characters
-in the range 0x21 through 0x7f excluding space and the
-.Ql #
-character.
-.PP
-Note that the keys used by the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-programs
-are checked against passwords requested by the programs
-and entered by hand, so it is generally appropriate to specify these keys
-in human readable ASCII format.
-.PP
-The
-.B
-program generates a MD5 symmetric keys file
-.Pa ntpkey_MD5key_ Ns Ar hostname.filestamp .
-Since the file contains private shared keys,
-it should be visible only to root and distributed by secure means
-to other subnet hosts.
-The NTP daemon loads the file
-.Pa ntp.keys ,
-so
-.B
-installs a soft link from this name to the generated file.
-Subsequently, similar soft links must be installed by manual
-or automated means on the other subnet hosts.
-While this file is not used with the Autokey Version 2 protocol,
-it is needed to authenticate some remote configuration commands
-used by the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-utilities.
.SH "OPTIONS"
.TP
.BR \-b " \fIimbits\fP, " \-\-imbits "=" \fIimbits\fP
If any of these are directories, then the file \fI.ntprc\fP
is searched for within those directories.
.SH USAGE
-The
-p Ar password
-option specifies the write password and
-q Ar password
-option the read password for previously encrypted files.
-The
-.B
-program prompts for the password if it reads an encrypted file
-and the password is missing or incorrect.
-If an encrypted file is read successfully and
-no write password is specified, the read password is used
-as the write password by default.
.SH "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.SH "FILES"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.SH BUGS
-It can take quite a while to generate some cryptographic values,
-from one to several minutes with modern architectures
-such as UltraSPARC and up to tens of minutes to an hour
-with older architectures such as SPARC IPC.
-.PP
-Please report bugs to http://bugs.ntp.org .Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-This document corresponds to version @VERSION@ of NTP.
-Portions of this document came from FreeBSD.
.PP
This manual page was \fIAutoGen\fP-erated from the \fBntp-keygen\fP
option definitions.
-.Dd December 24 2012
+.Dd December 25 2012
.Dt NTP_KEYGEN @NTP_KEYGEN_MS@ User Commands
-.Os FreeBSD 6.4-STABLE
+.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntp-keygen-opts.mdoc)
.\"
-.\" It has been AutoGen-ed December 24, 2012 at 12:08:14 PM by AutoGen 5.16.2
+.\" It has been AutoGen-ed December 25, 2012 at 11:35:47 AM by AutoGen 5.16.2
.\" From the definitions ntp-keygen-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
All arguments must be options.
.Pp
.Sh DESCRIPTION
-This program generates cryptographic data files used by the NTPv4
-authentication and identification schemes.
-It generates MD5 key files used in symmetric key cryptography.
-In addition, if the OpenSSL software library has been installed,
-it generates keys, certificate and identity files used in public key
-cryptography.
-These files are used for cookie encryption,
-digital signature and challenge/response identification algorithms
-compatible with the Internet standard security infrastructure.
-.Pp
-All files are in PEM-encoded printable ASCII format,
-so they can be embedded as MIME attachments in mail to other sites
-and certificate authorities.
-By default, files are not encrypted.
-.Pp
-When used to generate message digest keys, the program produces a file
-containing ten pseudo-random printable ASCII strings suitable for the
-MD5 message digest algorithm included in the distribution.
-If the OpenSSL library is installed, it produces an additional ten
-hex-encoded random bit strings suitable for the SHA1 and other message
-digest algorithms.
-The message digest keys file must be distributed and stored
-using secure means beyond the scope of NTP itself.
-Besides the keys used for ordinary NTP associations, additional keys
-can be defined as passwords for the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-utility programs.
-.Pp
-The remaining generated files are compatible with other OpenSSL
-applications and other Public Key Infrastructure (PKI) resources.
-Certificates generated by this program are compatible with extant
-industry practice, although some users might find the interpretation of
-X509v3 extension fields somewhat liberal.
-However, the identity keys are probably not compatible with anything
-other than Autokey.
-.Pp
-Some files used by this program are encrypted using a private password.
-The
-.Fl p
-option specifies the password for local encrypted files and the
-.Fl q
-option the password for encrypted files sent to remote sites.
-If no password is specified, the host name returned by the Unix
-.Fn gethostname
-function, normally the DNS name of the host is used.
-.Pp
-The
-.Ar pw
-option of the
-.Ar crypto
-configuration command specifies the read
-password for previously encrypted local files.
-This must match the local password used by this program.
-If not specified, the host name is used.
-Thus, if files are generated by this program without password,
-they can be read back by
-.Ar ntpd
-without password but only on the same host.
-.Pp
-Normally, encrypted files for each host are generated by that host and
-used only by that host, although exceptions exist as noted later on
-this page.
-The symmetric keys file, normally called
-.Ar ntp.keys ,
-is usually installed in
-.Pa /etc .
-Other files and links are usually installed in
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem in
-NFS-mounted networks and cannot be changed by shared clients.
-The location of the keys directory can be changed by the
-.Ar keysdir
-configuration command in such cases.
-Normally, this is in
-.Pa /etc .
-.Pp
-This program directs commentary and error messages to the standard
-error stream
-.Ar stderr
-and remote files to the standard output stream
-.Ar stdout
-where they can be piped to other applications or redirected to files.
-The names used for generated files and links all begin with the
-string
-.Ar ntpkey
-and include the file type, generating host and filestamp,
-as described in the
-.Dq Cryptographic Data Files
-section below.
-.Ss Running the Program
-To test and gain experience with Autokey concepts, log in as root and
-change to the keys directory, usually
-.Pa /usr/local/etc
-When run for the first time, or if all files with names beginning with
-.Ar ntpkey
-have been removed, use the
-.Nm
-command without arguments to generate a
-default RSA host key and matching RSA-MD5 certificate with expiration
-date one year hence.
-If run again without options, the program uses the
-existing keys and parameters and generates only a new certificate with
-new expiration date one year hence.
-.Pp
-Run the command on as many hosts as necessary.
-Designate one of them as the trusted host (TH) using
-.Nm
-with the
-.Fl T
-option and configure it to synchronize from reliable Internet servers.
-Then configure the other hosts to synchronize to the TH directly or
-indirectly.
-A certificate trail is created when Autokey asks the immediately
-ascendant host towards the TH to sign its certificate, which is then
-provided to the immediately descendant host on request.
-All group hosts should have acyclic certificate trails ending on the TH.
-.Pp
-The host key is used to encrypt the cookie when required and so must be
-RSA type.
-By default, the host key is also the sign key used to encrypt
-signatures.
-A different sign key can be assigned using the
-.Fl S
-option and this can be either RSA or DSA type.
-By default, the signature
-message digest type is MD5, but any combination of sign key type and
-message digest type supported by the OpenSSL library can be specified
-using the
-.Fl c
-option.
-The rules say cryptographic media should be generated with proventic
-filestamps, which means the host should already be synchronized before
-this program is run.
-This of course creates a chicken-and-egg problem
-when the host is started for the first time.
-Accordingly, the host time
-should be set by some other means, such as eyeball-and-wristwatch, at
-least so that the certificate lifetime is within the current year.
-After that and when the host is synchronized to a proventic source, the
-certificate should be re-generated.
-.Pp
-Additional information on trusted groups and identity schemes is on the
-.Dq Autokey Public-Key Authentication
-page.
-.Pp
-The
-.Xr ntpd @NTPD_MS@
-configuration command
-.Ic crypto pw Ar password
-specifies the read password for previously encrypted files.
-The daemon expires on the spot if the password is missing
-or incorrect.
-For convenience, if a file has been previously encrypted,
-the default read password is the name of the host running
-the program.
-If the previous write password is specified as the host name,
-these files can be read by that host with no explicit password.
-.Pp
-File names begin with the prefix
-.Cm ntpkey_
-and end with the postfix
-.Ar _hostname.filestamp ,
-where
-.Ar hostname
-is the owner name, usually the string returned
-by the Unix gethostname() routine, and
-.Ar filestamp
-is the NTP seconds when the file was generated, in decimal digits.
-This both guarantees uniqueness and simplifies maintenance
-procedures, since all files can be quickly removed
-by a
-.Ic rm ntpkey\&*
-command or all files generated
-at a specific time can be removed by a
-.Ic rm
-.Ar \&*filestamp
-command.
-To further reduce the risk of misconfiguration,
-the first two lines of a file contain the file name
-and generation date and time as comments.
-.Pp
-All files are installed by default in the keys directory
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem
-in NFS-mounted networks.
-The actual location of the keys directory
-and each file can be overridden by configuration commands,
-but this is not recommended.
-Normally, the files for each host are generated by that host
-and used only by that host, although exceptions exist
-as noted later on this page.
-.Pp
-Normally, files containing private values,
-including the host key, sign key and identification parameters,
-are permitted root read/write-only;
-while others containing public values are permitted world readable.
-Alternatively, files containing private values can be encrypted
-and these files permitted world readable,
-which simplifies maintenance in shared file systems.
-Since uniqueness is insured by the hostname and
-file name extensions, the files for a NFS server and
-dependent clients can all be installed in the same shared directory.
-.Pp
-The recommended practice is to keep the file name extensions
-when installing a file and to install a soft link
-from the generic names specified elsewhere on this page
-to the generated files.
-This allows new file generations to be activated simply
-by changing the link.
-If a link is present, ntpd follows it to the file name
-to extract the filestamp.
-If a link is not present,
-.Xr ntpd @NTPD_MS@
-extracts the filestamp from the file itself.
-This allows clients to verify that the file and generation times
-are always current.
-The
-.Nm
-program uses the same timestamp extension for all files generated
-at one time, so each generation is distinct and can be readily
-recognized in monitoring data.
-.Ss Running the program
-The safest way to run the
-.Nm
-program is logged in directly as root.
-The recommended procedure is change to the keys directory,
-usually
-.Pa /usr/local/etc ,
-then run the program.
-When run for the first time,
-or if all
-.Cm ntpkey
-files have been removed,
-the program generates a RSA host key file and matching RSA-MD5 certificate file,
-which is all that is necessary in many cases.
-The program also generates soft links from the generic names
-to the respective files.
-If run again, the program uses the same host key file,
-but generates a new certificate file and link.
-.Pp
-The host key is used to encrypt the cookie when required and so must be RSA type.
-By default, the host key is also the sign key used to encrypt signatures.
-When necessary, a different sign key can be specified and this can be
-either RSA or DSA type.
-By default, the message digest type is MD5, but any combination
-of sign key type and message digest type supported by the OpenSSL library
-can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
-and RIPE160 message digest algorithms.
-However, the scheme specified in the certificate must be compatible
-with the sign key.
-Certificates using any digest algorithm are compatible with RSA sign keys;
-however, only SHA and SHA1 certificates are compatible with DSA sign keys.
-.Pp
-Private/public key files and certificates are compatible with
-other OpenSSL applications and very likely other libraries as well.
-Certificates or certificate requests derived from them should be compatible
-with extant industry practice, although some users might find
-the interpretation of X509v3 extension fields somewhat liberal.
-However, the identification parameter files, although encoded
-as the other files, are probably not compatible with anything other than Autokey.
-.Pp
-Running the program as other than root and using the Unix
-.Ic su
-command
-to assume root may not work properly, since by default the OpenSSL library
-looks for the random seed file
-.Cm .rnd
-in the user home directory.
-However, there should be only one
-.Cm .rnd ,
-most conveniently
-in the root directory, so it is convenient to define the
-.Cm $RANDFILE
-environment variable used by the OpenSSL library as the path to
-.Cm /.rnd .
-.Pp
-Installing the keys as root might not work in NFS-mounted
-shared file systems, as NFS clients may not be able to write
-to the shared keys directory, even as root.
-In this case, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-command.
-There is no need for one client to read the keys and certificates
-of other clients or servers, as these data are obtained automatically
-by the Autokey protocol.
-.Pp
-Ordinarily, cryptographic files are generated by the host that uses them,
-but it is possible for a trusted agent (TA) to generate these files
-for other hosts; however, in such cases files should always be encrypted.
-The subject name and trusted name default to the hostname
-of the host generating the files, but can be changed by command line options.
-It is convenient to designate the owner name and trusted name
-as the subject and issuer fields, respectively, of the certificate.
-The owner name is also used for the host and sign key files,
-while the trusted name is used for the identity files.
-.Pp
-All files are installed by default in the keys directory
-.Pa /usr/local/etc ,
-which is normally in a shared filesystem
-in NFS-mounted networks.
-The actual location of the keys directory
-and each file can be overridden by configuration commands,
-but this is not recommended.
-Normally, the files for each host are generated by that host
-and used only by that host, although exceptions exist
-as noted later on this page.
-.Pp
-Normally, files containing private values,
-including the host key, sign key and identification parameters,
-are permitted root read/write-only;
-while others containing public values are permitted world readable.
-Alternatively, files containing private values can be encrypted
-and these files permitted world readable,
-which simplifies maintenance in shared file systems.
-Since uniqueness is insured by the hostname and
-file name extensions, the files for a NFS server and
-dependent clients can all be installed in the same shared directory.
-.Pp
-The recommended practice is to keep the file name extensions
-when installing a file and to install a soft link
-from the generic names specified elsewhere on this page
-to the generated files.
-This allows new file generations to be activated simply
-by changing the link.
-If a link is present, ntpd follows it to the file name
-to extract the filestamp.
-If a link is not present,
-.Xr ntpd @NTPD_MS@
-extracts the filestamp from the file itself.
-This allows clients to verify that the file and generation times
-are always current.
-The
-.Nm
-program uses the same timestamp extension for all files generated
-at one time, so each generation is distinct and can be readily
-recognized in monitoring data.
-.Ss Running the program
-The safest way to run the
-.Nm
-program is logged in directly as root.
-The recommended procedure is change to the keys directory,
-usually
-.Pa /usr/local/etc ,
-then run the program.
-When run for the first time,
-or if all
-.Cm ntpkey
-files have been removed,
-the program generates a RSA host key file and matching RSA-MD5 certificate file,
-which is all that is necessary in many cases.
-The program also generates soft links from the generic names
-to the respective files.
-If run again, the program uses the same host key file,
-but generates a new certificate file and link.
-.Pp
-The host key is used to encrypt the cookie when required and so must be RSA type.
-By default, the host key is also the sign key used to encrypt signatures.
-When necessary, a different sign key can be specified and this can be
-either RSA or DSA type.
-By default, the message digest type is MD5, but any combination
-of sign key type and message digest type supported by the OpenSSL library
-can be specified, including those using the MD2, MD5, SHA, SHA1, MDC2
-and RIPE160 message digest algorithms.
-However, the scheme specified in the certificate must be compatible
-with the sign key.
-Certificates using any digest algorithm are compatible with RSA sign keys;
-however, only SHA and SHA1 certificates are compatible with DSA sign keys.
-.Pp
-Private/public key files and certificates are compatible with
-other OpenSSL applications and very likely other libraries as well.
-Certificates or certificate requests derived from them should be compatible
-with extant industry practice, although some users might find
-the interpretation of X509v3 extension fields somewhat liberal.
-However, the identification parameter files, although encoded
-as the other files, are probably not compatible with anything other than Autokey.
-.Pp
-Running the program as other than root and using the Unix
-.Ic su
-command
-to assume root may not work properly, since by default the OpenSSL library
-looks for the random seed file
-.Cm .rnd
-in the user home directory.
-However, there should be only one
-.Cm .rnd ,
-most conveniently
-in the root directory, so it is convenient to define the
-.Cm $RANDFILE
-environment variable used by the OpenSSL library as the path to
-.Cm /.rnd .
-.Pp
-Installing the keys as root might not work in NFS-mounted
-shared file systems, as NFS clients may not be able to write
-to the shared keys directory, even as root.
-In this case, NFS clients can specify the files in another
-directory such as
-.Pa /etc
-using the
-.Ic keysdir
-command.
-There is no need for one client to read the keys and certificates
-of other clients or servers, as these data are obtained automatically
-by the Autokey protocol.
-.Pp
-Ordinarily, cryptographic files are generated by the host that uses them,
-but it is possible for a trusted agent (TA) to generate these files
-for other hosts; however, in such cases files should always be encrypted.
-The subject name and trusted name default to the hostname
-of the host generating the files, but can be changed by command line options.
-It is convenient to designate the owner name and trusted name
-as the subject and issuer fields, respectively, of the certificate.
-The owner name is also used for the host and sign key files,
-while the trusted name is used for the identity files.
-seconds.
-seconds.
-s Trusted Hosts and Groups
-Each cryptographic configuration involves selection of a signature scheme
-and identification scheme, called a cryptotype,
-as explained in the
-.Sx Authentication Options
-section of
-.Xr ntp.conf 5 .
-The default cryptotype uses RSA encryption, MD5 message digest
-and TC identification.
-First, configure a NTP subnet including one or more low-stratum
-trusted hosts from which all other hosts derive synchronization
-directly or indirectly.
-Trusted hosts have trusted certificates;
-all other hosts have nontrusted certificates.
-These hosts will automatically and dynamically build authoritative
-certificate trails to one or more trusted hosts.
-A trusted group is the set of all hosts that have, directly or indirectly,
-a certificate trail ending at a trusted host.
-The trail is defined by static configuration file entries
-or dynamic means described on the
-.Sx Automatic NTP Configuration Options
-section of
-.Xr ntp.conf 5 .
-.Pp
-On each trusted host as root, change to the keys directory.
-To insure a fresh fileset, remove all
-.Cm ntpkey
-files.
-Then run
-.Nm
-.Fl T
-to generate keys and a trusted certificate.
-On all other hosts do the same, but leave off the
-.Fl T
-flag to generate keys and nontrusted certificates.
-When complete, start the NTP daemons beginning at the lowest stratum
-and working up the tree.
-It may take some time for Autokey to instantiate the certificate trails
-throughout the subnet, but setting up the environment is completely automatic.
-.Pp
-If it is necessary to use a different sign key or different digest/signature
-scheme than the default, run
-.Nm
-with the
-.Fl S Ar type
-option, where
-.Ar type
-is either
-.Cm RSA
-or
-.Cm DSA .
-The most often need to do this is when a DSA-signed certificate is used.
-If it is necessary to use a different certificate scheme than the default,
-run
-.Nm
-with the
-.Fl c Ar scheme
-option and selected
-.Ar scheme
-as needed.
-f
-.Nm
-is run again without these options, it generates a new certificate
-using the same scheme and sign key.
-.Pp
-After setting up the environment it is advisable to update certificates
-from time to time, if only to extend the validity interval.
-Simply run
-.Nm
-with the same flags as before to generate new certificates
-using existing keys.
-However, if the host or sign key is changed,
-.Xr ntpd @NTPD_MS@
-should be restarted.
-When
-.Xr ntpd @NTPD_MS@
-is restarted, it loads any new files and restarts the protocol.
-Other dependent hosts will continue as usual until signatures are refreshed,
-at which time the protocol is restarted.
-.Ss Identity Schemes
-As mentioned on the Autonomous Authentication page,
-the default TC identity scheme is vulnerable to a middleman attack.
-However, there are more secure identity schemes available,
-including PC, IFF, GQ and MV described on the
-.Qq Identification Schemes
-page
-(maybe available at
-.Li http://www.eecis.udel.edu/%7emills/keygen.html ) .
-These schemes are based on a TA, one or more trusted hosts
-and some number of nontrusted hosts.
-Trusted hosts prove identity using values provided by the TA,
-while the remaining hosts prove identity using values provided
-by a trusted host and certificate trails that end on that host.
-The name of a trusted host is also the name of its sugroup
-and also the subject and issuer name on its trusted certificate.
-The TA is not necessarily a trusted host in this sense, but often is.
-.Pp
-In some schemes there are separate keys for servers and clients.
-A server can also be a client of another server,
-but a client can never be a server for another client.
-In general, trusted hosts and nontrusted hosts that operate
-as both server and client have parameter files that contain
-both server and client keys.
-Hosts that operate
-only as clients have key files that contain only client keys.
-.Pp
-The PC scheme supports only one trusted host in the group.
-On trusted host alice run
-.Nm
-.Fl P
-.Fl p Ar password
-to generate the host key file
-.Pa ntpkey_RSAkey_ Ns Ar alice.filestamp
-and trusted private certificate file
-.Pa ntpkey_RSA-MD5_cert_ Ns Ar alice.filestamp .
-Copy both files to all group hosts;
-they replace the files which would be generated in other schemes.
-On each host bob install a soft link from the generic name
-.Pa ntpkey_host_ Ns Ar bob
-to the host key file and soft link
-.Pa ntpkey_cert_ Ns Ar bob
-to the private certificate file.
-Note the generic links are on bob, but point to files generated
-by trusted host alice.
-In this scheme it is not possible to refresh
-either the keys or certificates without copying them
-to all other hosts in the group.
-.Pp
-For the IFF scheme proceed as in the TC scheme to generate keys
-and certificates for all group hosts, then for every trusted host in the group,
-generate the IFF parameter file.
-On trusted host alice run
-.Nm
-.Fl T
-.Fl I
-.Fl p Ar password
-to produce her parameter file
-.Pa ntpkey_IFFpar_ Ns Ar alice.filestamp ,
-which includes both server and client keys.
-Copy this file to all group hosts that operate as both servers
-and clients and install a soft link from the generic
-.Pa ntpkey_iff_ Ns Ar alice
-to this file.
-If there are no hosts restricted to operate only as clients,
-there is nothing further to do.
-As the IFF scheme is independent
-of keys and certificates, these files can be refreshed as needed.
-.Pp
-If a rogue client has the parameter file, it could masquerade
-as a legitimate server and present a middleman threat.
-To eliminate this threat, the client keys can be extracted
-from the parameter file and distributed to all restricted clients.
-After generating the parameter file, on alice run
-.Nm
-.Fl e
-and pipe the output to a file or mail program.
-Copy or mail this file to all restricted clients.
-On these clients install a soft link from the generic
-.Pa ntpkey_iff_ Ns Ar alice
-to this file.
-To further protect the integrity of the keys,
-each file can be encrypted with a secret password.
-.Pp
-For the GQ scheme proceed as in the TC scheme to generate keys
-and certificates for all group hosts, then for every trusted host
-in the group, generate the IFF parameter file.
-On trusted host alice run
-.Nm
-.Fl T
-.Fl G
-.Fl p Ar password
-to produce her parameter file
-.Pa ntpkey_GQpar_ Ns Ar alice.filestamp ,
-which includes both server and client keys.
-Copy this file to all group hosts and install a soft link
-from the generic
-.Pa ntpkey_gq_ Ns Ar alice
-to this file.
-In addition, on each host bob install a soft link
-from generic
-.Pa ntpkey_gq_ Ns Ar bob
-to this file.
-As the GQ scheme updates the GQ parameters file and certificate
-at the same time, keys and certificates can be regenerated as needed.
-.Pp
-For the MV scheme, proceed as in the TC scheme to generate keys
-and certificates for all group hosts.
-For illustration assume trish is the TA, alice one of several trusted hosts
-and bob one of her clients.
-On TA trish run
-.Nm
-.Fl V Ar n
-.Fl p Ar password ,
-where
-.Ar n
-is the number of revokable keys (typically 5) to produce
-the parameter file
-.Pa ntpkeys_MVpar_ Ns Ar trish.filestamp
-and client key files
-.Pa ntpkeys_MVkeyd_ Ns Ar trish.filestamp
-where
-.Ar d
-is the key number (0 \&<
-.Ar d
-\&<
-.Ar n ) .
-Copy the parameter file to alice and install a soft link
-from the generic
-.Pa ntpkey_mv_ Ns Ar alice
-to this file.
-Copy one of the client key files to alice for later distribution
-to her clients.
-It doesn't matter which client key file goes to alice,
-since they all work the same way.
-Alice copies the client key file to all of her cliens.
-On client bob install a soft link from generic
-.Pa ntpkey_mvkey_ Ns Ar bob
-to the client key file.
-As the MV scheme is independent of keys and certificates,
-these files can be refreshed as needed.
-.Ss Command Line Options
-.Bl -tag -width indent
-.It Fl c Ar scheme
-Select certificate message digest/signature encryption scheme.
-The
-.Ar scheme
-can be one of the following:
-. Cm RSA-MD2 , RSA-MD5 , RSA-SHA , RSA-SHA1 , RSA-MDC2 , RSA-RIPEMD160 , DSA-SHA ,
-or
-.Cm DSA-SHA1 .
-Note that RSA schemes must be used with a RSA sign key and DSA
-schemes must be used with a DSA sign key.
-The default without this option is
-.Cm RSA-MD5 .
-.It Fl d
-Enable debugging.
-This option displays the cryptographic data produced in eye-friendly billboards.
-.It Fl e
-Write the IFF client keys to the standard output.
-This is intended for automatic key distribution by mail.
-.It Fl G
-Generate parameters and keys for the GQ identification scheme,
-obsoleting any that may exist.
-.It Fl g
-Generate keys for the GQ identification scheme
-using the existing GQ parameters.
-If the GQ parameters do not yet exist, create them first.
-.It Fl H
-Generate new host keys, obsoleting any that may exist.
-.It Fl I
-Generate parameters for the IFF identification scheme,
-obsoleting any that may exist.
-.It Fl i Ar name
-Set the suject name to
-.Ar name .
-This is used as the subject field in certificates
-and in the file name for host and sign keys.
-.It Fl M
-Generate MD5 keys, obsoleting any that may exist.
-.It Fl P
-Generate a private certificate.
-By default, the program generates public certificates.
-.It Fl p Ar password
-Encrypt generated files containing private data with
-.Ar password
-and the DES-CBC algorithm.
-.It Fl q
-Set the password for reading files to password.
-.It Fl S Oo Cm RSA | DSA Oc
-Generate a new sign key of the designated type,
-obsoleting any that may exist.
-By default, the program uses the host key as the sign key.
-.It Fl s Ar name
-Set the issuer name to
-.Ar name .
-This is used for the issuer field in certificates
-and in the file name for identity files.
-.It Fl T
-Generate a trusted certificate.
-By default, the program generates a non-trusted certificate.
-.It Fl V Ar nkeys
-Generate parameters and keys for the Mu-Varadharajan (MV) identification scheme.
-.El
-.Ss Random Seed File
-All cryptographically sound key generation schemes must have means
-to randomize the entropy seed used to initialize
-the internal pseudo-random number generator used
-by the library routines.
-The OpenSSL library uses a designated random seed file for this purpose.
-The file must be available when starting the NTP daemon and
-.Nm
-program.
-If a site supports OpenSSL or its companion OpenSSH,
-it is very likely that means to do this are already available.
-.Pp
-It is important to understand that entropy must be evolved
-for each generation, for otherwise the random number sequence
-would be predictable.
-Various means dependent on external events, such as keystroke intervals,
-can be used to do this and some systems have built-in entropy sources.
-Suitable means are described in the OpenSSL software documentation,
-but are outside the scope of this page.
-.Pp
-The entropy seed used by the OpenSSL library is contained in a file,
-usually called
-.Cm .rnd ,
-which must be available when starting the NTP daemon
-or the
-.Nm
-program.
-The NTP daemon will first look for the file
-using the path specified by the
-.Ic randfile
-subcommand of the
-.Ic crypto
-configuration command.
-If not specified in this way, or when starting the
-.Nm
-program,
-the OpenSSL library will look for the file using the path specified
-by the
-.Ev RANDFILE
-environment variable in the user home directory,
-whether root or some other user.
-If the
-.Ev RANDFILE
-environment variable is not present,
-the library will look for the
-.Cm .rnd
-file in the user home directory.
-If the file is not available or cannot be written,
-the daemon exits with a message to the system log and the program
-exits with a suitable error message.
-.Ss Cryptographic Data Files
-All other file formats begin with two lines.
-The first contains the file name, including the generated host name
-and filestamp.
-The second contains the datestamp in conventional Unix date format.
-Lines beginning with # are considered comments and ignored by the
-.Nm
-program and
-.Xr ntpd @NTPD_MS@
-daemon.
-Cryptographic values are encoded first using ASN.1 rules,
-then encrypted if necessary, and finally written PEM-encoded
-printable ASCII format preceded and followed by MIME content identifier lines.
-.Pp
-The format of the symmetric keys file is somewhat different
-than the other files in the interest of backward compatibility.
-Since DES-CBC is deprecated in NTPv4, the only key format of interest
-is MD5 alphanumeric strings.
-Following hte heard the keys are
-entered one per line in the format
-.D1 Ar keyno type key
-where
-.Ar keyno
-is a positive integer in the range 1-65,535,
-.Ar type
-is the string MD5 defining the key format and
-.Ar key
-is the key itself,
-which is a printable ASCII string 16 characters or less in length.
-Each character is chosen from the 93 printable characters
-in the range 0x21 through 0x7f excluding space and the
-.Ql #
-character.
-.Pp
-Note that the keys used by the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-programs
-are checked against passwords requested by the programs
-and entered by hand, so it is generally appropriate to specify these keys
-in human readable ASCII format.
-.Pp
-The
-.Nm
-program generates a MD5 symmetric keys file
-.Pa ntpkey_MD5key_ Ns Ar hostname.filestamp .
-Since the file contains private shared keys,
-it should be visible only to root and distributed by secure means
-to other subnet hosts.
-The NTP daemon loads the file
-.Pa ntp.keys ,
-so
-.Nm
-installs a soft link from this name to the generated file.
-Subsequently, similar soft links must be installed by manual
-or automated means on the other subnet hosts.
-While this file is not used with the Autokey Version 2 protocol,
-it is needed to authenticate some remote configuration commands
-used by the
-.Xr ntpq @NTPQ_MS@
-and
-.Xr ntpdc @NTPDC_MS@
-utilities.
.Sh "OPTIONS"
.Bl -tag
.It \-b " \fIimbits\fP, " \-\-imbits "=" \fIimbits\fP
If any of these are directories, then the file \fI.ntprc\fP
is searched for within those directories.
.Sh USAGE
-The
-.Fl p Ar password
-option specifies the write password and
-.Fl q Ar password
-option the read password for previously encrypted files.
-The
-.Nm
-program prompts for the password if it reads an encrypted file
-and the password is missing or incorrect.
-If an encrypted file is read successfully and
-no write password is specified, the read password is used
-as the write password by default.
.Sh "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.Sh "FILES"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.Sh BUGS
-It can take quite a while to generate some cryptographic values,
-from one to several minutes with modern architectures
-such as UltraSPARC and up to tens of minutes to an hour
-with older architectures such as SPARC IPC.
-.Pp
-Please report bugs to http://bugs.ntp.org .Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-This document corresponds to version @VERSION@ of NTP.
-Portions of this document came from FreeBSD.
.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntp-keygen\fP
option definitions.
projects / thirdparty / ntp.git / commitdiff
