Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
NTP-KEYGEN(8)		  BSD System Manager's Manual		 NTP-KEYGEN(8)

     ntp-keygen	-- key generation program for ntpd

     ntp-keygen	[-deGgHIMnPT] [-c scheme] [-i name] [-p	password]
		[-S [RSA | DSA]] [-s name] [-v nkeys]

     This program generates cryptographic data files used by the NTPv4 authen-
     tication and identification schemes.  It generates	MD5 key	files used in
     symmetric key cryptography.  In addition, if the OpenSSL software library
     has been installed, it generates keys, certificate	and identity files
     used in public key	cryptography.  These files are used for	cookie encryp-
     tion, digital signature and challenge/response identification algorithms
     compatible	with the Internet standard security infrastructure.

     All files are in PEM-encoded printable ASCII format, so they can be em-
     bedded as MIME attachments	in mail	to other sites and certificate author-
     ities.  By	default, files are not encrypted.  The -p password option
     specifies the write password and -q password option the read password for
     previously	encrypted files.  The ntp-keygen program prompts for the pass-
     word if it	reads an encrypted file	and the	password is missing or incor-
     rect.  If an encrypted file is read successfully and no write password is
     specified,	the read password is used as the write password	by default.

     The ntpd(8) configuration command crypto pw password specifies the	read
     password for previously encrypted files.  The daemon expires on the spot
     if	the password is	missing	or incorrect.  For convenience,	if a file has
     been previously encrypted,	the default read password is the name of the
     host running the program.	If the previous	write password is specified as
     the host name, these files	can be read by that host with no explicit

     File names	begin with the prefix ntpkey_ and end with the postfix
     _hostname.filestamp, where	hostname is the	owner name, usually the	string
     returned by the Unix gethostname()	routine, and filestamp is the NTP sec-
     onds when the file	was generated, in decimal digits.  This	both guaran-
     tees uniqueness and simplifies maintenance	procedures, since all files
     can be quickly removed by a rm ntpkey* command or all files generated at
     a specific	time can be removed by a rm *filestamp command.	 To further
     reduce the	risk of	misconfiguration, the first two	lines of a file	con-
     tain the file name	and generation date and	time as	comments.

     All files are installed by	default	in the keys directory /usr/local/etc,
     which is normally in a shared filesystem in NFS-mounted networks.	The
     actual location of	the keys directory and each file can be	overridden by
     configuration commands, but this is not recommended.  Normally, the files
     for each host are generated by that host and used only by that host, al-
     though exceptions exist as	noted later on this page.

     Normally, files containing	private	values,	including the host key,	sign
     key and identification parameters,	are permitted root read/write-only;
     while others containing public values are permitted world readable.  Al-
     ternatively, files	containing private values can be encrypted and these
     files permitted world readable, which simplifies maintenance in shared
     file systems.  Since uniqueness is	insured	by the hostname	and file name
     extensions, the files for a NFS server and	dependent clients can all be
     installed in the same shared directory.

     The recommended practice is to keep the file name extensions when in-
     stalling a	file and to install a soft link	from the generic names speci-
     fied elsewhere on this page to the	generated files.  This allows new file
     generations to be activated simply	by changing the	link.  If a link is
     present, ntpd follows it to the file name to extract the filestamp.  If a
     link is not present, ntpd(8) extracts the filestamp from the file itself.
     This allows clients to verify that	the file and generation	times are al-
     ways current.  The	ntp-keygen program uses	the same timestamp extension
     for all files generated at	one time, so each generation is	distinct and
     can be readily recognized in monitoring data.

   Running the program
     The safest	way to run the ntp-keygen program is logged in directly	as
     root.  The	recommended procedure is change	to the keys directory, usually
     /usr/local/etc, then run the program.  When run for the first time, or if
     all ntpkey	files have been	removed, the program generates a RSA host key
     file and matching RSA-MD5 certificate file, which is all that is neces-
     sary in many cases.  The program also generates soft links	from the
     generic names to the respective files.  If	run again, the program uses
     the same host key file, but generates a new certificate file and link.

     The host key is used to encrypt the cookie	when required and so must be
     RSA type.	By default, the	host key is also the sign key used to encrypt
     signatures.  When necessary, a different sign key can be specified	and
     this can be either	RSA or DSA type.  By default, the message digest type
     is	MD5, but any combination of sign key type and message digest type sup-
     ported by the OpenSSL library can be specified, including those using the
     MD2, MD5, SHA, SHA1, MDC2 and RIPE160 message digest algorithms.  How-
     ever, the scheme specified	in the certificate must	be compatible with the
     sign key.	Certificates using any digest algorithm	are compatible with
     RSA sign keys; however, only SHA and SHA1 certificates are	compatible
     with DSA sign keys.

     Private/public key	files and certificates are compatible with other
     OpenSSL applications and very likely other	libraries as well.  Certifi-
     cates or certificate requests derived from	them should be compatible with
     extant industry practice, although	some users might find the interpreta-
     tion of X509v3 extension fields somewhat liberal.	However, the identifi-
     cation parameter files, although encoded as the other files, are probably
     not compatible with anything other	than Autokey.

     Running the program as other than root and	using the Unix su command to
     assume root may not work properly,	since by default the OpenSSL library
     looks for the random seed file .rnd in the	user home directory.  However,
     there should be only one .rnd, most conveniently in the root directory,
     so	it is convenient to define the $RANDFILE environment variable used by
     the OpenSSL library as the	path to	/.rnd.

     Installing	the keys as root might not work	in NFS-mounted shared file
     systems, as NFS clients may not be	able to	write to the shared keys di-
     rectory, even as root.  In	this case, NFS clients can specify the files
     in	another	directory such as /etc using the keysdir command.  There is no
     need for one client to read the keys and certificates of other clients or
     servers, as these data are	obtained automatically by the Autokey proto-

     Ordinarily, cryptographic files are generated by the host that uses them,
     but it is possible	for a trusted agent (TA) to generate these files for
     other hosts; however, in such cases files should always be	encrypted.
     The subject name and trusted name default to the hostname of the host
     generating	the files, but can be changed by command line options.	It is
     convenient	to designate the owner name and	trusted	name as	the subject
     and issuer	fields,	respectively, of the certificate.  The owner name is
     also used for the host and	sign key files,	while the trusted name is used
     for the identity files.

   Trusted Hosts and Groups
     Each cryptographic	configuration involves selection of a signature	scheme
     and identification	scheme,	called a cryptotype, as	explained in the
     Authentication Options section of ntp.conf(5).  The default cryptotype
     uses RSA encryption, MD5 message digest and TC identification.  First,
     configure a NTP subnet including one or more low-stratum trusted hosts
     from which	all other hosts	derive synchronization directly	or indirectly.
     Trusted hosts have	trusted	certificates; all other	hosts have nontrusted
     certificates.  These hosts	will automatically and dynamically build au-
     thoritative certificate trails to one or more trusted hosts.  A trusted
     group is the set of all hosts that	have, directly or indirectly, a	cer-
     tificate trail ending at a	trusted	host.  The trail is defined by static
     configuration file	entries	or dynamic means described on the Automatic
     NTP Configuration Options section of ntp.conf(5).

     On	each trusted host as root, change to the keys directory.  To insure a
     fresh fileset, remove all ntpkey files.  Then run ntp-keygen -T to	gener-
     ate keys and a trusted certificate.  On all other hosts do	the same, but
     leave off the -T flag to generate keys and	nontrusted certificates.  When
     complete, start the NTP daemons beginning at the lowest stratum and work-
     ing up the	tree.  It may take some	time for Autokey to instantiate	the
     certificate trails	throughout the subnet, but setting up the environment
     is	completely automatic.

     If	it is necessary	to use a different sign	key or different digest/signa-
     ture scheme than the default, run ntp-keygen with the -S type option,
     where type	is either RSA or DSA.  The most	often need to do this is when
     a DSA-signed certificate is used.	If it is necessary to use a different
     certificate scheme	than the default, run ntp-keygen with the -c scheme
     option and	selected scheme	as needed.  If ntp-keygen is run again without
     these options, it generates a new certificate using the same scheme and
     sign key.

     After setting up the environment it is advisable to update	certificates
     from time to time,	if only	to extend the validity interval.  Simply run
     ntp-keygen	with the same flags as before to generate new certificates us-
     ing existing keys.	 However, if the host or sign key is changed, ntpd(8)
     should be restarted.  When	ntpd(8)	is restarted, it loads any new files
     and restarts the protocol.	 Other dependent hosts will continue as	usual
     until signatures are refreshed, at	which time the protocol	is restarted.

   Identity Schemes
     As	mentioned on the Autonomous Authentication page, the default TC	iden-
     tity scheme is vulnerable to a middleman attack.  However,	there are more
     secure identity schemes available,	including PC, IFF, GQ and MV described
     on	the "Identification Schemes" page (maybe available at  These schemes are based
     on	a TA, one or more trusted hosts	and some number	of nontrusted hosts.
     Trusted hosts prove identity using	values provided	by the TA, while the
     remaining hosts prove identity using values provided by a trusted host
     and certificate trails that end on	that host.  The	name of	a trusted host
     is	also the name of its sugroup and also the subject and issuer name on
     its trusted certificate.  The TA is not necessarily a trusted host	in
     this sense, but often is.

     In	some schemes there are separate	keys for servers and clients.  A
     server can	also be	a client of another server, but	a client can never be
     a server for another client.  In general, trusted hosts and nontrusted
     hosts that	operate	as both	server and client have parameter files that
     contain both server and client keys.  Hosts that operate only as clients
     have key files that contain only client keys.

     The PC scheme supports only one trusted host in the group.	 On trusted
     host alice	run ntp-keygen -P -p password to generate the host key file
     ntpkey_RSAkey_alice.filestamp and trusted private certificate file
     ntpkey_RSA-MD5_cert_alice.filestamp.  Copy	both files to all group	hosts;
     they replace the files which would	be generated in	other schemes.	On
     each host bob install a soft link from the	generic	name ntpkey_host_bob
     to	the host key file and soft link	ntpkey_cert_bob	to the private cer-
     tificate file.  Note the generic links are	on bob,	but point to files
     generated by trusted host alice.  In this scheme it is not	possible to
     refresh either the	keys or	certificates without copying them to all other
     hosts in the group.

     For the IFF scheme	proceed	as in the TC scheme to generate	keys and cer-
     tificates for all group hosts, then for every trusted host	in the group,
     generate the IFF parameter	file.  On trusted host alice run ntp-keygen -T
     -I	-p password to produce her parameter file
     ntpkey_IFFpar_alice.filestamp, which includes both	server and client
     keys.  Copy this file to all group	hosts that operate as both servers and
     clients and install a soft	link from the generic ntpkey_iff_alice to this
     file.  If there are no hosts restricted to	operate	only as	clients, there
     is	nothing	further	to do.	As the IFF scheme is independent of keys and
     certificates, these files can be refreshed	as needed.

     If	a rogue	client has the parameter file, it could	masquerade as a	legit-
     imate server and present a	middleman threat.  To eliminate	this threat,
     the client	keys can be extracted from the parameter file and distributed
     to	all restricted clients.	 After generating the parameter	file, on alice
     run ntp-keygen -e and pipe	the output to a	file or	mail program.  Copy or
     mail this file to all restricted clients.	On these clients install a
     soft link from the	generic	ntpkey_iff_alice to this file.	To further
     protect the integrity of the keys,	each file can be encrypted with	a se-
     cret password.

     For the GQ	scheme proceed as in the TC scheme to generate keys and	cer-
     tificates for all group hosts, then for every trusted host	in the group,
     generate the IFF parameter	file.  On trusted host alice run ntp-keygen -T
     -G	-p password to produce her parameter file
     ntpkey_GQpar_alice.filestamp, which includes both server and client keys.
     Copy this file to all group hosts and install a soft link from the
     generic ntpkey_gq_alice to	this file.  In addition, on each host bob in-
     stall a soft link from generic ntpkey_gq_bob to this file.	 As the	GQ
     scheme updates the	GQ parameters file and certificate at the same time,
     keys and certificates can be regenerated as needed.

     For the MV	scheme,	proceed	as in the TC scheme to generate	keys and cer-
     tificates for all group hosts.  For illustration assume trish is the TA,
     alice one of several trusted hosts	and bob	one of her clients.  On	TA tr-
     ish run ntp-keygen	-V n -p	password, where	n is the number	of revokable
     keys (typically 5)	to produce the parameter file
     ntpkeys_MVpar_trish.filestamp and client key files
     ntpkeys_MVkeyd_trish.filestamp where d is the key number (0 < d < n).
     Copy the parameter	file to	alice and install a soft link from the generic
     ntpkey_mv_alice to	this file.  Copy one of	the client key files to	alice
     for later distribution to her clients.  It	doesn't	matter which client
     key file goes to alice, since they	all work the same way.	Alice copies
     the client	key file to all	of her cliens.	On client bob install a	soft
     link from generic ntpkey_mvkey_bob	to the client key file.	 As the	MV
     scheme is independent of keys and certificates, these files can be	re-
     freshed as	needed.

   Command Line	Options
     -c	scheme
	     Select certificate	message	digest/signature encryption scheme.
	     The scheme	can be one of the following: RSA-MD2, RSA-MD5,
	     Note that RSA schemes must	be used	with a RSA sign	key and	DSA
	     schemes must be used with a DSA sign key.	The default without
	     this option is RSA-MD5.

     -d	     Enable debugging.	This option displays the cryptographic data
	     produced in eye-friendly billboards.

     -e	     Write the IFF client keys to the standard output.	This is	in-
	     tended for	automatic key distribution by mail.

     -G	     Generate parameters and keys for the GQ identification scheme,
	     obsoleting	any that may exist.

     -g	     Generate keys for the GQ identification scheme using the existing
	     GQ	parameters.  If	the GQ parameters do not yet exist, create
	     them first.

     -H	     Generate new host keys, obsoleting	any that may exist.

     -I	     Generate parameters for the IFF identification scheme, obsoleting
	     any that may exist.

     -i	name
	     Set the suject name to name.  This	is used	as the subject field
	     in	certificates and in the	file name for host and sign keys.

     -M	     Generate MD5 keys,	obsoleting any that may	exist.

     -P	     Generate a	private	certificate.  By default, the program gener-
	     ates public certificates.

     -p	password
	     Encrypt generated files containing	private	data with password and
	     the DES-CBC algorithm.

     -q	     Set the password for reading files	to password.

     -S	[RSA | DSA]
	     Generate a	new sign key of	the designated type, obsoleting	any
	     that may exist.  By default, the program uses the host key	as the
	     sign key.

     -s	name
	     Set the issuer name to name.  This	is used	for the	issuer field
	     in	certificates and in the	file name for identity files.

     -T	     Generate a	trusted	certificate.  By default, the program gener-
	     ates a non-trusted	certificate.

     -V	nkeys
	     Generate parameters and keys for the Mu-Varadharajan (MV) identi-
	     fication scheme.

   Random Seed File
     All cryptographically sound key generation	schemes	must have means	to
     randomize the entropy seed	used to	initialize the internal	pseudo-random
     number generator used by the library routines.  The OpenSSL library uses
     a designated random seed file for this purpose.  The file must be avail-
     able when starting	the NTP	daemon and ntp-keygen program.	If a site sup-
     ports OpenSSL or its companion OpenSSH, it	is very	likely that means to
     do	this are already available.

     It	is important to	understand that	entropy	must be	evolved	for each gen-
     eration, for otherwise the	random number sequence would be	predictable.
     Various means dependent on	external events, such as keystroke intervals,
     can be used to do this and	some systems have built-in entropy sources.
     Suitable means are	described in the OpenSSL software documentation, but
     are outside the scope of this page.

     The entropy seed used by the OpenSSL library is contained in a file, usu-
     ally called .rnd, which must be available when starting the NTP daemon or
     the ntp-keygen program.  The NTP daemon will first	look for the file us-
     ing the path specified by the randfile subcommand of the crypto configu-
     ration command.  If not specified in this way, or when starting the
     ntp-keygen	program, the OpenSSL library will look for the file using the
     path specified by the RANDFILE environment	variable in the	user home di-
     rectory, whether root or some other user.	If the RANDFILE	environment
     variable is not present, the library will look for	the .rnd file in the
     user home directory.  If the file is not available	or cannot be written,
     the daemon	exits with a message to	the system log and the program exits
     with a suitable error message.

   Cryptographic Data Files
     All other file formats begin with two lines.  The first contains the file
     name, including the generated host	name and filestamp.  The second	con-
     tains the datestamp in conventional Unix date format.  Lines beginning
     with # are	considered comments and	ignored	by the ntp-keygen program and
     ntpd(8) daemon.  Cryptographic values are encoded first using ASN.1
     rules, then encrypted if necessary, and finally written PEM-encoded
     printable ASCII format preceded and followed by MIME content identifier

     The format	of the symmetric keys file is somewhat different than the
     other files in the	interest of backward compatibility.  Since DES-CBC is
     deprecated	in NTPv4, the only key format of interest is MD5 alphanumeric
     strings.  Following hte heard the keys are	entered	one per	line in	the
	   keyno type key
     where keyno is a positive integer in the range 1-65,535, type is the
     string MD5	defining the key format	and key	is the key itself, which is a
     printable ASCII string 16 characters or less in length.  Each character
     is	chosen from the	93 printable characters	in the range 0x21 through 0x7f
     excluding space and the `#' character.

     Note that the keys	used by	the ntpq(8) and	ntpdc(8) programs are checked
     against passwords requested by the	programs and entered by	hand, so it is
     generally appropriate to specify these keys in human readable ASCII for-

     The ntp-keygen program generates a	MD5 symmetric keys file
     ntpkey_MD5key_hostname.filestamp.	Since the file contains	private	shared
     keys, it should be	visible	only to	root and distributed by	secure means
     to	other subnet hosts.  The NTP daemon loads the file ntp.keys, so
     ntp-keygen	installs a soft	link from this name to the generated file.
     Subsequently, similar soft	links must be installed	by manual or automated
     means on the other	subnet hosts.  While this file is not used with	the
     Autokey Version 2 protocol, it is needed to authenticate some remote con-
     figuration	commands used by the ntpq(8) and ntpdc(8) utilities.

     It	can take quite a while to generate some	cryptographic values, from one
     to	several	minutes	with modern architectures such as UltraSPARC and up to
     tens of minutes to	an hour	with older architectures such as SPARC IPC.

BSD				 May 17, 2006				   BSD


Want to link to this manual page? Use this URL:

home | help