[ntp:questions] Re: Still Authentication

Martin Burnicki martin.burnicki at meinberg.de
Fri Sep 9 11:29:48 UTC 2005


Eric,

Eric Liu wrote:
>> > Hi all:
>> >
>> >I am trying authentication with Ntp-4.2.0, and I've got a problem.
>> >Here is my client ntp.conf:
>> > ________________________________________
>> > server  192.168.0.120 burst key 10

You should use iburst instead of burst here, if possible. However, that's
not related to your problem.

>> > trustedkey 10
>> > keys /etc/ntp.keys
>> > driftfile /etc/ntp.drift
>> > logfile /var/ntp.log
>> >________________________________________
>> >
>> >Server side ntp.conf:
>> >______________________________
>> >server 127.127.1.1
>> >keys /etc/ntp.keys
>> >driftfile /etc/ntp.drift
>> > logfile /var/ntp.log
>> >___________________________________
>> >
>> > Heree is the key file for both server and client:
>> > ________________________________
>> > 10 M ericl
>> > ________________________________
[...]

Anything of the above looks OK.

>> >
>> >However, the client always think the server is untrusted because in the
>> >packet from the server the keyid is always 0, but not 10.
>> >Could someone do me a favour?

I've observed that the server responds with a keyid 0 if it has been
configured for the requested key but the keys file is not readable.

In your case it could mean that your server knows that key 10 can be
trusted, and it receives a request from a client with key 10, but since the
server's daemon is unable to read the keys file it is unable to sign the
response packet with that key and responds with keyid 0.
I've tested this here just by renaming the keys file. 

Unfortunately you haven't specified your environment. Maybe your server is
started chroot'ed, but the keys file is not copied to the chroot jail
directory by the startup script for the daemon?

You might try to kill the NTP daemon on the server using that script, and
restart it manually, i.e. just by executing the binary directly.


> Richard B. Gilbert wrote:
>> I'll gladly defer to someone who knows what he's talking about but it
>> looks to me as if you've done nothing to tell your server to use key 10.
>> 
>> Try:
>>
>> server 127.127.1.1 key 10
> 
>    This does not work at all. On the contrary, it makes thing worse
>    because
> this means authentication is necessary when synchronizing to local
> machine. Here, the key is not for client, but for server. So "key 10" is
> not necessary at all. (Eric)

You're right here. It makes no sense to specify a key for the refclock
driver "local clock".


Hope this helps,

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list