Provided by: openswan_2.4.6+dfsg.2-1.1build2_i386
ipsec newhostkey - generate a new host authentication key
ipsec newhostkey --output filename [ --quiet ] \
[ --bits n ] [ --hostname host ]
Newhostkey outputs (into filename, which can be ‘-’ for standard out‐
put) an RSA private key suitable for this host, in /etc/ipsec.secrets
format (see ipsec.secrets(5)). Normally, newhostkey invokes rsasigkey
(see ipsec_rsasigkey(8)) with the --verbose option, so a narrative of
what is being done appears on standard error.
The --output specifier, although it is syntactically an option and can
appear at any point among the options (it doesn’t have to be first), is
not optional. The specified filename is created under umask 077 if
nonexistent; if it already exists and is non-empty, a warning message
about that is sent to standard error, and the output is appended to the
The --quiet option suppresses both the rsasigkey narrative and the
existing-file warning message.
The --bits option specifies the number of bits in the key; the current
default is 2192 and we do not recommend use of anything shorter unless
unusual constraints demand it.
The --hostname option is passed through to rsasigkey to tell it what
host name to label the output with (via its --hostname option).
The output format is that of rsasigkey, with bracketing added to com‐
plete the ipsec.secrets format. In the usual case, where ipsec.secrets
contains only the host’s own private key, the output of newhostkey is
sufficient as a complete ipsec.secrets file.
Written for the Linux FreeS/WAN project <http://www.freeswan.org> by
As with rsasigkey, the run time is difficult to predict, since deple‐
tion of the system’s randomness pool can cause arbitrarily long waits
for random bits, and the prime-number searches can also take unpre‐
dictable (and potentially large) amounts of CPU time. See
ipsec_rsasigkey(8) for some typical performance numbers.
A higher-level tool which could handle the clerical details of changing
to a new key would be helpful.
The requirement for --output is a blemish, but private keys are
extremely sensitive information and unusual precautions seem justified.
4 March 2002 IPSEC_NEWHOSTKEY(8)