[Git][NTPsec/ntpsec][master] 2 commits: Address GitLab issue #92: ntpkeygen documentation needs to be rewritten.
Eric S. Raymond
gitlab at mg.gitlab.com
Wed Aug 10 11:52:07 UTC 2016
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
caf51b48 by Eric S. Raymond at 2016-08-10T07:46:30-04:00
Address GitLab issue #92: ntpkeygen documentation needs to be rewritten.
- - - - -
85ed70ee by Eric S. Raymond at 2016-08-10T07:51:20-04:00
Address GitLab issue #93: No --help output from ntpkeygen.
- - - - -
2 changed files:
- docs/includes/ntpkeygen-body.txt
- ntpkeygen/ntpkeygen.c
Changes:
=====================================
docs/includes/ntpkeygen-body.txt
=====================================
--- a/docs/includes/ntpkeygen-body.txt
+++ b/docs/includes/ntpkeygen-body.txt
@@ -5,133 +5,39 @@
[[synop]]
== Synopsis ==
[verse]
-+{ntpkeygen}+
- [ +-dM+ ] [ +-b+ 'modulus' ]
- [ +-c+ [ +RSA-MD2+ | +RSA-MD5+ | +RSA-SHA+ | +RSA-SHA1+ |
- +RSA-MDC2+ | +RSA-RIPEMD160+ | +DSA-SHA+ | +DSA-SHA1+ ] ]
- [ +-C+ 'cipher' ] [ +-m+ 'modulus' ]
++{ntpkeygen}+ [ +-M+ ]
[[descrip]]
== Description ==
-This program generates cryptographic data files used by the NTPv4
-authentication and identity schemes. It can generate MD5 message digest keys
-used in symmetric key cryptography.
+This program generates the MD5 message digest keys used in NTP's symmetric
+key cryptography.
-All files are in PEM-encoded printable ASCII format, so they can be
-embedded as MIME attachments in mail to other sites and certificate
-`authorities. By default, files are not encrypted.
+The program produces a file containing ten pseudo-random printable
+ASCII strings suitable for the MD5 message digest algorithm included
+in the distribution. If the OpenSSL library is installed, it produces
+an additional ten hex-encoded random bit strings suitable for the SHA1
+and other message digest algorithms. The message digest keys file must
+be distributed and stored using secure means beyond the scope of NTP
+itself. Besides the keys used for ordinary NTP associations,
+additional keys can be defined as passwords for the
+link:ntpq.html[+{ntpq}+] utility program.
-When used to generate message digest keys, the program produces a file
-containing ten pseudo-random printable ASCII strings suitable for the
-MD5 message digest algorithm included in the distribution. If the
-OpenSSL library is installed, it produces an additional ten hex-encoded
-random bit strings suitable for the SHA1 and other message digest
-algorithms. The message digest keys file must be distributed and stored
-using secure means beyond the scope of NTP itself. Besides the keys used
-for ordinary NTP associations, additional keys can be defined as
-passwords for the link:ntpq.html[+{ntpq}+] utility program.
-
-The remaining generated files are compatible with other OpenSSL
-applications and other Public Key Infrastructure (PKI) resources.
-Certificates generated by this program are compatible with extant
-industry practice, although some users might find the interpretation of
-X509v3 extension fields somewhat liberal.
-
-The +pw+ option of the +crypto+ configuration command specifies the read
-password for previously encrypted local files. This must match the local
-password used by this program. If not specified, the host name is used.
-Thus, if files are generated by this program without password, they can
-be read back by +{ntpd}+ without password, but only on the same host.
-
-Normally, encrypted files for each host are generated by that host and
-used only by that host, although exceptions exist as noted later on this
-page. The symmetric keys file, normally called +{ntpkeys}+, is usually
-installed in +/etc+. Other files and links are usually installed in
-+/usr/local/etc+, which is normally in a shared filesystem in
-NFS-mounted networks and cannot be changed by shared clients. The
-location of the keys directory can be changed by the +keysdir+
-configuration command in such cases. Normally, this is in +/etc+.
-
-This program directs commentary and error messages to the standard error
-stream +stderr+ and remote files to the standard output stream +stdout+
-where they can be piped to other applications or redirected to files.
-The names used for generated files and links all begin with the string
-+ntpkey+ and include the file type, generating host and filestamp, as
-described in the link:#fmt[Cryptographic Data Files] section below
+Historical note:
[[cmd]]
== Command Line Options ==
-+-b+ 'modulus', +--imbits+='modules'::
- Set the modulus for generating identity keys to _modulus_ bits. The
- modulus defaults to 256, but can be set from 256 (32 octets) to 2048
- (256 octets). Use the larger moduli with caution, as this can consume
- considerable computing resources and increases the size of
- authenticated packets.
-+-c [ RSA-MD2 | RSA-MD5 | RSA-SHA | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ]+::
- Select certificate digital signature and message digest scheme. Note
- that RSA schemes must be used with an RSA sign key and DSA schemes
- must be used with a DSA sign key. The default without this option is
- +RSA-MD5+. If compatibility with FIPS 140-2 is required, either the
- +DSA-SHA+ or +DSA-SHA1+ scheme must be used. The long option
- +--certificate+ is synonymous.
-+-C+ 'cipher', +--cipher+='cipher'::
- Select the OpenSSL cipher to use for password-protected keys. The
- +openssl -h+ command provided with OpenSSL displays available ciphers.
- The default without this option is +des-ede3-cbc+ - three-key triple
- DES in CBC mode. The openssl tool lists ciphers available in
- +openssl -h+ output.
-+-d+, +--debug+::
- Enable debugging. This option displays the cryptographic data produced
- for eye-friendly billboards. It may appear an unlimited number of
- times, enabling higher levels of debugging.
-+-D+ number, +--set-debug-level+=_number_::
- Set the debug verbosity level. This option may appear an unlimited
- number of times. This option takes an integer number as its argument.
-+-m+ 'modulus', +--modulus+=_modulus_::
- Set the modulus for generating files to _modulus_ bits. The modulus
- defaults to 512, but can be set from 256 (32 octets) to 2048 (256
- octets). Use the larger moduli with caution, as this can consume
- considerable computing resources and increases the size of
- authenticated packets.
+-M+, +--md5key+::
- Generate a new keys file containing 10 MD5 keys and 10 SHA keys. An
- MD5 key is a string of 20 random printable ASCII characters, while a
- SHA key is a string of 40 random hex digits. The file can be edited
- using a text editor to change the key type or key content. This option
- is mutually exclusive with all other option.
+ Dummy option for backward compatibility in old scripts. This
+ program always runs in -M mode.
[[run]]
== Running the program ==
The safest way to run the +{ntpkeygen}+ 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 necessary 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
-supported by the OpenSSL library can be specified, including those using
-the MD2, MD5, SHA, SHA1, MDC2 and RIPE160 message digest algorithms.
-However, 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 key files and certificates are compatible with other
-OpenSSL applications and very likely other libraries as well.
-Certificates or certificate requests derived from them should be
-compatible with extant industry practice, although some users might find
-the interpretation of X509v3 extension fields somewhat liberal.
++/usr/local/etc+, then run the program.
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
@@ -145,26 +51,16 @@ systems, as NFS clients may not be able to write to the shared keys
directory, even as root. In this case, NFS clients can specify the files
in another directory such as +/etc+ using the _keysdir_ command.
-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.
-
[[access]]
== Key file access and location ==
-The {ntpdman} 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 password.
+//The {ntpdman} 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 password.
File names begin with the prefix _ntpkey__ and end with the postfix
__hostname.filestamp_, where _hostname_ is the owner name, usually the
@@ -173,9 +69,7 @@ the NTP seconds when the file was generated, in decimal digits. This
both guarantees 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 contain the file name and generation date and time as
-comments.
+command.
All files are installed by default in the keys directory
+/usr/local/etc+, which is normally in a shared filesystem in
@@ -185,152 +79,6 @@ recommended. Normally, the files for each host are generated by that
host and used only by that host, although 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.
-Alternatively, 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
-installing a file and to install a soft link from the generic names
-specified 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, {ntpdman} extracts the filestamp from
-the file itself. This allows clients to verify that the file and
-generation times are always current. The +{ntpkeygen}+ 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.
-
-[[trust]]
-== 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 {ntpdconfman}.
-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 authoritative certificate
-trails to one or more trusted hosts. A trusted group is the set of all
-hosts that have, directly or indirectly, a certificate 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 {ntpdconfman}.
-
-On each trusted host as root, change to the keys directory. To insure a
-fresh fileset, remove all _ntpkey_ files. Then run +{ntpkeygen}+ +-T+ to
-generate 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 working up the tree.
-
-If it is necessary to use a different sign key or different
-digest/signature scheme than the default, run +{ntpkeygen}+ 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 +{ntpkeygen}+
-with the +-c+ scheme option and selected _scheme_ as needed. f
-+{ntpkeygen}+ 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
-+{ntpkeygen}+ with the same flags as before to generate new certificates
-using existing keys. However, if the host or sign key is changed,
-{ntpdman} should be restarted. When {ntpdman} 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.
-
-[[ident]]
-== Identity Schemes ==
-
-As mentioned on the Autonomous Authentication page, the default TC
-identity 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
-_http://www.eecis.udel.edu/%7emills/keygen.html_). 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 +{ntpkeygen}+ +-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 certificate 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
-certificates for all group hosts, then for every trusted host in the
-group, generate the IFF parameter file. On trusted host alice run
-+{ntpkeygen}+ +-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
-legitimate 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 +{ntpkeygen} -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 secret password.
-
-For the GQ scheme proceed as in the TC scheme to generate keys and
-certificates for all group hosts, then for every trusted host in the
-group, generate the IFF parameter file. On trusted host alice run
-+{ntpkeygen} -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
-install 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
-certificates 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
-trish run +{ntpkeygen} -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
-refreshed as needed.
-
[[random]]
== Random Seed File ==
@@ -365,35 +113,6 @@ and the program exits with a suitable error message.
[[crypto]]
== Cryptographic Data Files ==
-File and link names are in the form _ntpkey_key_name.fstamp_, where
-_key_ is the key or parameter type, _name_ is the host or group name and
-_fstamp_ is the filestamp (NTP seconds) when the file was created). By
-convention, _key_ names in generated file names include both upper and
-lower case characters, while _key_ names in generated link names
-include only lower case characters. The filestamp is not used in
-generated link names.
-
-The _key_ name is a string defining the cryptographic key type. Key
-types include public/private keys +host+ and +sign+, certificate +cert+
-and several challenge/response key types. By convention, client files
-used for challenges have a +par+ subtype, as in the IFF challenge
-+IFFpar+, while server files for responses have a +key+ subtype, as in
-the GQ response +GQkey+.
-
-All other file formats begin with two lines. The first contains the file
-name, including the generated host name and filestamp. The second
-contains the datestamp in conventional Unix date format. Lines beginning
-with # are considered comments and ignored by the +{ntpkeygen}+ program
-and {ntpdman} 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 lines.
-
-Note that the keys used by the {ntpqman} program 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
-format.
-
The +{ntpkeygen}+ 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
@@ -404,10 +123,7 @@ automated means on the other subnet hosts. This file is needed to
authenticate some remote configuration commands used by the {ntpqman}
utility.
-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 the header the keys are entered one per line in the
+Following the header the keys are entered one per line in the
format _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
=====================================
ntpkeygen/ntpkeygen.c
=====================================
--- a/ntpkeygen/ntpkeygen.c
+++ b/ntpkeygen/ntpkeygen.c
@@ -1,78 +1,17 @@
/*
* Program to generate cryptographic keys for ntp clients and servers
*
- * This program generates password encrypted data files for use with
- * the Network Time Protocol Version 4. Files are prefixed with a
- * header giving the name and date of creation followed by a
- * type-specific descriptive label and PEM-encoded data structure
- * compatible with programs of the OpenSSL library.
- *
* All file names are like "ntpkey_<type>_<hostname>.<filestamp>", where
* <type> is the file type, <hostname> the generating host name and
* <filestamp> the generation time in NTP seconds. The NTP programs
* expect generic names such as "ntpkey_<type>_whimsy.udel.edu" with the
* association maintained by soft links. Following is a list of file
- * types; the first line is the file name and the second link name.
+ * types.
*
* ntpkey_MD5key_<hostname>.<filestamp>
* MD5 (128-bit) keys used to compute message digests in symmetric
* key cryptography
*
- * ntpkey_RSAhost_<hostname>.<filestamp>
- * ntpkey_host_<hostname>
- * RSA private/public host key pair used for public key signatures
- *
- * ntpkey_RSAsign_<hostname>.<filestamp>
- * ntpkey_sign_<hostname>
- * RSA private/public sign key pair used for public key signatures
- *
- * ntpkey_DSAsign_<hostname>.<filestamp>
- * ntpkey_sign_<hostname>
- * DSA Private/public sign key pair used for public key signatures
- *
- * Available digest/signature schemes
- *
- * RSA: RSA-MD2, RSA-MD5, RSA-SHA, RSA-SHA1, RSA-MDC2, EVP-RIPEMD160
- * DSA: DSA-SHA, DSA-SHA1
- *
- * ntpkey_XXXcert_<hostname>.<filestamp>
- * ntpkey_cert_<hostname>
- * X509v3 certificate using RSA or DSA public keys and signatures.
- * XXX is a code identifying the message digest and signature
- * encryption algorithm
- *
- * Identity schemes. The key type par is used for the challenge; the key
- * type key is used for the response.
- *
- * ntpkey_IFFkey_<groupname>.<filestamp>
- * ntpkey_iffkey_<groupname>
- * Schnorr (IFF) identity parameters and keys
- *
- * ntpkey_GQkey_<groupname>.<filestamp>,
- * ntpkey_gqkey_<groupname>
- * Guillou-Quisquater (GQ) identity parameters and keys
- *
- * ntpkey_MVkeyX_<groupname>.<filestamp>,
- * ntpkey_mvkey_<groupname>
- * Mu-Varadharajan (MV) identity parameters and keys
- *
- * Note: Once in a while because of some statistical fluke this program
- * fails to generate and verify some cryptographic data, as indicated by
- * exit status -1. In this case simply run the program again. If the
- * program does complete with exit code 0, the data are correct as
- * verified.
- *
- * These cryptographic routines are characterized by the prime modulus
- * size in bits. The default value of 512 bits is a compromise between
- * cryptographic strength and computing time and is ordinarily
- * considered adequate for this application. The routines have been
- * tested with sizes of 256, 512, 1024 and 2048 bits. Not all message
- * digest and signature encryption schemes work with sizes less than 512
- * bits. The computing time for sizes greater than 2048 bits is
- * prohibitive on all but the fastest processors. An UltraSPARC Blade
- * 1000 took something over nine minutes to generate and verify the
- * values with size 2048. An old SPARC IPC would take a week.
- *
* The OpenSSL library used by this program expects a random seed file.
* As described in the OpenSSL documentation, the file name defaults to
* first the RANDFILE environment variable in the user's home directory
@@ -106,7 +45,6 @@
#include <sodium.h>
#include <ssl_applink.c>
-#define _UC(str) ((char *)(intptr_t)(str))
/*
* Cryptodefines
*/
@@ -125,17 +63,11 @@ void followlink (char *, size_t);
*/
extern char *optarg; /* command line argument */
char *progname;
-u_int lifetime = DAYSPERYEAR; /* certificate lifetime (days) */
-int nkeys; /* MV keys */
time_t epoch; /* Unix epoch (seconds) since 1970 */
u_int fstamp; /* NTP filestamp */
char hostbuf[MAXHOSTNAME + 1];
char *hostname = NULL; /* host, used in cert filenames */
char *groupname = NULL; /* group name */
-char certnamebuf[2 * sizeof(hostbuf)];
-char *certname = NULL; /* certificate subject/issuer name */
-char *passwd1 = NULL; /* input private key password */
-char *passwd2 = NULL; /* output private key password */
char filename[MAXFILENAME + 1]; /* file name */
#ifdef SYS_WINNT
@@ -243,21 +175,13 @@ followlink(
fname[len] = '\0';
}
-#define ALL_OPTIONS "b:c:dD:e:G:HI:i:l:Mm:P:p:q:S:s:T:V:x:"
+#define ALL_OPTIONS "Mh"
static const struct option longoptions[] = {
- { "imbits", 1, 0, 'i' },
- { "cipher", 1, 0, 'C' },
- { "debug", 0, 0, 'd' },
- { "set-debug-level", 1, 0, 'D' },
{ "md5key", 0, 0, 'M' },
- { "modulus", 1, 0, 'm' },
+ { "help", 0, 0, 'h' },
{ NULL, 0, 0, '\0'},
};
-static char *opt_imbits = NULL;
-static bool opt_md5key = false;
-static int opt_modulus = -1;
-
/*
* Main program
*/
@@ -268,7 +192,6 @@ main(
)
{
struct timespec ts; /* initialization vector */
- int md5key = 0; /* generate MD5 keys */
int op;
progname = argv[0];
@@ -298,8 +221,6 @@ main(
hostbuf[COUNTOF(hostbuf) - 1] = '\0';
hostname = hostbuf;
groupname = hostbuf;
- passwd1 = hostbuf;
- passwd2 = NULL;
clock_gettime(CLOCK_REALTIME, &ts);
epoch = ts.tv_sec;
fstamp = (u_int)(epoch + JAN_1970);
@@ -308,25 +229,15 @@ main(
ALL_OPTIONS, longoptions, NULL)) != -1) {
switch (op) {
- case 'b':
- opt_imbits = ntp_optarg;
- break;
- case 'd':
-#ifdef DEBUG
- ++debug;
-#endif
- break;
- case 'D':
-#ifdef DEBUG
- debug = atoi(ntp_optarg);
-#endif
- break;
case 'M':
- opt_md5key = true;
- break;
- case 'm':
- opt_modulus = atoi(ntp_optarg);
+ /* dummy MD5 option for backwards compatibility */
break;
+ case 'h':
+ fprintf(stderr, "usage: ntpkeygen [-M]\n" );
+ exit(0);
+ default:
+ fprintf(stderr, "usage: ntpkeygen [-M]\n" );
+ exit(1);
}
}
@@ -342,17 +253,7 @@ main(
OPENSSL_VERSION_TEXT, SSLeay_version(SSLEAY_VERSION));
#endif /* HAVE_OPENSSL */
- if (opt_md5key)
- md5key++;
-
- /*
- * Create new unencrypted MD5 keys file if requested. If this
- * option is selected, ignore all other options.
- */
- if (md5key) {
- gen_md5("md5");
- exit (0);
- }
+ gen_md5("md5");
exit(0);
}
@@ -439,12 +340,7 @@ fheader (
exit (-1);
}
/* NAMECHANGE */
- if (strcmp(ulink, "md5") == 0) {
- strlcpy(linkname,"ntp.keys",sizeof(linkname));
- } else {
- snprintf(linkname, sizeof(linkname), "ntpkey_%s_%s", ulink,
- hostname);
- }
+ strlcpy(linkname,"ntp.keys",sizeof(linkname));
(void)remove(linkname); /* The symlink() line below matters */
temp = symlink(filename, linkname);
if (temp < 0)
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/165cbb1e555a6d9d50e498c6137140537b77f662...85ed70ee8386f3bef9e5c3a34a9ecde21d7babcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/vc/attachments/20160810/bd49900d/attachment.html>
More information about the vc
mailing list