6.2.2认证

6.2.2.1为什么需要认证？

大多数NTP用户不需要认证因为协议本身包含了许多针对坏的时间的过滤器。然而，还是存在认证，并且认证的使用正在变得越来越常见。其中原因可能是：

你只想用来自可信事件源的时间。

攻击者可能广播错误的时间戳。

攻击者可能伪装成另一个时间服务器。

6.2.2.2认证怎样应用？

NTP使用keys来实施认证。这些keys在两台机器之间交换数据时被使用。就如Q:6.1.3.3和6.1.3.4中所介绍的，其中有些用法和远端的管理有关系。当配置服务器或者对等体时，认证密钥可以被指定。

通常，双方都需要知道keys。这些keys存在于/etc/ntp.keys典型的明文因此应该被妥善隐藏，不要暴漏。这就意味着，这些keys需要被安全的发布到所有的通信伙伴那里。以下的例子来自于html/notes.htm:

peer 128.100.49.105 key 22
peer 128.8.10.1     key 4
peer 192.35.82.50   key 6

# path for key file
keys /usr/local/etc/ntp.keys

trustedkey 4 6 14 15 22 # define trusted keys
requestkey 15    # key (7) for accessing server variables
controlkey 15    # key (6) for accessing server variables

authdelay 0.000094      # authentication delay (Sun4c/50 IPX)

 这个关键字key指定了在与规定的服务器对话时使用的密钥。你一定要信任这个密钥来同步时间。因为认证需要引入额外的计算，这个关键字authdelay规定了计算时间。在更新的版本中这个计算可以被自动完成，然而一些老版本需要一个叫做authspeed的程序集来为DES或者MD5决定这个数字。

6.2.2.3怎样创建一个key？

A key只是一个最多8个ASCII码的的序列号（有些包含特殊意义的字符不能使用）。

M key是一个最多可达41个ACII码的序列号。

S key是一个每个字节的最低位是奇校验的64位值。

A key是一个每个字节的最高位是奇校验的64位值。

既然你已经知道了keys的基本规则，那么用密码和keys是一样的。看一个拥有有效keys的例子，见Q:6.1.3.3,更多信息可以在html/confopt.htm和html/notes.htm中被找到。

6.2.2.4 认证是怎样工作的？

基本认证是数字签名，并且没有数据加密（如果这又任何区别的话）。通常的数据包加上密钥被用来建立一个不可逆的魔法数字追加到数据包尾。接受者（拥有相同的密钥）会做相同的计算并且比较结果。如果结果匹配，认证就成功了。

6.2.2.5 我可以不重启ntpd来添加认证吗？

可以也不可以：你可以通过认证密钥来动态地添加服务器，并且亦可以通过使用xntpdcKauai信任和不信任任何密钥。你也可以通过readkeys命令重读密钥文件。不幸的是你需要在使用任何命令之前需要基本的认证。

