Config file format - (Was: [ntp:hackers] FreeBSD serial ports)

Steve Kostecke kostecke at
Fri Feb 18 08:05:58 PST 2005

John Pettitt said:

>Harlan Stenn wrote:
>>I see no reason to lose the remote config stuff - it is mode7 and is
>I still question in-band config - it's just a security hole waiting to

Remote configuration is quite useful. I use it regularly and there are
a number of ntpd helper scripts in circulation which depend on remote

Remote configuration is not possible unless one of two conditions are

	1. The keys are are configured _and_ the person performing
	the remote configuration has the keys _and_ the originating
	IP address for the remote configuration has not been blocked
	with a "nomodify" restriction


	2. ntpd is started with '-A' to disable authentication (you
	will still be prompted for a keyID/password but any values
	are accepted

>Perhaps if there is a config from a url then in-band config could be
>limited to a "re-load" command that just causes the server to re-fetch
>it's out of-band config.

It seems to me that a complete configuration reload is tantamount to
restarting ntpd. This would cause a disruption of time service where
refclocks are involved. And 

>That would effectivly be "dial back" security which would help.

Unless hihacked by DNS spoofing or a MITM attack.

>> ntpd -c (get a conf file from a local
>> server)
>I like the remote via url config idea

This adds more complexity to ntpd. And it introduces a single point of

>>I'd also like to have the ability for ntpd to write its current config
>I'd also vote against programs writing to their config file, it's a bad
>idea that also potentialy opens security holes.

It may be useful to have ntpd dump the configuration file to STDOUT. But
doing so will add more complexity to ntpd.

Steve Kostecke <kostecke at>
NTP Public Services Project
Public Key at

More information about the hackers mailing list