svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
sshd(8)
(OpenSSH Daemon) is the daemon program for It provides secure en‐
crypted communications between two untrusted hosts over an inse‐
cure network. listens for connections from clients. It is nor‐
mally started at boot from It forks a new daemon for each incom‐
ing connection. The forked daemons handle key exchange, encryp‐
tion, authentication, command execution, and data exchange. can
be configured using command-line options or a configuration file
(by default command-line options override values specified in the
configuration file. rereads its configuration file when it re‐
ceives a hangup signal, by executing itself with the name and op‐
tions it was started with, e.g. If sshd links with FIPS-capable
OpenSSL, sshd runs in FIPS-140 mode. In FIPS-140 mode non-FIPS
approved ciphers, MACs and digests are disabled. The options are
as follows: Forces to use IPv4 addresses only. Forces to use
IPv6 addresses only. Specify the connection parameters to use
for the extended test mode. If provided, any directives in the
configuration file that would apply are applied before the con‐
figuration is written to standard output. The connection parame‐
ters are supplied as keyword=value pairs and may be supplied in
any order, either with multiple options or as a comma-separated
list. The keywords are and and correspond to source address,
user, resolved source host name, local address, local port number
and routing domain respectively. Additionally the flag (which
does not take a value argument) may be specified to simulate a
connection from an unrecognised username. Specifies a path to a
certificate file to identify during key exchange. The certifi‐
cate file must match a host key file specified using the option
or the configuration directive. When this option is specified,
will not detach and does not become a daemon. This allows easy
monitoring of Debug mode. The server sends verbose debug output
to standard error, and does not put itself in the background.
The server also will not and will only process one connection.
This option is only intended for debugging for the server. Mul‐
tiple options increase the debugging level. Maximum is 3. Ap‐
pend debug logs to instead of the system log. Write debug logs
to standard error instead of the system log. Specifies the name
of the configuration file. The default is refuses to start if
there is no configuration file. Parse and print configuration
file. Check the validity of the configuration file, output the
effective configuration to stdout and then exit. Optionally,
rules may be applied by specifying the connection parameters us‐
ing one or more options. Gives the grace time for clients to au‐
thenticate themselves (default 120 seconds). If the client fails
to authenticate the user within this many seconds, the server
disconnects and exits. A value of zero indicates no limit.
Specifies a file from which a host key is read. This option must
be given if is not run as root (as the normal host key files are
normally not readable by anyone but root). The default is and It
is possible to have multiple host key files for the different
host key algorithms. Specifies that is being run from Can be
used to give options in the format used in the configuration
file. This is useful for specifying options for which there is
no separate command-line flag. For full details of the options,
and their values, see Specifies the port on which the server lis‐
tens for connections (default 22). Multiple port options are
permitted. Ports specified in the configuration file with the
option are ignored when a command-line port is specified. Ports
specified using the option override command-line ports. Quiet
mode. Nothing is sent to the system log. Normally the begin‐
ning, authentication, and termination of each connection is
logged. Extended test mode. Check the validity of the configu‐
ration file, output the effective configuration to stdout and
then exit. Optionally, rules may be applied by specifying the
connection parameters using one or more options. This is similar
to the flag, but it includes the additional testing performed by
the flag. Test mode. Only check the validity of the configura‐
tion file and sanity of the keys. This is useful for updating
reliably as configuration options may change. This option is
used to specify the size of the field in the structure that holds
the remote host name. If the resolved host name is longer than
the dotted decimal value will be used instead. This allows hosts
with very long host names that overflow this field to still be
uniquely identified. Specifying indicates that only dotted deci‐
mal addresses should be put into the file. may also be used to
prevent from making DNS requests unless the authentication mecha‐
nism or configuration requires it. Authentication mechanisms
that may require DNS include and using a option in a key file.
Configuration options that require DNS include using a USER@HOST
pattern in or Display the version number and exit. The OpenSSH
SSH daemon supports SSH protocol 2 only. Each host has a host-
specific key, used to identify the host. Whenever a client con‐
nects, the daemon responds with its public host key. The client
compares the host key against its own database to verify that it
has not changed. Forward secrecy is provided through a Diffie-
Hellman key agreement. This key agreement results in a shared
session key. The rest of the session is encrypted using a sym‐
metric cipher. The client selects the encryption algorithm to
use from those offered by the server. Additionally, session in‐
tegrity is provided through a cryptographic message authentica‐
tion code (MAC). Finally, the server and the client enter an au‐
thentication dialog. The client tries to authenticate itself us‐
ing host-based authentication, public key authentication, chal‐
lenge-response authentication, or password authentication. Re‐
gardless of the authentication type, the account is checked to
ensure that it is accessible. An account is not accessible if it
is locked, listed in or its group is listed in . The definition
of a locked account is system dependent. Some platforms have
their own account database (eg AIX) and some modify the passwd
field ( on Solaris and UnixWare, on HP-UX, containing on Tru64, a
leading on FreeBSD and a leading on most Linuxes). If there is a
requirement to disable password authentication for the account
while allowing still public-key, then the passwd field should be
set to something other than these values (eg or ). If the client
successfully authenticates itself, a dialog for preparing the
session is entered. At this time the client may request things
like allocating a pseudo-tty, forwarding X11 connections, for‐
warding TCP connections, or forwarding the authentication agent
connection over the secure channel. After this, the client ei‐
ther requests an interactive shell or execution of a non-interac‐
tive command, which will execute via the user's shell using its
option. The sides then enter session mode. In this mode, either
side may send data at any time, and such data is forwarded
to/from the shell or command on the server side, and the user
terminal in the client side. When the user program terminates
and all forwarded X11 and other connections have been closed, the
server sends command exit status to the client, and both sides
exit. When a user successfully logs in, does the following: If
the login is on a tty, and no command has been specified, prints
last login time and (unless prevented in the configuration file
or by see the section). If the login is on a tty, records login
time. Checks if it exists, prints contents and quits (unless
root). Changes to run with normal user privileges. Sets up ba‐
sic environment. Reads the file if it exists, and users are al‐
lowed to change their environment. See the option in Changes to
user's home directory. If exists and the option is set, runs it;
else if exists, runs it; otherwise runs The files are given the
X11 authentication protocol and cookie in standard input. See
below. Runs user's shell or command. All commands are run under
the user's login shell as specified in the system password data‐
base. If the file exists, runs it after reading the environment
files but before starting the user's shell or command. It must
not produce any output on stdout; stderr must be used instead.
If X11 forwarding is in use, it will receive the "proto cookie"
pair in its standard input (and in its environment). The script
must call because will not run xauth automatically to add X11
cookies. The primary purpose of this file is to run any initial‐
ization routines which may be needed before the user's home di‐
rectory becomes accessible; AFS is a particular example of such
an environment. This file will probably contain some initializa‐
tion code followed by something similar to: if read proto cookie
&& [ -n "$DISPLAY" ]; then if [ `echo $DISPLAY | cut
-c1-10` = 'localhost:' ]; then # X11UseLocal‐
host=yes echo add unix:`echo $DISPLAY |
cut -c11-` $proto $cookie else
# X11UseLocalhost=no echo add
$DISPLAY $proto $cookie fi | xauth -q - fi If this file
does not exist, is run, and if that does not exist either, xauth
is used to add the cookie. specifies the files containing public
keys for public key authentication; if this option is not speci‐
fied, the default is and Each line of the file contains one key
(empty lines and lines starting with a are ignored as comments).
Public keys consist of the following space-separated fields: op‐
tions, keytype, base64-encoded key, comment. The options field
is optional. The supported key types are: sk-ecdsa-
sha2-nistp256@openssh.com ecdsa-sha2-nistp256 ecdsa-sha2-nistp384
ecdsa-sha2-nistp521 sk-ssh-ed25519@openssh.com ssh-ed25519 ssh-
rsa The comment field is not used for anything (but may be conve‐
nient for the user to identify the key). Note that lines in this
file can be several hundred bytes long (because of the size of
the public key encoding) up to a limit of 8 kilobytes, which per‐
mits RSA keys up to 16 kilobits. You don't want to type them in;
instead, copy the or the file and edit it. enforces a minimum
RSA key modulus size of 1024 bits. The options (if present) con‐
sist 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): Enable authentication agent forwarding previously
disabled by the option. Specifies that the listed key is a cer‐
tification authority (CA) that is trusted to validate signed cer‐
tificates for user authentication. Certificates may encode ac‐
cess restrictions similar to these key options. If both certifi‐
cate restrictions and key options are present, the most restric‐
tive union of the two is applied. Specifies that the command is
executed whenever this key is used for authentication. The com‐
mand supplied by the user (if any) is ignored. The command is
run on a pty if the client requests a pty; otherwise it is run
without a tty. If an 8-bit clean channel is required, one must
not request a pty or should specify A quote may be included in
the command by quoting it with a backslash. This option might be
useful to restrict certain public keys to perform just a specific
operation. An example might be a key that permits remote backups
but nothing else. Note that the client may specify TCP and/or
X11 forwarding unless they are explicitly prohibited, e.g. using
the key option. The command originally supplied by the client is
available in the environment variable. Note that this option ap‐
plies to shell, command or subsystem execution. Also note that
this command may be superseded by an directive. If a command is
specified and a forced-command is embedded in a certificate used
for authentication, then the certificate will be accepted only if
the two commands are identical. Specifies that the string is to
be added to the environment when logging in using this key. En‐
vironment variables set this way override other default environ‐
ment values. Multiple options of this type are permitted. Envi‐
ronment processing is disabled by default and is controlled via
the option. Specifies a time after which the key will not be ac‐
cepted. The time may be specified as a YYYYMMDD[Z] date or a
YYYYMMDDHHMM[SS][Z] time. Dates and times will be interpreted in
the system time zone unless suffixed by a Z character, in which
case they will be interpreted in the UTC time zone. Specifies
that in addition to public key authentication, either the canoni‐
cal name of the remote host or its IP address must be present in
the comma-separated list of patterns. See PATTERNS in for more
information on patterns. In addition to the wildcard matching
that may be applied to hostnames or addresses, a stanza may match
IP addresses using CIDR address/masklen notation. The purpose of
this option is to optionally increase security: public key au‐
thentication by itself does not trust the network or name servers
or anything (but the key); however, if somebody somehow steals
the key, the key permits an intruder to log in from anywhere in
the world. This additional option makes using a stolen key more
difficult (name servers and/or routers would have to be compro‐
mised in addition to just the key). Forbids authentication agent
forwarding when this key is used for authentication. Forbids TCP
forwarding when this key is used for authentication. Any port
forward requests by the client will return an error. This might
be used, e.g. in connection with the option. Prevents tty allo‐
cation (a request to allocate a pty will fail). Disables execu‐
tion of Forbids X11 forwarding when this key is used for authen‐
tication. Any X11 forward requests by the client will return an
error. Limit remote port forwarding with the option such that it
may only listen on the specified host (optional) and port. IPv6
addresses can be specified by enclosing the address in square
brackets. Multiple options may be applied separated by commas.
Hostnames may include wildcards as described in the PATTERNS sec‐
tion in A port specification of matches any port. Note that the
setting of may further restrict listen addresses. Note that will
send a hostname of if a listen host was not specified when the
forwarding was requested, and that this name is treated differ‐
ently to the explicit localhost addresses and Limit local port
forwarding with the option such that it may only connect to the
specified host and port. IPv6 addresses can be specified by en‐
closing the address in square brackets. Multiple options may be
applied separated by commas. No pattern matching or name lookup
is performed on the specified hostnames, they must be literal
host names and/or addresses. A port specification of matches any
port. Enable port forwarding previously disabled by the option.
On a line, specifies allowed principals for certificate authenti‐
cation as a comma-separated list. At least one name from the
list must appear in the certificate's list of principals for the
certificate to be accepted. This option is ignored for keys that
are not marked as trusted certificate signers using the option.
Permits tty allocation previously disabled by the option. Do not
require demonstration of user presence for signatures made using
this key. This option only makes sense for the FIDO authentica‐
tor algorithms and Require that signatures made using this key
attest that they verified the user, e.g. via a PIN. This option
only makes sense for the FIDO authenticator algorithms and Enable
all restrictions, i.e. disable port, agent and X11 forwarding, as
well as disabling PTY allocation and execution of If any future
restriction capabilities are added to authorized_keys files, they
will be included in this set. Force a device on the server.
Without this option, the next available device will be used if
the client requests a tunnel. Enables execution of previously
disabled by the option. Permits X11 forwarding previously dis‐
abled by the option. An example authorized_keys file: # Comments
are allowed at start of line. Blank lines are allowed. # Plain
key, no restrictions ssh-rsa ... # Forced command, disable PTY
and all forwarding restrict,command="dump /home" ssh-rsa ... #
Restriction of ssh -L forwarding destinations permi‐
topen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa ... # Re‐
striction of ssh -R forwarding listeners permitlisten="local‐
host:8080",permitlisten="[::1]:22000" ssh-rsa ... # Configura‐
tion for tunnel forwarding tunnel="0",command="sh /etc/netstart
tun0" ssh-rsa ... # Override of restriction to allow PTY alloca‐
tion restrict,pty,command="nethack" ssh-rsa ... # Allow FIDO key
without requiring touch no-touch-required sk-ecdsa-
sha2-nistp256@openssh.com ... # Require user-verification (e.g.
PIN or biometric) for FIDO key verify-required sk-ecdsa-
sha2-nistp256@openssh.com ... # Trust CA key, allow touch-less
FIDO if requested in certificate cert-authority,no-touch-re‐
quired,principals="user_a" ssh-rsa ... The and files contain
host public keys for all known hosts. The global file should be
prepared by the administrator (optional), and the per-user file
is maintained automatically: whenever the user connects to an un‐
known host, its key is added to the per-user file. Each line in
these files contains the following fields: marker (optional),
hostnames, keytype, base64-encoded key, comment. The fields are
separated by spaces. The marker is optional, but if it is
present then it must be one of to indicate that the line contains
a certification authority (CA) key, or to indicate that the key
contained on the line is revoked and must not ever be accepted.
Only one marker should be used on a key line. Hostnames is a
comma-separated list of patterns and act as wildcards); each pat‐
tern in turn is matched against the host name. When is authenti‐
cating a client, such as when using this will be the canonical
client host name. When is authenticating a server, this will be
the host name given by the user, the value of the if it was spec‐
ified, or the canonical server hostname if the option was used.
A pattern may also be preceded by to indicate negation: if the
host name matches a negated pattern, it is not accepted (by that
line) even if it matched another pattern on the line. A hostname
or address may optionally be enclosed within and brackets then
followed by and a non-standard port number. Alternately, host‐
names may be stored in a hashed form which hides host names and
addresses should the file's contents be disclosed. Hashed host‐
names start with a character. Only one hashed hostname may ap‐
pear on a single line and none of the above negation or wildcard
operators may be applied. The keytype and base64-encoded key are
taken directly from the host key; they can be obtained, for exam‐
ple, from The optional comment field continues to the end of the
line, and is not used. Lines starting with and empty lines are
ignored as comments. When performing host authentication, au‐
thentication is accepted if any matching line has the proper key;
either one that matches exactly or, if the server has presented a
certificate for authentication, the key of the certification au‐
thority that signed the certificate. For a key to be trusted as
a certification authority, it must use the marker described
above. The known hosts file also provides a facility to mark
keys as revoked, for example when it is known that the associated
private key has been stolen. Revoked keys are specified by in‐
cluding the marker at the beginning of the key line, and are
never accepted for authentication or as certification authori‐
ties, but instead will produce a warning from when they are en‐
countered. It is permissible (but not recommended) to have sev‐
eral lines or different host keys for the same names. This will
inevitably happen when short forms of host names from different
domains are put in the file. It is possible that the files con‐
tain conflicting information; authentication is accepted if valid
information can be found from either file. Note that the lines
in these files are typically hundreds of characters long, and you
definitely don't want to type in the host keys by hand. Rather,
generate them by a script, or by taking, for example, and adding
the host names at the front. also offers some basic automated
editing for including removing hosts matching a host name and
converting all host names to their hashed representations. An
example ssh_known_hosts file: # Comments allowed at start of line
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....= # A hashed
hostname |1|JfKTdBh7rNbXk‐
VAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234.....= # A revoked key @revoked * ssh-rsa AAAAB5W... # A
CA key, accepted for any host in *.mydomain.com or *.mydomain.org
@cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...
This file is used to suppress printing the last login time and if
and respectively, are enabled. It does not suppress printing of
the banner specified by This file is used for host-based authen‐
tication (see for more information). On some machines this file
may need to be world-readable if the user's home directory is on
an NFS partition, because reads it as root. Additionally, this
file must be owned by the user, and must not have write permis‐
sions for anyone else. The recommended permission for most ma‐
chines is read/write for the user, and not accessible by others.
This file is used in exactly the same way as but allows host-
based authentication without permitting login with rlogin/rsh.
This directory is the default location for all user-specific con‐
figuration and authentication information. There is no general
requirement to keep the entire contents of this directory secret,
but the recommended permissions are read/write/execute for the
user, and not accessible by others. Lists the public keys
(ECDSA, Ed25519, RSA) that can be used for logging in as this
user. The format of this file is described above. The content
of the file is not highly sensitive, but the recommended permis‐
sions are read/write for the user, and not accessible by others.
If this file, the directory, or the user's home directory are
writable by other users, then the file could be modified or re‐
placed by unauthorized users. In this case, will not allow it to
be used unless the option has been set to This file is read into
the environment at login (if it exists). It can only contain
empty lines, comment lines (that start with and assignment lines
of the form name=value. The file should be writable only by the
user; it need not be readable by anyone else. Environment pro‐
cessing is disabled by default and is controlled via the option.
Contains a list of host keys for all hosts the user has logged
into that are not already in the systemwide list of known host
keys. The format of this file is described above. This file
should be writable only by root/the owner and can, but need not
be, world-readable. Contains initialization routines to be run
before the user's home directory becomes accessible. This file
should be writable only by the user, and need not be readable by
anyone else. This file is for host-based authentication (see It
should only be writable by root. Contains Diffie-Hellman groups
used for the "Diffie-Hellman Group Exchange" key exchange method.
The file format is described in If no usable groups are found in
this file then fixed internal groups will be used. See If this
file exists, refuses to let anyone except root log in. The con‐
tents of the file are displayed to anyone trying to log in, and
non-root connections are refused. The file should be world-read‐
able. This file is used in exactly the same way as but allows
host-based authentication without permitting login with
rlogin/rsh. These files contain the private parts of the host
keys. These files should only be owned by root, readable only by
root, and not accessible to others. Note that does not start if
these files are group/world-accessible. These files contain the
public parts of the host keys. These files should be world-read‐
able but writable only by root. Their contents should match the
respective private parts. These files are not really used for
anything; they are provided for the convenience of the user so
their contents can be copied to known hosts files. These files
are created using Systemwide list of known host keys. This file
should be prepared by the system administrator to contain the
public host keys of all machines in the organization. The format
of this file is described above. This file should be writable
only by root/the owner and should be world-readable. Contains
configuration data for The file format and configuration options
are described in Similar to it can be used to specify machine-
specific login-time initializations globally. This file should
be writable only by root, and should be world-readable. direc‐
tory used by during privilege separation in the pre-authentica‐
tion phase. The directory should not contain any files and must
be owned by root and not group or world-writable. Contains the
process ID of the listening for connections (if there are several
daemons running concurrently for different ports, this contains
the process ID of the one started last). The content of this
file is not sensitive; it can be world-readable. sshd uses
pam(3PAM) for password and keyboard-interactive methods as well
as for account management, session management, and the password
management for all authentication methods. Each SSHv2 userauth
type has its own PAM service name:
----------------------------------------------- | SSHv2 Userauth
| PAM Service Name |
----------------------------------------------- | none
| sshd-none |
----------------------------------------------- | password
| sshd-password |
----------------------------------------------- | keyboard-inter‐
active | sshd-kbdint |
----------------------------------------------- | pubkey
| sshd-pubkey |
----------------------------------------------- | hostbased
| sshd-hostbased |
----------------------------------------------- | gssapi-with-mic
| sshd-gssapi |
----------------------------------------------- | gssapi-keyex
| sshd-gssapi |
-----------------------------------------------
See for descriptions of the following attributes:
box; cbp-1 | cbp-1 l | l . ATTRIBUTE TYPE ATTRIBUTE VALUE =
Availability service/network/ssh = Stability Pass-
through uncommitted 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 re‐
moved many bugs, re-added newer features and created OpenSSH.
Markus Friedl contributed the support for SSH protocol versions
1.5 and 2.0. Niels Provos and Markus Friedl contributed support
for privilege separation.
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/.