6.2.2.6 我怎样使用公钥认证autokey？

    You need extra RSA libraries (like rsaref. See README.rsa for instructions.

    You need the utility ntp_genkeys to generate key-pairs and the Diffie-Hellman parameters file. All generated files have a timestamp suffix, it is recommended to install a symlink from the default name (without the timestamp extension) to the actual file:

    $ ntp_genkeys
    Generating MD5 key file...
    Generating RSA public/private key pair (512 bits)...
    Generating Diffie-Hellman parameters (512 bits)...
    $ ls
    ntp.keys.3174020162               ntpkey_dh.3174020162
    ntpkey.3174020162                 ntpkey_nops.BelWue.DE.3174020162
    $ ln -s ntp.keys.3174020162 ntp.keys
    $ ln -s ntpkey.3174020162 ntpkey
    $ ln -s ntpkey_dh.3174020162 ntpkey_dh
    $ ln -s ntpkey_nops.BelWue.DE.3174020162 ntpkey_nops.BelWue.DE

    In this example, nops.BelWue.DE is the canonical name of the local host. It is automatically appended to the file names by ntp_genkeys. File ntpkey_nops.BelWue.DE contains the public RSA key of host nops.BelWue.DE. File ntpkey contains the private RSA key. Needless to say that ntpkey and ntp.keys must not be world readable.

    Create a configuration file ntp.conf and a directory structure like this:

    crypto
    keysdir /etc/ntp/
    keys /etc/ntp/ntp.keys
       ...
    server noc1.belwue.de autokey version 4
    server noc2.belwue.de autokey version 4
    server rustime01.rus.uni-stuttgart.de version 3
    peer nepi.BelWue.DE autokey version 4
       ...

    /etc/ntp/
    /etc/ntp/leap-seconds.3169152000
    /etc/ntp/ntp.keys -> ntp.keys.3174020162
    /etc/ntp/ntp.keys.3174020162
    /etc/ntp/ntpkey -> ntpkey.3174020162
    /etc/ntp/ntpkey.3174020162
    /etc/ntp/ntpkey_dh -> ntpkey_dh.3174020906
    /etc/ntp/ntpkey_dh.3174020906
    /etc/ntp/ntpkey_leap -> leap-seconds.3169152000
    /etc/ntp/ntpkey_nepi.BelWue.DE -> ntpkey_nepi.BelWue.DE.3174020497
    /etc/ntp/ntpkey_nepi.BelWue.DE.3174020497
    /etc/ntp/ntpkey_nops.BelWue.DE -> ntpkey_nops.BelWue.DE.3174020162
    /etc/ntp/ntpkey_nops.BelWue.DE.3174020162

    File leap-seconds.3169152000 was downloaded from ftp://time.nist.gov/pub/. File ntpkey_nepi.BelWue.DE is the public RSA key of peer nepi.BelWue.DE. File ntpkey_dh is the same with all authenticated associations, it must be shared among all clients and servers of a security compartment. It does not matter on which host it was generated. You see that the public RSA keys for to the other two authenticated servers are missing. They autokey mechanism is able to download these keys from the servers over the net.

    If authentication is working, your should have output similar to this:

    ntpq> pe
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     LOCAL(1)        LOCAL(1)         6 l   58   64  377    0.000    0.000   0.000
    +noc1.belwue.de  .DCFp.           1 u  415 1024  377    2.071    4.886   0.020
    +noc2.belwue.de  .DCFp.           1 u  520 1024  377    1.936    4.891   0.016
    *rustime01.rus.u .DCFp.           1 u  422 1024  377    3.855    3.829   0.037
    -nepi.BelWue.DE  rustime01.rus.u  2 u  259 1024  376    1.839    8.957   0.217
    ntpq> as
    ind assID status  conf reach auth condition  last_event cnt
    ===========================================================
      1 57740  9014   yes   yes  none    reject   reachable  1
      2 57741  f4f4   yes   yes   ok   candidat   reachable 15
      3 57742  f4f4   yes   yes   ok   candidat   reachable 15
      4 57743  9634   yes   yes  none  sys.peer   reachable  3
      5 57744  f334   yes   yes   ok    outlyer   reachable  3
    ntpq> rv
    status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
    version="ntpd 4.0.99k-r Thu Jul 27 15:41:30 MET DST 2000 (7)",
    processor="sun4u", system="SunOS5.6", leap=00, stratum=2, precision=-15,
    rootdelay=3.855, rootdispersion=25.972, peer=57743,
    refid=rustime01.rus.uni-stuttgart.de,
    reftime=bd4d0006.7ba24894  Tue, Aug 22 2000 15:35:02.482, poll=10,
    clock=bd4d01be.a8915bdd  Tue, Aug 22 2000 15:42:22.658, state=4,
    phase=4.548, frequency=7.357, jitter=1.913, stability=0.016,
    hostname="nops.BelWue.DE", publickey=3174020162, params=3174020906,
    refresh=3175878685, leaptable=3169152000, tai=32