Путеводитель по Руководству Linux

  User  |  Syst  |  Libr  |  Device  |  Files  |  Other  |  Admin  |  Head  |



   sshd    ( 8 )

демон OpenSSH (OpenSSH daemon)

Имя (Name)

sshd — OpenSSH daemon

Синопсис (Synopsis)

sshd [-46DdeiqTt] [-C connection_spec] [-c host_certificate_file]
          [-E log_file] [-f config_file] [-g login_grace_time]
          [-h host_key_file] [-o option] [-p port] [-u len]

Описание (Description)

sshd (OpenSSH Daemon) is the daemon program for ssh(1).  It
     provides secure encrypted communications between two untrusted
     hosts over an insecure network.

sshd listens for connections from clients. It is normally started at boot from /etc/rc. It forks a new daemon for each incoming connection. The forked daemons handle key exchange, encryption, authentication, command execution, and data exchange.

sshd can be configured using command-line options or a configuration file (by default sshd_config(5)); command-line options override values specified in the configuration file. sshd rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name and options it was started with, e.g. /usr/sbin/sshd.

The options are as follows:

-4 Forces sshd to use IPv4 addresses only.

-6 Forces sshd to use IPv6 addresses only.

-C connection_spec Specify the connection parameters to use for the -T extended test mode. If provided, any Match directives in the configuration file that would apply are applied before the configuration is written to standard output. The connection parameters are supplied as keyword=value pairs and may be supplied in any order, either with multiple -C options or as a comma-separated list. The keywords are 'addr', 'user', 'host', 'laddr', 'lport', and 'rdomain' and correspond to source address, user, resolved source host name, local address, local port number and routing domain respectively.

-c host_certificate_file Specifies a path to a certificate file to identify sshd during key exchange. The certificate file must match a host key file specified using the -h option or the HostKey configuration directive.

-D When this option is specified, sshd will not detach and does not become a daemon. This allows easy monitoring of sshd.

-d Debug mode. The server sends verbose debug output to standard error, and does not put itself in the background. The server also will not fork(2) and will only process one connection. This option is only intended for debugging for the server. Multiple -d options increase the debugging level. Maximum is 3.

-E log_file Append debug logs to log_file instead of the system log.

-e Write debug logs to standard error instead of the system log.

-f config_file Specifies the name of the configuration file. The default is /etc/ssh/sshd_config. sshd refuses to start if there is no configuration file.

-g login_grace_time Gives the grace time for clients to authenticate 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.

-h host_key_file Specifies a file from which a host key is read. This option must be given if sshd is not run as root (as the normal host key files are normally not readable by anyone but root). The default is /etc/ssh/ssh_host_ecdsa_key, /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key. It is possible to have multiple host key files for the different host key algorithms.

-i Specifies that sshd is being run from inetd(8).

-o option 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 sshd_config(5).

-p port Specifies the port on which the server listens for connections (default 22). Multiple port options are permitted. Ports specified in the configuration file with the Port option are ignored when a command-line port is specified. Ports specified using the ListenAddress option override command-line ports.

-q Quiet mode. Nothing is sent to the system log. Normally the beginning, authentication, and termination of each connection is logged.

-T Extended test mode. Check the validity of the configuration file, output the effective configuration to stdout and then exit. Optionally, Match rules may be applied by specifying the connection parameters using one or more -C options.

-t Test mode. Only check the validity of the configuration file and sanity of the keys. This is useful for updating sshd reliably as configuration options may change.

-u len This option is used to specify the size of the field in the utmp structure that holds the remote host name. If the resolved host name is longer than len, 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 -u0 indicates that only dotted decimal addresses should be put into the utmp file. -u0 may also be used to prevent sshd from making DNS requests unless the authentication mechanism or configuration requires it. Authentication mechanisms that may require DNS include HostbasedAuthentication and using a from="pattern-list" option in a key file. Configuration options that require DNS include using a USER@HOST pattern in AllowUsers or DenyUsers.


Аутентификация (Authentication)

The OpenSSH SSH daemon supports SSH protocol 2 only.  Each host has
     a host-specific key, used to identify the host.  Whenever a client
     connects, 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
     symmetric cipher.  The client selects the encryption algorithm to
     use from those offered by the server.  Additionally, session
     integrity is provided through a cryptographic message
     authentication code (MAC).

Finally, the server and the client enter an authentication dialog. The client tries to authenticate itself using host-based authentication, public key authentication, challenge-response authentication, or password authentication.

Regardless 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 DenyUsers or its group is listed in DenyGroups . The definition of a locked account is system dependent. Some platforms have their own account database (eg AIX) and some modify the passwd field ( '*LK*' on Solaris and UnixWare, '*' on HP-UX, containing 'Nologin' on Tru64, a leading '*LOCKED*' 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 'NP' or '*NP*' ).

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, forwarding TCP connections, or forwarding the authentication agent connection over the secure channel.

After this, the client either requests a shell or execution of a command. 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.


LOGIN PROCESS

When a user successfully logs in, sshd does the following:

1. If the login is on a tty, and no command has been specified, prints last login time and /etc/motd (unless prevented in the configuration file or by ~/.hushlogin; see the FILES section).

2. If the login is on a tty, records login time.

3. Checks /etc/nologin; if it exists, prints contents and quits (unless root).

4. Changes to run with normal user privileges.

5. Sets up basic environment.

6. Reads the file ~/.ssh/environment, if it exists, and users are allowed to change their environment. See the PermitUserEnvironment option in sshd_config(5).

7. Changes to user's home directory.

8. If ~/.ssh/rc exists and the sshd_config(5) PermitUserRC option is set, runs it; else if /etc/ssh/sshrc exists, runs it; otherwise runs xauth(1). The 'rc' files are given the X11 authentication protocol and cookie in standard input. See SSHRC, below.

9. Runs user's shell or command. All commands are run under the user's login shell as specified in the system password database.


SSHRC

If the file ~/.ssh/rc exists, sh(1) 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 DISPLAY in its
     environment).  The script must call xauth(1) because sshd will not
     run xauth automatically to add X11 cookies.

The primary purpose of this file is to run any initialization routines which may be needed before the user's home directory becomes accessible; AFS is a particular example of such an environment.

This file will probably contain some initialization code followed by something similar to:

if read proto cookie && [ -n "$DISPLAY" ]; then if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then # X11UseLocalhost=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, /etc/ssh/sshrc is run, and if that does not exist either, xauth is used to add the cookie.