svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ssh-keygen(1)
generates, manages and converts authentication keys for can cre‐
ate keys for use by SSH protocol version 2. The type of key to
be generated is specified with the option. If invoked without
any arguments, will generate an Ed25519 key (RSA key if running
in FIPS-140 mode). is also used to generate groups for use in
Diffie-Hellman group exchange (DH-GEX). See the section for de‐
tails. Finally, can be used to generate and update Key Revoca‐
tion Lists, and to test whether given keys have been revoked by
one. See the section for details. Normally each user wishing to
use SSH with public key authentication runs this once to create
the authentication key in or Additionally, the system administra‐
tor may use this to generate host keys, as seen in 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 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 arbi‐
trary 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 option. There is no way to recover a lost passphrase.
If the passphrase is lost or forgotten, a new key must be gener‐
ated and the corresponding public key copied to other machines.
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 pri‐
vate key file itself. The key comment may be useful to help
identify the key. The comment is initialized to when the key is
created, but can be changed using the option. It is still possi‐
ble for to write the previously-used PEM format private keys us‐
ing the flag. This may be used when generating new keys, and ex‐
isting new-format keys may be converted using this option in con‐
junction with the (change passphrase) flag. After a key is gen‐
erated, will ask where the keys should be placed to be activated.
The options are as follows: 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 com‐
ment. If has also been specified, its argument is used as a pre‐
fix to the default path for the resulting host key files. This
is used by to generate new host keys. If OpenSSL is running in
FIPS-140 mode, only rsa and ecdsa host keys are generated. When
saving a private key, this option specifies the number of KDF
(key derivation function, currently 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. Show the bubblebabble digest of speci‐
fied private or public key file. 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. For ECDSA keys, the 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. Ed25519 key has a fixed length
and the flag will be ignored. Provides a new comment. 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.
Download the public keys provided by the PKCS#11 shared library
When used in combination with this option indicates that a CA key
resides in a PKCS#11 token (see the section for details). Speci‐
fies the hash algorithm used when displaying key fingerprints.
Valid options are: and The default is If OpenSSL is running in
FIPS-140 mode, the only supported option is 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 option. The default
export format is This option allows exporting OpenSSH keys for
use by other programs, including several commercial SSH implemen‐
tations. Search for the specified (with optional port number) in
a file, listing any occurrences found. This option is useful to
find hashed host names or addresses and may also be used in con‐
junction with the option to print found keys in a hashed format.
Specifies the filename of the key file. Use generic DNS format
when printing fingerprint resource records using the command.
Hash a 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 and but they do not reveal identifying infor‐
mation 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. When signing a
key, create a host certificate instead of a user certificate.
See the section for details. Specify the key identity when sign‐
ing a public key. See the section for details. This option will
read an unencrypted private (or public) key file in the format
specified by the option and print an OpenSSH compatible private
(or public) key to stdout. This option allows importing keys
from other software, including several commercial SSH implementa‐
tions. The default import format is Download resident keys from
a FIDO authenticator. Public and private key files will be writ‐
ten to the current directory for each downloaded key. If multi‐
ple FIDO authenticators are attached, keys will be downloaded
from the first touched authenticator. See the section for more
information. Generate a KRL file. In this mode, will generate a
KRL file at the location specified via the 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 section. Prints the
contents of one or more certificates. Show fingerprint of speci‐
fied public key file. will try to find the matching public key
file and prints its fingerprint. If combined with a visual ASCII
art representation of the key is supplied with the fingerprint.
Generate candidate Diffie-Hellman Group Exchange (DH-GEX) parame‐
ters for eventual use by the key exchange methods. The numbers
generated by this operation must be further screened before use.
See the section for more information. Screen candidate parame‐
ters 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 op‐
eration may be added to the file. See the section for more in‐
formation. Specify a key format for key generation, the (im‐
port), (export) conversion options, and the change passphrase op‐
eration. The latter may be used to convert between OpenSSH pri‐
vate key and PEM private key formats. The supported key formats
are: (RFC 4716/SSH2 public or private key), (PKCS8 public or pri‐
vate key) or (PEM public key). By default OpenSSH will write
newly-generated private keys in its own format, but when convert‐
ing public keys for export the default format is Setting a format
of when generating or updating a supported private key type will
cause the key to be stored in the legacy PEM private key format.
Provides the new passphrase. 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 com‐
mas. See the section for details. Specify a key/value option.
These are specific to the operation that has been requested to
perform. When signing certificates, one of the options listed in
the section may be specified here. When performing moduli gener‐
ation or screening, one of the options listed in the section may
be specified. When generating FIDO authenticator-backed keys,
the options listed in the section may be specified. When per‐
forming signature-related options using the flag, the following
options are accepted: Selects the hash algorithm to use for hash‐
ing the message to be signed. Valid algorithms are and The de‐
fault is Print the full public key to standard output after sig‐
nature verification. Specifies a time to use when validating
signatures instead of the current time. The time may be speci‐
fied as a date or time in the YYYYMMDD[Z] or in YYYYMMD‐
DHHMM[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. When
generating SSHFP DNS records from public keys using the flag, the
following options are accepted: Selects a hash algorithm to use
when printing SSHFP records using the flag. Valid algorithms are
and The default is to print both. The option may be specified
multiple times. Provides the (old) passphrase. Requests chang‐
ing 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. Test whether keys have been revoked in a KRL. If
the option is also specified then the contents of the KRL will be
printed. Silence Removes all keys belonging to the specified
(with optional port number) from a file. This option is useful
to delete hashed hosts (see the option above). Print the SSHFP
fingerprint resource record named for the specified public key
file. Certify (sign) a public key using the specified CA key.
See the section for details. When generating a KRL, specifies a
path to a CA public key file used to revoke certificates directly
by key ID or serial number. See the section for details. Speci‐
fies the type of key to create. The possible values are or This
flag may also be used to specify the desired signature type when
signing certificates using an RSA CA key. The available RSA sig‐
nature variants are (SHA1 signatures, not recommended), and (the
default for RSA keys). When used in combination with or this op‐
tion indicates that a CA key resides in an See the section for
more information. Update a KRL. When specified with keys listed
via the command line are added to the existing KRL rather than a
new KRL being created. 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 expir‐
ing 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: The string to indicate the certificate has no
specified start time. A date or time in the system time zone
formatted as YYYYMMDD or YYYYMMDDHHMM[SS]. A date or time in the
UTC time zone as YYYYMMDDZ or YYYYMMDDHHMM[SS]Z. A relative time
before the current system time consisting of a minus sign fol‐
lowed by an interval in the format described in the TIME FORMATS
section of A raw seconds since epoch (Jan 1 1970 00:00:00 UTC) as
a hexadecimal number beginning with The end time may be specified
similarly to the start time: The string to indicate the certifi‐
cate has no specified end time. A date or time in the system
time zone formatted as YYYYMMDD or YYYYMMDDHHMM[SS]. A date or
time in the UTC time zone as YYYYMMDDZ or YYYYMMDDHHMM[SS]Z. 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 A raw seconds since epoch (Jan 1 1970 00:00:00
UTC) as a hexadecimal number beginning with For example: Valid
from now to 52 weeks and one day from now. Valid from four weeks
ago to four weeks from now. Valid from 12:30 PM, January 1st,
2010 to 12:30 PM, January 1st, 2011. Similar, but interpreted in
the UTC time zone rather than the system time zone. Valid from
yesterday to midnight, January 1st, 2011. Valid from roughly
early 1970 to May 2033. Valid from one minute ago and never ex‐
piring. Verbose mode. Causes to print debugging messages about
its progress. This is helpful for debugging moduli generation.
Multiple options increase the verbosity. The maximum is 3.
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. Not supported in Solaris. Find
the principal(s) associated with the public key of a signature,
provided using the flag in an authorized signers file provided
using the flag. The format of the allowed signers file is docu‐
mented in the section below. If one or more matching principals
are found, they are returned on standard output. Find principal
matching the principal name provided using the flag in the autho‐
rized signers file specified using the flag. If one or more
matching principals are found, they are returned on standard out‐
put. Checks that a signature generated using has a valid struc‐
ture. This does not validate if a signature comes from an autho‐
rized signer. When testing a signature, accepts a message on
standard input and a signature namespace using A file containing
the corresponding signature must also be supplied using the flag.
Successful testing of the signature is signalled by returning a
zero exit status. Cryptographically sign a file or some data us‐
ing an SSH key. When signing, accepts zero or more files to sign
on the command-line - if no files are specified then will sign
data presented on standard input. Signatures are written to the
path of the input file with 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 option and may refer to
either a private key, or a public key with the private half
available via 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 flag. Name‐
spaces are arbitrary strings, and may include: for file signing,
for email signing. For custom uses, it is recommended to use
names following a NAMESPACE@YOUR.DOMAIN pattern to generate unam‐
biguous namespaces. Request to verify a signature generated us‐
ing as described above. When verifying a signature, accepts a
message on standard input and a signature namespace using A file
containing the corresponding signature must also be supplied us‐
ing the flag, along with the identity of the signer using and a
list of allowed signers via the flag. The format of the allowed
signers file is documented in the section below. A file contain‐
ing revoked keys can be passed using the flag. The revocation
file may be a KRL or a one-per-line list of public keys. Suc‐
cessful verification by an authorized signer is signalled by re‐
turning a zero exit status. This option will read a private
OpenSSH format file and print an OpenSSH public key to stdout.
Specifies the cipher to use for encryption when writing an
OpenSSH-format private key file. The list of available ciphers
may be obtained using The default is Specifies a serial number to
be embedded in the certificate to distinguish this certificate
from others from the same CA. If the is prefixed with a charac‐
ter, then the serial number will be incremented for each certifi‐
cate signed on a single command-line. The default serial number
is zero. When generating a KRL, the flag is used to specify a
KRL version number. 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 can‐
didate primes are then tested for suitability (a CPU-intensive
process). Generation of primes is performed using the option.
The desired length of the primes may be specified by the option.
For example: By default, the search for primes begins at a random
point in the desired length range. This may be overridden using
the 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 op‐
tion. In this mode will read candidates from standard input (or
a file specified using the option). For example: By default,
each candidate will be subjected to 100 primality tests. This
may be overridden using the 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 op‐
tion. Valid generator values are 2, 3, and 5. Screened DH
groups may be installed in It is important that this file con‐
tains moduli of a range of bit lengths. A number of options are
available for moduli generation and screening via the flag: Exit
after screening the specified number of lines while performing DH
candidate screening. Start screening at the specified line num‐
ber while performing DH candidate screening. 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. Spec‐
ify start point (in hex) when generating candidate moduli for DH-
GEX. Specify desired generator (in decimal) when testing candi‐
date moduli for DH-GEX. supports signing of keys to produce cer‐
tificates that may be used for user or host authentication. Cer‐
tificates 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 signa‐
ture 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 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: The resultant
certificate will be placed in A host certificate requires the op‐
tion: The host certificate will be output to It is possible to
sign using a CA key stored in a PKCS#11 token by providing the
token library using and identifying the CA key by providing its
public half as an argument to Similarly, it is possible for the
CA key to be hosted in an This is indicated by the flag and,
again, the CA key must be identified by its public half. In all
cases, 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: Ad‐
ditional limitations on the validity and use of user certificates
may be specified through certificate options. A certificate op‐
tion 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 all enabled permissions. This is useful
for clearing the default set of permissions so permissions may be
added individually. Includes an arbitrary certificate critical
option or extension. The specified should include a domain suf‐
fix, e.g. If is specified then it is included as the contents of
the extension/option encoded as a string, otherwise the exten‐
sion/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. Forces the execution of instead
of any shell or command specified by the user when the certifi‐
cate is used for authentication. Disable forwarding (permitted
by default). Disable port forwarding (permitted by default).
Disable PTY allocation (permitted by default). Disable execution
of by (permitted by default). Disable X11 forwarding (permitted
by default). Allows forwarding. Allows port forwarding. Allows
PTY allocation. Allows execution of by Allows X11 forwarding.
Do not require signatures made using this key include demonstra‐
tion of user presence (e.g. by having the user touch the authen‐
ticator). This option only makes sense for the FIDO authentica‐
tor algorithms and which are currently not supported on Solaris.
Restrict the source addresses from which the certificate is con‐
sidered valid. The is a comma-separated list of one or more ad‐
dress/netmask pairs in CIDR format. Require signatures made us‐
ing this key indicate that the user was first verified, e.g. by
PIN or on-token biometrics. This option only makes sense for the
FIDO authenticator algorithms and At present, no standard options
are valid for host keys. Finally, certificates may be defined
with a validity lifetime. The 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 Epoch to the distant fu‐
ture. For certificates to be used for user or host authentica‐
tion, the CA public key must be trusted by or Refer to those man‐
ual pages for details. 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 gener‐
ally 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-de‐
vice 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. Sup‐
ported key types are and The options that are valid for FIDO keys
are: Override the default FIDO application/origin string of This
may be useful when generating host or domain-specific resident
keys. The specified application string must begin with Specifies
a path to a challenge string that will be passed to the FIDO au‐
thenticator 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). Explicitly specify a de‐
vice to use, rather than letting the authenticator middleware se‐
lect one. Indicate that the generated private key should not re‐
quire touch events (user presence) when making signatures. Note
that will refuse such signatures by default, unless overridden
via an authorized_keys option. 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 re‐
quire that a PIN be set on the authenticator prior to generation.
Resident keys may be loaded off the authenticator using Storing
both parts of a key on a FIDO authenticator increases the likeli‐
hood of an attacker being able to use a stolen authenticator de‐
vice. A username to be associated with a resident key, overrid‐
ing the empty default username. Specifying a username may be
useful when generating multiple resident keys for the same appli‐
cation name. 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. 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 de‐
fault, this information is discarded. 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 flag. This op‐
tion 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 cer‐
tificates 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. 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 ser‐
ial 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 command line using the op‐
tion. Revokes a certificate with the specified key ID string.
The CA key must have been specified on the command line using the
option. Revokes the specified key. If a certificate is listed,
then it is revoked as a plain public key. Revokes the specified
key by including its SHA1 hash in the KRL. 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. Revokes a key using a fingerprint hash, as obtained from
an authentication log message or the flag. Only SHA256 finger‐
prints are supported here and resultant KRLs are not supported by
OpenSSH versions prior to 7.9. KRLs may be updated using the
flag in addition to When this option is specified, keys listed
via the command line are merged into the KRL, adding to those al‐
ready there. It is also possible, given a KRL, to test whether
it revokes a particular key (or keys). The 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 will exit with a non-zero exit status. A zero
exit status will only be returned if no key was revoked. When
verifying signatures, 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 AU‐
THORIZED_KEYS FILE FORMAT described in Each line of the file con‐
tains the following space-separated fields: principals, options,
keytype, base64-encoded key. Empty lines and lines starting with
a are ignored as comments. The principals field is a pattern-
list (see PATTERNS in consisting of one or more comma-separated
USER@DOMAIN identity patterns that are accepted for signing.
When verifying, the identity presented via the 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): Indicates that this key is accepted as a certifi‐
cate authority (CA) and that certificates signed by this CA may
be accepted for verification. Specifies a pattern-list of name‐
spaces 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. In‐
dicates 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 charac‐
ter, which causes them to be interpreted in the UTC time zone.
Indicates that the key is valid for use at or before the speci‐
fied timestamp. When verifying signatures made by certificates,
the expected principal name must match both the principals pat‐
tern in the allowed signers file and the principals embedded in
the certificate itself. An example allowed signers file: # Com‐
ments allowed at start of line user1@example.com,user2@exam‐
ple.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... Speci‐
fies 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. Not supported in Solaris. Contains
the 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 possi‐
ble 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
but it is offered as the default file for the private key. will
read this file when a login attempt is made. Contains the ECDSA,
authenticator-hosted ECDSA, Ed25519, authenticator-hosted Ed25519
or RSA public key for authentication. The contents of this file
should be added to 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. Contains Diffie-Hellman groups
used for DH-GEX. The file format is described in
See for descriptions of the following attributes:
box; cbp-1 | cbp-1 l | l . ATTRIBUTE TYPE ATTRIBUTE VALUE =
Availability network/ssh = Stability Pass-through uncom‐
mitted 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.
Source code for open source software components in Oracle Solaris
can be found at https://www.oracle.com/downloads/opensource/so‐
laris-source-code-downloads.html.
This software was built from source available at:
https://github.com/oracle/solaris-userland
The original community source was downloaded from:
https://mir‐
rors.sonic.net/pub/OpenBSD/OpenSSH/portable/openssh-10.2p1.tar.gz
Further information about this software can be found on the open
source community website at https://www.openssh.com/.