NTP Authentication: Server Side

As already pointed out in my NTP intro blogpost Why should I run own NTP Servers? it is crucial to leverage NTP authentication to have the highest trustworthiness of your time distribution all over your network. Hence the first step is to enable NTP authentication on your own stratum 1 NTP servers, in my case two Raspberry Pis with DCF77/GPS reference clocks.

Luckily it is quite easy to deploy NTP authentication. You only need to generate some NTP keys and trusting them in your ntp.conf configuration file.

This article is one of many blog posts within this NTP series. Please have a look!

You can use the tool ntp-keygen -M in order to “Generate a new symmetric keys file containing 10 MD5 keys, and if OpenSSL is available, 10 SHA keys”. I’m doing it in the /etc/ folder to have the key file in the correct place. Note that ntp-keygen in fact generates a keyfile as well as a link called “ntp.keys”. Finally, I am showing the keys here:

Of course you MUST NOT publish your generated NTP keys since the security relies on their confidentiality. You MUST use a single SHA-1 key per security zone in your enterprise.

The second step is to enable NTP authentication by telling ntp which keyfile to use and which keys to trustsudo nano /etc/ntp.conf adding these lines:

Followed by a restart of ntp: sudo service ntp restart.

Note: Though ntp-keygen generates MD5 and SHA-1 keys, you should only use/trust the SHA-1 based keys for maximum security.

That’s it. You can now use those SHA-1 keys on your NTP clients to authenticate the replies from this specific NTP server. In case you need more keys, simply run ntp-keygen -M one more time in another folder (e.g., your home directory), while adding the new keys to the initially generated keyfile – of course only the SHA-1 ones with increased key IDs, such as 21-30.

For further details please refer to the official Authentication Support documentation from ntp. “By default, the client sends non-authenticated packets and the server responds with non-authenticated packets. If the client sends authenticated packets, the server responds with authenticated packets if correct, or a crypto-NAK packet if not.”

If you’re interested in how those authenticated NTP packets look on the wire download an appropriate pcap file here: Packet Capture: Network Time Protocol (NTP).

Featured image “Verträge sind gemacht” by Rolf van Melis is licensed under CC BY-NC-ND 2.0.

7 thoughts on “NTP Authentication: Server Side

  1. how to solve this error plz

    authreadkeys: file ‘/etc/ntp.keys’: Permission denied

    lrwxrwxrwx 1 root root ntp.keys

    1. Uh, that’s interesting. Where is this error messages from?
      Since your rights on the ntp.keys file is already rwx from everyone, I don’t know why the permission is denied. ;(

      Have you tried turning it off and on again? ;)

      Please find a NTP mailinglist to ask your question there: http://lists.ntp.org/listinfo


  2. You have provided the server configuration, but please tell me what settings to be done on client.

    1. Yep: There’s a blue box at the top of this post that reads “This article is one of many blog posts within this NTP series. Please have a look!” Follow the link. You’ll find a “NTP Authentication: Client Side” article there. ;)

Leave a Reply

Your email address will not be published. Required fields are marked *