<dt><tt>hostnames [ yes | no ]</tt>
<dd>If <tt>yes</tt> is specified, host names are printed in information displays. If <tt>no</tt> is specified, numeric addresses are printed instead. The default is <tt>yes</tt>, unless modified using the command line <tt>-n</tt> switch.
<dt><tt>keyid <i>keyid</i></tt>
- <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.
+ <dd>This command allows the specification of a
+ key number to be used to authenticate configuration
+ requests from ntpdc to the <NOBR>host(s).</NOBR> This must
+ correspond to a key number which the host/server has
+ been configured to use for this purpose (server
+ options: <tt>trustedkey</tt>, and
+ <tt>requestkey</tt>). If authentication is not
+ enabled on the <NOBR>host(s)</NOBR> for ntpdc
+ commands, the command
+ <tt>"keyid 0"</tt> should be given; otherwise the
+ <i>keyid</i> of the next subsequent <tt>addpeer/addserver/broadcast
+ </tt> command will
+ be used.
<dt><tt>quit</tt>
<dd>Exit <tt>ntpdc</tt>.
<dt><tt>passwd</tt>
<p>Authenticated requests always include a timestamp in the packet data, which is included in the computation of the authentication code. This timestamp is compared by the server to its receive time stamp. If they differ by more than a small amount the request is rejected. This is done for two reasons. First, it makes simple replay attacks on the server, by someone who might be able to overhear traffic on your LAN, much more difficult. Second, it makes it more difficult to request configuration changes to your server from topologically remote hosts. While the reconfiguration facility will work well with a server on the local host, and may work adequately between time-synchronized hosts on the same LAN, it will work very poorly for more distant hosts. As such, if reasonable passwords are chosen, care is taken in the distribution and protection of keys and appropriate source address restrictions are applied, the run time reconfiguration facility should provide an adequate level of security.</p>
<p>The following commands all make authenticated requests.</p>
<dl>
- <dt><tt>addpeer <i>peer_address</i> [
+ <dt><tt>addpeer <i>peer_address</i> [
<i>keyid</i> ] [ <i>version</i> ] [
- <i>minpoll|prefer|iburst|burst</i> [...] ]</tt>
+ <tt>minpoll# | prefer | iburst | burst | minpoll
+ <i>N</i> | <tt>maxpoll</tt> <i>N</i> [...] ]</tt>
+ <dt><tt>addpeer <i>peer_address</i> [
+ <tt>prefer | iburst | burst | minpoll
+ <i>N</i> | <tt>maxpoll</tt> <i>N</i> | <tt>keyid</tt>
+ <i>N</i> | <tt>version</tt> <i>N</i> [...] ]</tt>
<dd>Add a configured peer association at the
given address and operating in symmetric
active mode. Note that an existing association
with the same peer may be deleted when this
command is executed, or may simply be
converted to conform to the new configuration,
- as appropriate. If the optional <tt>keyid</tt>
- is a nonzero integer, all outgoing packets to
+ as appropriate. If the <tt>keyid</tt>
+ is nonzero, 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 <tt>version#</tt> can be 1,
- 2 or 3 and defaults to 3. The remaining
+ will be done. If ntpdc's key number has not
+ yet been set (<i>e.g.,</i> by the keyid
+ command), it will be set to this value.
+ The <tt>version#</tt> can be 1 through 4 and defaults to 3. The remaining
options are either a numeric value for <tt>minpoll</tt> or
- a literal string <tt>prefer</tt>, <tt>iburst</tt>, or
- <tt>burst</tt>, and have the action as specified in the
+ literals <tt>prefer</tt>, <tt>iburst</tt>,
+ <tt>burst</tt>, <tt>minpoll </tt><i>N</i>,
+ <tt>keyid </tt><i>N</i>, <tt>version </tt> <i>N</i>, or
+ <tt>maxpoll </tt><i>N</i> (where <i>N</i> is a numeric value), and have the action as specified in the
<tt>peer</tt> configuration file command of
ntpd. See the <a href="confopt.html">Server Options</a> page for further information.
Each flag (or its absence) replaces the
previous setting. The <tt>prefer</tt> keyword indicates a preferred peer (and thus will be used primarily for clock synchronisation if possible). The preferred peer also determines the validity of the PPS signal - if the preferred peer is suitable for synchronisation so is the PPS signal.
- <dt><tt>addserver <i>peer_address</i> [ <i>keyid</i> ] [ <i>version</i> ] [ [ <i>minpoll|prefer|iburst|burst</i> [...] ]</tt>
+ <dt><tt>addserver <i>peer_address</i> [
+ <i>keyid</i> ] [ <i>version</i> ] [
+ <tt>minpoll# | prefer | iburst | burst | minpoll
+ <i>N</i> | <tt>maxpoll</tt> <i>N</i> [...] ]</tt>
+ <dt><tt>addserver <i>peer_address</i> [
+ <tt>prefer | iburst | burst | minpoll
+ <i>N</i> | <tt>maxpoll</tt> <i>N</i> | <tt>keyid</tt>
+ <i>N</i> | <tt>version</tt> <i>N</i> [...] ]</tt>
+
<dd>Identical to the addpeer command, except that the operating mode is client.
<dt><tt>broadcast <i>peer_address</i> [
<i>keyid</i> ] [ <i>version</i> ] [ <i>prefer</i> ]</tt>
- <dd>Identical to the addpeer command, except that the operating mode is broadcast. In this case a valid key identifier and key are required. The <tt>peer_address</tt> 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 required.
+ <dd>Identical to the addpeer command, except
+ that the operating mode is broadcast. In this
+ case a valid non-zero key identifier and key are required. The <tt>peer_address</tt> 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 required.
<dt><tt>unconfig <i>peer_address</i> [...]</tt>
<dd>This command causes the configured bit to be removed from the specified peer(s). In many cases this will cause the peer association to be deleted. When appropriate, however, the association may persist in an unconfigured mode if the remote peer is willing to continue on in this fashion.
<dt><tt>fudge <i>peer_address</i> [ <i>time1</i> ] [ <i>time2</i> ] [ <i>stratum</i> ] [ <i>refid</i> ]</tt>
* Keyid used for authenticated requests. Obtained on the fly.
*/
static u_long info_auth_keyid;
+static int keyid_entered = 0;
/*
* Type of key md5
#define MAXCMDS 100 /* maximum commands on cmd line */
#define MAXHOSTS 200 /* maximum hosts on cmd line */
#define MAXLINE 512 /* maximum line length */
-#define MAXTOKENS (1+1+MAXARGS+2) /* maximum number of usable tokens */
+#define MAXTOKENS (1+1+MAXARGS+MOREARGS+2) /* maximum number of usable tokens */
#define SCREENWIDTH 78 /* nominal screen width in columns */
/*
qpkt.mbz_itemsize = MBZ_ITEMSIZE(0);
}
- if (!auth) {
+ if (!auth || (keyid_entered && info_auth_keyid == 0)) {
qpkt.auth_seq = AUTH_SEQ(0, 0);
return sendpkt((char *)&qpkt, req_pkt_size);
} else {
const char *cmdline
)
{
- char *tokens[1+MAXARGS+2];
+ char *tokens[1+MAXARGS+MOREARGS+2];
struct parse pcmd;
int ntok;
int i, ti;
)
{
if (pcmd->nargs == 0) {
- if (info_auth_keyid == 0)
+ if (info_auth_keyid == 0 && !keyid_entered)
(void) fprintf(fp, "no keyid defined\n");
+ else if (info_auth_keyid == 0 && keyid_entered)
+ (void) fprintf(fp, "no keyid will be sent\n");
else
(void) fprintf(fp, "keyid is %lu\n", (u_long)info_auth_keyid);
} else {
info_auth_keyid = pcmd->argval[0].uval;
+ keyid_entered = 1;
}
}