Adding upstream version 1:9.2p1.upstream/1%9.2p1upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 902 insertions, 0 deletions

diff --git a/ssh-keygen.0 b/ssh-keygen.0
new file mode 100644
index 0000000..4b2e356
--- /dev/null
+++ b/ssh-keygen.0
@@ -0,0 +1,902 @@
+SSH-KEYGEN(1)               General Commands Manual              SSH-KEYGEN(1)
+
+NAME
+     ssh-keygen M-bM-^@M-^S OpenSSH authentication key utility
+
+SYNOPSIS
+     ssh-keygen [-q] [-a rounds] [-b bits] [-C comment] [-f output_keyfile]
+                [-m format] [-N new_passphrase] [-O option]
+                [-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]
+                [-w provider] [-Z cipher]
+     ssh-keygen -p [-a rounds] [-f keyfile] [-m format] [-N new_passphrase]
+                [-P old_passphrase] [-Z cipher]
+     ssh-keygen -i [-f input_keyfile] [-m key_format]
+     ssh-keygen -e [-f input_keyfile] [-m key_format]
+     ssh-keygen -y [-f input_keyfile]
+     ssh-keygen -c [-a rounds] [-C comment] [-f keyfile] [-P passphrase]
+     ssh-keygen -l [-v] [-E fingerprint_hash] [-f input_keyfile]
+     ssh-keygen -B [-f input_keyfile]
+     ssh-keygen -D pkcs11
+     ssh-keygen -F hostname [-lv] [-f known_hosts_file]
+     ssh-keygen -H [-f known_hosts_file]
+     ssh-keygen -K [-a rounds] [-w provider]
+     ssh-keygen -R hostname [-f known_hosts_file]
+     ssh-keygen -r hostname [-g] [-f input_keyfile]
+     ssh-keygen -M generate [-O option] output_file
+     ssh-keygen -M screen [-f input_file] [-O option] output_file
+     ssh-keygen -I certificate_identity -s ca_key [-hU] [-D pkcs11_provider]
+                [-n principals] [-O option] [-V validity_interval]
+                [-z serial_number] file ...
+     ssh-keygen -L [-f input_keyfile]
+     ssh-keygen -A [-a rounds] [-f prefix_path]
+     ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number]
+                file ...
+     ssh-keygen -Q [-l] -f krl_file file ...
+     ssh-keygen -Y find-principals [-O option] -s signature_file
+                -f allowed_signers_file
+     ssh-keygen -Y match-principals -I signer_identity -f allowed_signers_file
+     ssh-keygen -Y check-novalidate [-O option] -n namespace -s signature_file
+     ssh-keygen -Y sign [-O option] -f key_file -n namespace file ...
+     ssh-keygen -Y verify [-O option] -f allowed_signers_file
+                -I signer_identity -n namespace -s signature_file
+                [-r revocation_file]
+
+DESCRIPTION
+     ssh-keygen generates, manages and converts authentication keys for
+     ssh(1).  ssh-keygen can create keys for use by SSH protocol version 2.
+
+     The type of key to be generated is specified with the -t option.  If
+     invoked without any arguments, ssh-keygen will generate an RSA key.
+
+     ssh-keygen is also used to generate groups for use in Diffie-Hellman
+     group exchange (DH-GEX).  See the MODULI GENERATION section for details.
+
+     Finally, ssh-keygen can be used to generate and update Key Revocation
+     Lists, and to test whether given keys have been revoked by one.  See the
+     KEY REVOCATION LISTS section for details.
+
+     Normally each user wishing to use SSH with public key authentication runs
+     this once to create the authentication key in ~/.ssh/id_dsa,
+     ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519,
+     ~/.ssh/id_ed25519_sk or ~/.ssh/id_rsa.  Additionally, the system
+     administrator may use this to generate host keys, as seen in /etc/rc.
+
+     Normally this program generates the key and asks for a file in which to
+     store the private key.  The public key is stored in a file with the same
+     name but M-bM-^@M-^\.pubM-bM-^@M-^] appended.  The program also asks for a passphrase.  The
+     passphrase may be empty to indicate no passphrase (host keys must have an
+     empty passphrase), or it may be a string of arbitrary length.  A
+     passphrase is similar to a password, except it can be a phrase with a
+     series of words, punctuation, numbers, whitespace, or any string of
+     characters you want.  Good passphrases are 10-30 characters long, are not
+     simple sentences or otherwise easily guessable (English prose has only
+     1-2 bits of entropy per character, and provides very bad passphrases),
+     and contain a mix of upper and lowercase letters, numbers, and non-
+     alphanumeric characters.  The passphrase can be changed later by using
+     the -p option.
+
+     There is no way to recover a lost passphrase.  If the passphrase is lost
+     or forgotten, a new key must be generated and the corresponding public
+     key copied to other machines.
+
+     ssh-keygen will by default write keys in an OpenSSH-specific format.
+     This format is preferred as it offers better protection for keys at rest
+     as well as allowing storage of key comments within the private key file
+     itself.  The key comment may be useful to help identify the key.  The
+     comment is initialized to M-bM-^@M-^\user@hostM-bM-^@M-^] when the key is created, but can be
+     changed using the -c option.
+
+     It is still possible for ssh-keygen to write the previously-used PEM
+     format private keys using the -m flag.  This may be used when generating
+     new keys, and existing new-format keys may be converted using this option
+     in conjunction with the -p (change passphrase) flag.
+
+     After a key is generated, ssh-keygen will ask where the keys should be
+     placed to be activated.
+
+     The options are as follows:
+
+     -A      Generate host keys of all default key types (rsa, ecdsa, and
+             ed25519) if they do not already exist.  The host keys are
+             generated with the default key file path, an empty passphrase,
+             default bits for the key type, and default comment.  If -f has
+             also been specified, its argument is used as a prefix to the
+             default path for the resulting host key files.  This is used by
+             /etc/rc to generate new host keys.
+
+     -a rounds
+             When saving a private key, this option specifies the number of
+             KDF (key derivation function, currently bcrypt_pbkdf(3)) rounds
+             used.  Higher numbers result in slower passphrase verification
+             and increased resistance to brute-force password cracking (should
+             the keys be stolen).  The default is 16 rounds.
+
+     -B      Show the bubblebabble digest of specified private or public key
+             file.
+
+     -b bits
+             Specifies the number of bits in the key to create.  For RSA keys,
+             the minimum size is 1024 bits and the default is 3072 bits.
+             Generally, 3072 bits is considered sufficient.  DSA keys must be
+             exactly 1024 bits as specified by FIPS 186-2.  For ECDSA keys,
+             the -b flag determines the key length by selecting from one of
+             three elliptic curve sizes: 256, 384 or 521 bits.  Attempting to
+             use bit lengths other than these three values for ECDSA keys will
+             fail.  ECDSA-SK, Ed25519 and Ed25519-SK keys have a fixed length
+             and the -b flag will be ignored.
+
+     -C comment
+             Provides a new comment.
+
+     -c      Requests changing the comment in the private and public key
+             files.  The program will prompt for the file containing the
+             private keys, for the passphrase if the key has one, and for the
+             new comment.
+
+     -D pkcs11
+             Download the public keys provided by the PKCS#11 shared library
+             pkcs11.  When used in combination with -s, this option indicates
+             that a CA key resides in a PKCS#11 token (see the CERTIFICATES
+             section for details).
+
+     -E fingerprint_hash
+             Specifies the hash algorithm used when displaying key
+             fingerprints.  Valid options are: M-bM-^@M-^\md5M-bM-^@M-^] and M-bM-^@M-^\sha256M-bM-^@M-^].  The
+             default is M-bM-^@M-^\sha256M-bM-^@M-^].
+
+     -e      This option will read a private or public OpenSSH key file and
+             print to stdout a public key in one of the formats specified by
+             the -m option.  The default export format is M-bM-^@M-^\RFC4716M-bM-^@M-^].  This
+             option allows exporting OpenSSH keys for use by other programs,
+             including several commercial SSH implementations.
+
+     -F hostname | [hostname]:port
+             Search for the specified hostname (with optional port number) in
+             a known_hosts file, listing any occurrences found.  This option
+             is useful to find hashed host names or addresses and may also be
+             used in conjunction with the -H option to print found keys in a
+             hashed format.
+
+     -f filename
+             Specifies the filename of the key file.
+
+     -g      Use generic DNS format when printing fingerprint resource records
+             using the -r command.
+
+     -H      Hash a known_hosts file.  This replaces all hostnames and
+             addresses with hashed representations within the specified file;
+             the original content is moved to a file with a .old suffix.
+             These hashes may be used normally by ssh and sshd, but they do
+             not reveal identifying information should the file's contents be
+             disclosed.  This option will not modify existing hashed hostnames
+             and is therefore safe to use on files that mix hashed and non-
+             hashed names.
+
+     -h      When signing a key, create a host certificate instead of a user
+             certificate.  See the CERTIFICATES section for details.
+
+     -I certificate_identity
+             Specify the key identity when signing a public key.  See the
+             CERTIFICATES section for details.
+
+     -i      This option will read an unencrypted private (or public) key file
+             in the format specified by the -m option and print an OpenSSH
+             compatible private (or public) key to stdout.  This option allows
+             importing keys from other software, including several commercial
+             SSH implementations.  The default import format is M-bM-^@M-^\RFC4716M-bM-^@M-^].
+
+     -K      Download resident keys from a FIDO authenticator.  Public and
+             private key files will be written to the current directory for
+             each downloaded key.  If multiple FIDO authenticators are
+             attached, keys will be downloaded from the first touched
+             authenticator.  See the FIDO AUTHENTICATOR section for more
+             information.
+
+     -k      Generate a KRL file.  In this mode, ssh-keygen will generate a
+             KRL file at the location specified via the -f flag that revokes
+             every key or certificate presented on the command line.
+             Keys/certificates to be revoked may be specified by public key
+             file or using the format described in the KEY REVOCATION LISTS
+             section.
+
+     -L      Prints the contents of one or more certificates.
+
+     -l      Show fingerprint of specified public key file.  For RSA and DSA
+             keys ssh-keygen tries to find the matching public key file and
+             prints its fingerprint.  If combined with -v, a visual ASCII art
+             representation of the key is supplied with the fingerprint.
+
+     -M generate
+             Generate candidate Diffie-Hellman Group Exchange (DH-GEX)
+             parameters for eventual use by the
+             M-bM-^@M-^Xdiffie-hellman-group-exchange-*M-bM-^@M-^Y key exchange methods.  The
+             numbers generated by this operation must be further screened
+             before use.  See the MODULI GENERATION section for more
+             information.
+
+     -M screen
+             Screen candidate parameters for Diffie-Hellman Group Exchange.
+             This will accept a list of candidate numbers and test that they
+             are safe (Sophie Germain) primes with acceptable group
+             generators.  The results of this operation may be added to the
+             /etc/moduli file.  See the MODULI GENERATION section for more
+             information.
+
+     -m key_format
+             Specify a key format for key generation, the -i (import), -e
+             (export) conversion options, and the -p change passphrase
+             operation.  The latter may be used to convert between OpenSSH
+             private key and PEM private key formats.  The supported key
+             formats are: M-bM-^@M-^\RFC4716M-bM-^@M-^] (RFC 4716/SSH2 public or private key),
+             M-bM-^@M-^\PKCS8M-bM-^@M-^] (PKCS8 public or private key) or M-bM-^@M-^\PEMM-bM-^@M-^] (PEM public key).
+             By default OpenSSH will write newly-generated private keys in its
+             own format, but when converting public keys for export the
+             default format is M-bM-^@M-^\RFC4716M-bM-^@M-^].  Setting a format of M-bM-^@M-^\PEMM-bM-^@M-^] when
+             generating or updating a supported private key type will cause
+             the key to be stored in the legacy PEM private key format.
+
+     -N new_passphrase
+             Provides the new passphrase.
+
+     -n principals
+             Specify one or more principals (user or host names) to be
+             included in a certificate when signing a key.  Multiple
+             principals may be specified, separated by commas.  See the
+             CERTIFICATES section for details.
+
+     -O option
+             Specify a key/value option.  These are specific to the operation
+             that ssh-keygen has been requested to perform.
+
+             When signing certificates, one of the options listed in the
+             CERTIFICATES section may be specified here.
+
+             When performing moduli generation or screening, one of the
+             options listed in the MODULI GENERATION section may be specified.
+
+             When generating FIDO authenticator-backed keys, the options
+             listed in the FIDO AUTHENTICATOR section may be specified.
+
+             When performing signature-related options using the -Y flag, the
+             following options are accepted:
+
+             hashalg=algorithm
+                     Selects the hash algorithm to use for hashing the message
+                     to be signed.  Valid algorithms are M-bM-^@M-^\sha256M-bM-^@M-^] and
+                     M-bM-^@M-^\sha512.M-bM-^@M-^] The default is M-bM-^@M-^\sha512.M-bM-^@M-^]
+
+             print-pubkey
+                     Print the full public key to standard output after
+                     signature verification.
+
+             verify-time=timestamp
+                     Specifies a time to use when validating signatures
+                     instead of the current time.  The time may be specified
+                     as a date or time in the YYYYMMDD[Z] or in
+                     YYYYMMDDHHMM[SS][Z] formats.  Dates and times will be
+                     interpreted in the current system time zone unless
+                     suffixed with a Z character, which causes them to be
+                     interpreted in the UTC time zone.
+
+             The -O option may be specified multiple times.
+
+     -P passphrase
+             Provides the (old) passphrase.
+
+     -p      Requests changing the passphrase of a private key file instead of
+             creating a new private key.  The program will prompt for the file
+             containing the private key, for the old passphrase, and twice for
+             the new passphrase.
+
+     -Q      Test whether keys have been revoked in a KRL.  If the -l option
+             is also specified then the contents of the KRL will be printed.
+
+     -q      Silence ssh-keygen.
+
+     -R hostname | [hostname]:port
+             Removes all keys belonging to the specified hostname (with
+             optional port number) from a known_hosts file.  This option is
+             useful to delete hashed hosts (see the -H option above).
+
+     -r hostname
+             Print the SSHFP fingerprint resource record named hostname for
+             the specified public key file.
+
+     -s ca_key
+             Certify (sign) a public key using the specified CA key.  See the
+             CERTIFICATES section for details.
+
+             When generating a KRL, -s specifies a path to a CA public key
+             file used to revoke certificates directly by key ID or serial
+             number.  See the KEY REVOCATION LISTS section for details.
+
+     -t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa
+             Specifies the type of key to create.  The possible values are
+             M-bM-^@M-^\dsaM-bM-^@M-^], M-bM-^@M-^\ecdsaM-bM-^@M-^], M-bM-^@M-^\ecdsa-skM-bM-^@M-^], M-bM-^@M-^\ed25519M-bM-^@M-^], M-bM-^@M-^\ed25519-skM-bM-^@M-^], or M-bM-^@M-^\rsaM-bM-^@M-^].
+
+             This flag may also be used to specify the desired signature type
+             when signing certificates using an RSA CA key.  The available RSA
+             signature variants are M-bM-^@M-^\ssh-rsaM-bM-^@M-^] (SHA1 signatures, not
+             recommended), M-bM-^@M-^\rsa-sha2-256M-bM-^@M-^], and M-bM-^@M-^\rsa-sha2-512M-bM-^@M-^] (the default).
+
+     -U      When used in combination with -s or -Y sign, this option
+             indicates that a CA key resides in a ssh-agent(1).  See the
+             CERTIFICATES section for more information.
+
+     -u      Update a KRL.  When specified with -k, keys listed via the
+             command line are added to the existing KRL rather than a new KRL
+             being created.
+
+     -V validity_interval
+             Specify a validity interval when signing a certificate.  A
+             validity interval may consist of a single time, indicating that
+             the certificate is valid beginning now and expiring at that time,
+             or may consist of two times separated by a colon to indicate an
+             explicit time interval.
+
+             The start time may be specified as:
+             M-bM-^@M-M-bM-^@M-"   The string M-bM-^@M-^\alwaysM-bM-^@M-^] to indicate the certificate has no
+                 specified start time.
+             M-bM-^@M-M-bM-^@M-"   A date or time in the system time zone formatted as YYYYMMDD
+                 or YYYYMMDDHHMM[SS].
+             M-bM-^@M-M-bM-^@M-"   A date or time in the UTC time zone as YYYYMMDDZ or
+                 YYYYMMDDHHMM[SS]Z.
+             M-bM-^@M-M-bM-^@M-"   A relative time before the current system time consisting of
+                 a minus sign followed by an interval in the format described
+                 in the TIME FORMATS section of sshd_config(5).
+             M-bM-^@M-M-bM-^@M-"   A raw seconds since epoch (Jan 1 1970 00:00:00 UTC) as a
+                 hexadecimal number beginning with M-bM-^@M-^\0xM-bM-^@M-^].
+
+             The end time may be specified similarly to the start time:
+             M-bM-^@M-M-bM-^@M-"   The string M-bM-^@M-^\foreverM-bM-^@M-^] to indicate the certificate has no
+                 specified end time.
+             M-bM-^@M-M-bM-^@M-"   A date or time in the system time zone formatted as YYYYMMDD
+                 or YYYYMMDDHHMM[SS].
+             M-bM-^@M-M-bM-^@M-"   A date or time in the UTC time zone as YYYYMMDDZ or
+                 YYYYMMDDHHMM[SS]Z.
+             M-bM-^@M-M-bM-^@M-"   A relative time after the current system time consisting of a
+                 plus sign followed by an interval in the format described in
+                 the TIME FORMATS section of sshd_config(5).
+             M-bM-^@M-M-bM-^@M-"   A raw seconds since epoch (Jan 1 1970 00:00:00 UTC) as a
+                 hexadecimal number beginning with M-bM-^@M-^\0xM-bM-^@M-^].
+
+             For example:
+
+             +52w1d  Valid from now to 52 weeks and one day from now.
+
+             -4w:+4w
+                     Valid from four weeks ago to four weeks from now.
+
+             20100101123000:20110101123000
+                     Valid from 12:30 PM, January 1st, 2010 to 12:30 PM,
+                     January 1st, 2011.
+
+             20100101123000Z:20110101123000Z
+                     Similar, but interpreted in the UTC time zone rather than
+                     the system time zone.
+
+             -1d:20110101
+                     Valid from yesterday to midnight, January 1st, 2011.
+
+             0x1:0x2000000000
+                     Valid from roughly early 1970 to May 2033.
+
+             -1m:forever
+                     Valid from one minute ago and never expiring.
+
+     -v      Verbose mode.  Causes ssh-keygen to print debugging messages
+             about its progress.  This is helpful for debugging moduli
+             generation.  Multiple -v options increase the verbosity.  The
+             maximum is 3.
+
+     -w provider
+             Specifies a path to a library that will be used when creating
+             FIDO authenticator-hosted keys, overriding the default of using
+             the internal USB HID support.
+
+     -Y find-principals
+             Find the principal(s) associated with the public key of a
+             signature, provided using the -s flag in an authorized signers
+             file provided using the -f flag.  The format of the allowed
+             signers file is documented in the ALLOWED SIGNERS section below.
+             If one or more matching principals are found, they are returned
+             on standard output.
+
+     -Y match-principals
+             Find principal matching the principal name provided using the -I
+             flag in the authorized signers file specified using the -f flag.
+             If one or more matching principals are found, they are returned
+             on standard output.
+
+     -Y check-novalidate
+             Checks that a signature generated using ssh-keygen -Y sign has a
+             valid structure.  This does not validate if a signature comes
+             from an authorized signer.  When testing a signature, ssh-keygen
+             accepts a message on standard input and a signature namespace
+             using -n.  A file containing the corresponding signature must
+             also be supplied using the -s flag.  Successful testing of the
+             signature is signalled by ssh-keygen returning a zero exit
+             status.
+
+     -Y sign
+             Cryptographically sign a file or some data using a SSH key.  When
+             signing, ssh-keygen accepts zero or more files to sign on the
+             command-line - if no files are specified then ssh-keygen will
+             sign data presented on standard input.  Signatures are written to
+             the path of the input file with M-bM-^@M-^\.sigM-bM-^@M-^] appended, or to standard
+             output if the message to be signed was read from standard input.
+
+             The key used for signing is specified using the -f option and may
+             refer to either a private key, or a public key with the private
+             half available via ssh-agent(1).  An additional signature
+             namespace, used to prevent signature confusion across different
+             domains of use (e.g. file signing vs email signing) must be
+             provided via the -n flag.  Namespaces are arbitrary strings, and
+             may include: M-bM-^@M-^\fileM-bM-^@M-^] for file signing, M-bM-^@M-^\emailM-bM-^@M-^] for email signing.
+             For custom uses, it is recommended to use names following a
+             NAMESPACE@YOUR.DOMAIN pattern to generate unambiguous namespaces.
+
+     -Y verify
+             Request to verify a signature generated using ssh-keygen -Y sign
+             as described above.  When verifying a signature, ssh-keygen
+             accepts a message on standard input and a signature namespace
+             using -n.  A file containing the corresponding signature must
+             also be supplied using the -s flag, along with the identity of
+             the signer using -I and a list of allowed signers via the -f
+             flag.  The format of the allowed signers file is documented in
+             the ALLOWED SIGNERS section below.  A file containing revoked
+             keys can be passed using the -r flag.  The revocation file may be
+             a KRL or a one-per-line list of public keys.  Successful
+             verification by an authorized signer is signalled by ssh-keygen
+             returning a zero exit status.
+
+     -y      This option will read a private OpenSSH format file and print an
+             OpenSSH public key to stdout.
+
+     -Z cipher
+             Specifies the cipher to use for encryption when writing an
+             OpenSSH-format private key file.  The list of available ciphers
+             may be obtained using "ssh -Q cipher".  The default is
+             M-bM-^@M-^\aes256-ctrM-bM-^@M-^].
+
+     -z serial_number
+             Specifies a serial number to be embedded in the certificate to
+             distinguish this certificate from others from the same CA.  If
+             the serial_number is prefixed with a M-bM-^@M-^X+M-bM-^@M-^Y character, then the
+             serial number will be incremented for each certificate signed on
+             a single command-line.  The default serial number is zero.
+
+             When generating a KRL, the -z flag is used to specify a KRL
+             version number.
+
+MODULI GENERATION
+     ssh-keygen may be used to generate groups for the Diffie-Hellman Group
+     Exchange (DH-GEX) protocol.  Generating these groups is a two-step
+     process: first, candidate primes are generated using a fast, but memory
+     intensive process.  These candidate primes are then tested for
+     suitability (a CPU-intensive process).
+
+     Generation of primes is performed using the -M generate option.  The
+     desired length of the primes may be specified by the -O bits option.  For
+     example:
+
+           # ssh-keygen -M generate -O bits=2048 moduli-2048.candidates
+
+     By default, the search for primes begins at a random point in the desired
+     length range.  This may be overridden using the -O start option, which
+     specifies a different start point (in hex).
+
+     Once a set of candidates have been generated, they must be screened for
+     suitability.  This may be performed using the -M screen option.  In this
+     mode ssh-keygen will read candidates from standard input (or a file
+     specified using the -f option).  For example:
+
+           # ssh-keygen -M screen -f moduli-2048.candidates moduli-2048
+
+     By default, each candidate will be subjected to 100 primality tests.
+     This may be overridden using the -O prime-tests option.  The DH generator
+     value will be chosen automatically for the prime under consideration.  If
+     a specific generator is desired, it may be requested using the -O
+     generator option.  Valid generator values are 2, 3, and 5.
+
+     Screened DH groups may be installed in /etc/moduli.  It is important that
+     this file contains moduli of a range of bit lengths.
+
+     A number of options are available for moduli generation and screening via
+     the -O flag:
+
+     lines=number
+             Exit after screening the specified number of lines while
+             performing DH candidate screening.
+
+     start-line=line-number
+             Start screening at the specified line number while performing DH
+             candidate screening.
+
+     checkpoint=filename
+             Write the last line processed to the specified file while
+             performing DH candidate screening.  This will be used to skip
+             lines in the input file that have already been processed if the
+             job is restarted.
+
+     memory=mbytes
+             Specify the amount of memory to use (in megabytes) when
+             generating candidate moduli for DH-GEX.
+
+     start=hex-value
+             Specify start point (in hex) when generating candidate moduli for
+             DH-GEX.
+
+     generator=value
+             Specify desired generator (in decimal) when testing candidate
+             moduli for DH-GEX.
+
+CERTIFICATES
+     ssh-keygen supports signing of keys to produce certificates that may be
+     used for user or host authentication.  Certificates consist of a public
+     key, some identity information, zero or more principal (user or host)
+     names and a set of options that are signed by a Certification Authority
+     (CA) key.  Clients or servers may then trust only the CA key and verify
+     its signature on a certificate rather than trusting many user/host keys.
+     Note that OpenSSH certificates are a different, and much simpler, format
+     to the X.509 certificates used in ssl(8).
+
+     ssh-keygen supports two types of certificates: user and host.  User
+     certificates authenticate users to servers, whereas host certificates
+     authenticate server hosts to users.  To generate a user certificate:
+
+           $ ssh-keygen -s /path/to/ca_key -I key_id /path/to/user_key.pub
+
+     The resultant certificate will be placed in /path/to/user_key-cert.pub.
+     A host certificate requires the -h option:
+
+           $ ssh-keygen -s /path/to/ca_key -I key_id -h /path/to/host_key.pub
+
+     The host certificate will be output to /path/to/host_key-cert.pub.
+
+     It is possible to sign using a CA key stored in a PKCS#11 token by
+     providing the token library using -D and identifying the CA key by
+     providing its public half as an argument to -s:
+
+           $ ssh-keygen -s ca_key.pub -D libpkcs11.so -I key_id user_key.pub
+
+     Similarly, it is possible for the CA key to be hosted in a ssh-agent(1).
+     This is indicated by the -U flag and, again, the CA key must be
+     identified by its public half.
+
+           $ ssh-keygen -Us ca_key.pub -I key_id user_key.pub
+
+     In all cases, key_id is a "key identifier" that is logged by the server
+     when the certificate is used for authentication.
+
+     Certificates may be limited to be valid for a set of principal
+     (user/host) names.  By default, generated certificates are valid for all
+     users or hosts.  To generate a certificate for a specified set of
+     principals:
+
+           $ ssh-keygen -s ca_key -I key_id -n user1,user2 user_key.pub
+           $ ssh-keygen -s ca_key -I key_id -h -n host.domain host_key.pub
+
+     Additional limitations on the validity and use of user certificates may
+     be specified through certificate options.  A certificate option may
+     disable features of the SSH session, may be valid only when presented
+     from particular source addresses or may force the use of a specific
+     command.
+
+     The options that are valid for user certificates are:
+
+     clear   Clear all enabled permissions.  This is useful for clearing the
+             default set of permissions so permissions may be added
+             individually.
+
+     critical:name[=contents]
+     extension:name[=contents]
+             Includes an arbitrary certificate critical option or extension.
+             The specified name should include a domain suffix, e.g.
+             M-bM-^@M-^\name@example.comM-bM-^@M-^].  If contents is specified then it is included
+             as the contents of the extension/option encoded as a string,
+             otherwise the extension/option is created with no contents
+             (usually indicating a flag).  Extensions may be ignored by a
+             client or server that does not recognise them, whereas unknown
+             critical options will cause the certificate to be refused.
+
+     force-command=command
+             Forces the execution of command instead of any shell or command
+             specified by the user when the certificate is used for
+             authentication.
+
+     no-agent-forwarding
+             Disable ssh-agent(1) forwarding (permitted by default).
+
+     no-port-forwarding
+             Disable port forwarding (permitted by default).
+
+     no-pty  Disable PTY allocation (permitted by default).
+
+     no-user-rc
+             Disable execution of ~/.ssh/rc by sshd(8) (permitted by default).
+
+     no-x11-forwarding
+             Disable X11 forwarding (permitted by default).
+
+     permit-agent-forwarding
+             Allows ssh-agent(1) forwarding.
+
+     permit-port-forwarding
+             Allows port forwarding.
+
+     permit-pty
+             Allows PTY allocation.
+
+     permit-user-rc
+             Allows execution of ~/.ssh/rc by sshd(8).
+
+     permit-X11-forwarding
+             Allows X11 forwarding.
+
+     no-touch-required
+             Do not require signatures made using this key include
+             demonstration of user presence (e.g. by having the user touch the
+             authenticator).  This option only makes sense for the FIDO
+             authenticator algorithms ecdsa-sk and ed25519-sk.
+
+     source-address=address_list
+             Restrict the source addresses from which the certificate is
+             considered valid.  The address_list is a comma-separated list of
+             one or more address/netmask pairs in CIDR format.
+
+     verify-required
+             Require signatures made using this key indicate that the user was
+             first verified.  This option only makes sense for the FIDO
+             authenticator algorithms ecdsa-sk and ed25519-sk.  Currently PIN
+             authentication is the only supported verification method, but
+             other methods may be supported in the future.
+
+     At present, no standard options are valid for host keys.
+
+     Finally, certificates may be defined with a validity lifetime.  The -V
+     option allows specification of certificate start and end times.  A
+     certificate that is presented at a time outside this range will not be
+     considered valid.  By default, certificates are valid from the UNIX Epoch
+     to the distant future.
+
+     For certificates to be used for user or host authentication, the CA
+     public key must be trusted by sshd(8) or ssh(1).  Refer to those manual
+     pages for details.
+
+FIDO AUTHENTICATOR
+     ssh-keygen is able to generate FIDO authenticator-backed keys, after
+     which they may be used much like any other key type supported by OpenSSH,
+     so long as the hardware authenticator is attached when the keys are used.
+     FIDO authenticators generally require the user to explicitly authorise
+     operations by touching or tapping them.  FIDO keys consist of two parts:
+     a key handle part stored in the private key file on disk, and a per-
+     device private key that is unique to each FIDO authenticator and that
+     cannot be exported from the authenticator hardware.  These are combined
+     by the hardware at authentication time to derive the real key that is
+     used to sign authentication challenges.  Supported key types are ecdsa-sk
+     and ed25519-sk.
+
+     The options that are valid for FIDO keys are:
+
+     application
+             Override the default FIDO application/origin string of M-bM-^@M-^\ssh:M-bM-^@M-^].
+             This may be useful when generating host or domain-specific
+             resident keys.  The specified application string must begin with
+             M-bM-^@M-^\ssh:M-bM-^@M-^].
+
+     challenge=path
+             Specifies a path to a challenge string that will be passed to the
+             FIDO authenticator during key generation.  The challenge string
+             may be used as part of an out-of-band protocol for key enrollment
+             (a random challenge is used by default).
+
+     device  Explicitly specify a fido(4) device to use, rather than letting
+             the authenticator middleware select one.
+
+     no-touch-required
+             Indicate that the generated private key should not require touch
+             events (user presence) when making signatures.  Note that sshd(8)
+             will refuse such signatures by default, unless overridden via an
+             authorized_keys option.
+
+     resident
+             Indicate that the key handle should be stored on the FIDO
+             authenticator itself.  This makes it easier to use the
+             authenticator on multiple computers.  Resident keys may be
+             supported on FIDO2 authenticators and typically require that a
+             PIN be set on the authenticator prior to generation.  Resident
+             keys may be loaded off the authenticator using ssh-add(1).
+             Storing both parts of a key on a FIDO authenticator increases the
+             likelihood of an attacker being able to use a stolen
+             authenticator device.
+
+     user    A username to be associated with a resident key, overriding the
+             empty default username.  Specifying a username may be useful when
+             generating multiple resident keys for the same application name.
+
+     verify-required
+             Indicate that this private key should require user verification
+             for each signature.  Not all FIDO authenticators support this
+             option.  Currently PIN authentication is the only supported
+             verification method, but other methods may be supported in the
+             future.
+
+     write-attestation=path
+             May be used at key generation time to record the attestation data
+             returned from FIDO authenticators during key generation.  This
+             information is potentially sensitive.  By default, this
+             information is discarded.
+
+KEY REVOCATION LISTS
+     ssh-keygen is able to manage OpenSSH format Key Revocation Lists (KRLs).
+     These binary files specify keys or certificates to be revoked using a
+     compact format, taking as little as one bit per certificate if they are
+     being revoked by serial number.
+
+     KRLs may be generated using the -k flag.  This option reads one or more
+     files from the command line and generates a new KRL.  The files may
+     either contain a KRL specification (see below) or public keys, listed one
+     per line.  Plain public keys are revoked by listing their hash or
+     contents in the KRL and certificates revoked by serial number or key ID
+     (if the serial is zero or not available).
+
+     Revoking keys using a KRL specification offers explicit control over the
+     types of record used to revoke keys and may be used to directly revoke
+     certificates by serial number or key ID without having the complete
+     original certificate on hand.  A KRL specification consists of lines
+     containing one of the following directives followed by a colon and some
+     directive-specific information.
+
+     serial: serial_number[-serial_number]
+             Revokes a certificate with the specified serial number.  Serial
+             numbers are 64-bit values, not including zero and may be
+             expressed in decimal, hex or octal.  If two serial numbers are
+             specified separated by a hyphen, then the range of serial numbers
+             including and between each is revoked.  The CA key must have been
+             specified on the ssh-keygen command line using the -s option.
+
+     id: key_id
+             Revokes a certificate with the specified key ID string.  The CA
+             key must have been specified on the ssh-keygen command line using
+             the -s option.
+
+     key: public_key
+             Revokes the specified key.  If a certificate is listed, then it
+             is revoked as a plain public key.
+
+     sha1: public_key
+             Revokes the specified key by including its SHA1 hash in the KRL.
+
+     sha256: public_key
+             Revokes the specified key by including its SHA256 hash in the
+             KRL.  KRLs that revoke keys by SHA256 hash are not supported by
+             OpenSSH versions prior to 7.9.
+
+     hash: fingerprint
+             Revokes a key using a fingerprint hash, as obtained from a
+             sshd(8) authentication log message or the ssh-keygen -l flag.
+             Only SHA256 fingerprints are supported here and resultant KRLs
+             are not supported by OpenSSH versions prior to 7.9.
+
+     KRLs may be updated using the -u flag in addition to -k.  When this
+     option is specified, keys listed via the command line are merged into the
+     KRL, adding to those already there.
+
+     It is also possible, given a KRL, to test whether it revokes a particular
+     key (or keys).  The -Q flag will query an existing KRL, testing each key
+     specified on the command line.  If any key listed on the command line has
+     been revoked (or an error encountered) then ssh-keygen will exit with a
+     non-zero exit status.  A zero exit status will only be returned if no key
+     was revoked.
+
+ALLOWED SIGNERS
+     When verifying signatures, ssh-keygen uses a simple list of identities
+     and keys to determine whether a signature comes from an authorized
+     source.  This "allowed signers" file uses a format patterned after the
+     AUTHORIZED_KEYS FILE FORMAT described in sshd(8).  Each line of the file
+     contains the following space-separated fields: principals, options,
+     keytype, base64-encoded key.  Empty lines and lines starting with a M-bM-^@M-^X#M-bM-^@M-^Y
+     are ignored as comments.
+
+     The principals field is a pattern-list (see PATTERNS in ssh_config(5))
+     consisting of one or more comma-separated USER@DOMAIN identity patterns
+     that are accepted for signing.  When verifying, the identity presented
+     via the -I option must match a principals pattern in order for the
+     corresponding key to be considered acceptable for verification.
+
+     The options (if present) consist of comma-separated option
+     specifications.  No spaces are permitted, except within double quotes.
+     The following option specifications are supported (note that option
+     keywords are case-insensitive):
+
+     cert-authority
+             Indicates that this key is accepted as a certificate authority
+             (CA) and that certificates signed by this CA may be accepted for
+             verification.
+
+     namespaces=namespace-list
+             Specifies a pattern-list of namespaces that are accepted for this
+             key.  If this option is present, the signature namespace embedded
+             in the signature object and presented on the verification
+             command-line must match the specified list before the key will be
+             considered acceptable.
+
+     valid-after=timestamp
+             Indicates that the key is valid for use at or after the specified
+             timestamp, which may be a date or time in the YYYYMMDD[Z] or
+             YYYYMMDDHHMM[SS][Z] formats.  Dates and times will be interpreted
+             in the current system time zone unless suffixed with a Z
+             character, which causes them to be interpreted in the UTC time
+             zone.
+
+     valid-before=timestamp
+             Indicates that the key is valid for use at or before the
+             specified timestamp.
+
+     When verifying signatures made by certificates, the expected principal
+     name must match both the principals pattern in the allowed signers file
+     and the principals embedded in the certificate itself.
+
+     An example allowed signers file:
+
+        # Comments allowed at start of line
+        user1@example.com,user2@example.com ssh-rsa AAAAX1...
+        # A certificate authority, trusted for all principals in a domain.
+        *@example.com cert-authority ssh-ed25519 AAAB4...
+        # A key that is accepted only for file signing.
+        user2@example.com namespaces="file" ssh-ed25519 AAA41...
+
+ENVIRONMENT
+     SSH_SK_PROVIDER
+             Specifies a path to a library that will be used when loading any
+             FIDO authenticator-hosted keys, overriding the default of using
+             the built-in USB HID support.
+
+FILES
+     ~/.ssh/id_dsa
+     ~/.ssh/id_ecdsa
+     ~/.ssh/id_ecdsa_sk
+     ~/.ssh/id_ed25519
+     ~/.ssh/id_ed25519_sk
+     ~/.ssh/id_rsa
+             Contains the DSA, ECDSA, authenticator-hosted ECDSA, Ed25519,
+             authenticator-hosted Ed25519 or RSA authentication identity of
+             the user.  This file should not be readable by anyone but the
+             user.  It is possible to specify a passphrase when generating the
+             key; that passphrase will be used to encrypt the private part of
+             this file using 128-bit AES.  This file is not automatically
+             accessed by ssh-keygen but it is offered as the default file for
+             the private key.  ssh(1) will read this file when a login attempt
+             is made.
+
+     ~/.ssh/id_dsa.pub
+     ~/.ssh/id_ecdsa.pub
+     ~/.ssh/id_ecdsa_sk.pub
+     ~/.ssh/id_ed25519.pub
+     ~/.ssh/id_ed25519_sk.pub
+     ~/.ssh/id_rsa.pub
+             Contains the DSA, ECDSA, authenticator-hosted ECDSA, Ed25519,
+             authenticator-hosted Ed25519 or RSA public key for
+             authentication.  The contents of this file should be added to
+             ~/.ssh/authorized_keys on all machines where the user wishes to
+             log in using public key authentication.  There is no need to keep
+             the contents of this file secret.
+
+     /etc/moduli
+             Contains Diffie-Hellman groups used for DH-GEX.  The file format
+             is described in moduli(5).
+
+SEE ALSO
+     ssh(1), ssh-add(1), ssh-agent(1), moduli(5), sshd(8)
+
+     The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006.
+
+AUTHORS
+     OpenSSH is a derivative of the original and free ssh 1.2.12 release by
+     Tatu Ylonen.  Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
+     de Raadt and Dug Song removed many bugs, re-added newer features and
+     created OpenSSH.  Markus Friedl contributed the support for SSH protocol
+     versions 1.5 and 2.0.
+
+OpenBSD 7.2                   September 10, 2022                   OpenBSD 7.2