diff options
author | Dag-Erling Smørgrav <des@FreeBSD.org> | 2008-07-23 09:15:38 +0000 |
---|---|---|
committer | Dag-Erling Smørgrav <des@FreeBSD.org> | 2008-07-23 09:15:38 +0000 |
commit | 24cf82b14a50efe0bb150e7651f451a3cc36103b (patch) | |
tree | 31274ced9514914f9504202c6e49c93d509e710d /sshd.0 | |
parent | 024ab8dd1d8c50215dd4a503416b095663d4346c (diff) | |
download | src-24cf82b14a50efe0bb150e7651f451a3cc36103b.tar.gz src-24cf82b14a50efe0bb150e7651f451a3cc36103b.zip |
Vendor import of OpenSSH 4.6p1 for posterity's sake
Notes
Notes:
svn path=/vendor-crypto/openssh/dist/; revision=180740
Diffstat (limited to 'sshd.0')
-rw-r--r-- | sshd.0 | 544 |
1 files changed, 544 insertions, 0 deletions
diff --git a/sshd.0 b/sshd.0 new file mode 100644 index 000000000000..5e21db125d76 --- /dev/null +++ b/sshd.0 @@ -0,0 +1,544 @@ +SSHD(8) OpenBSD System Manager's Manual SSHD(8) + +NAME + sshd - OpenSSH SSH daemon + +SYNOPSIS + sshd [-46Ddeiqt] [-b bits] [-f config_file] [-g login_grace_time] + [-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u len] + +DESCRIPTION + sshd (OpenSSH Daemon) is the daemon program for ssh(1). Together these + programs replace rlogin and rsh, and provide secure encrypted communica- + tions 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, com- + mand 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 speci- + fied 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. + + -b bits + Specifies the number of bits in the ephemeral protocol version 1 + server key (default 768). + + -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 the system + log, and does not put itself in the background. The server also + will not fork and will only process one connection. This option + is only intended for debugging for the server. Multiple -d op- + tions increase the debugging level. Maximum is 3. + + -e When this option is specified, sshd will send the output to the + standard error instead of the system log. + + -f configuration_file + Specifies the name of the configuration file. The default is + /etc/ssh/sshd_config. sshd refuses to start if there is no con- + figuration file. + + -g login_grace_time + Gives the grace time for clients to authenticate themselves (de- + fault 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_key for protocol version 1, and + /etc/ssh/ssh_host_rsa_key and /etc/ssh/ssh_host_dsa_key for pro- + tocol version 2. It is possible to have multiple host key files + for the different protocol versions and host key algorithms. + + -i Specifies that sshd is being run from inetd(8). sshd is normally + not run from inetd because it needs to generate the server key + before it can respond to the client, and this may take tens of + seconds. Clients would have to wait too long if the key was re- + generated every time. However, with small key sizes (e.g. 512) + using sshd from inetd may be feasible. + + -k key_gen_time + Specifies how often the ephemeral protocol version 1 server key + is regenerated (default 3600 seconds, or one hour). The motiva- + tion for regenerating the key fairly often is that the key is not + stored anywhere, and after about an hour it becomes impossible to + recover the key for decrypting intercepted communications even if + the machine is cracked into or physically seized. A value of ze- + ro indicates that the key will never be regenerated. + + -o option + Can be used to give options in the format used in the configura- + tion file. This is useful for specifying options for which there + is no separate command-line flag. For full details of the op- + tions, 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 speci- + fied 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 be- + ginning, authentication, and termination of each connection is + logged. + + -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 over- + flow 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 in- + clude RhostsRSAAuthentication, HostbasedAuthentication, and using + a from="pattern-list" option in a key file. Configuration op- + tions that require DNS include using a USER@HOST pattern in + AllowUsers or DenyUsers. + +AUTHENTICATION + The OpenSSH SSH daemon supports SSH protocols 1 and 2. Both protocols + are supported by default, though this can be changed via the Protocol op- + tion in sshd_config(5). Protocol 2 supports both RSA and DSA keys; pro- + tocol 1 only supports RSA keys. For both protocols, each host has a + host-specific key, normally 2048 bits, used to identify the host. + + Forward security for protocol 1 is provided through an additional server + key, normally 768 bits, generated when the server starts. This key is + normally regenerated every hour if it has been used, and is never stored + on disk. Whenever a client connects, the daemon responds with its public + host and server keys. The client compares the RSA host key against its + own database to verify that it has not changed. The client then gener- + ates a 256-bit random number. It encrypts this random number using both + the host key and the server key, and sends the encrypted number to the + server. Both sides then use this random number as a session key which is + used to encrypt all further communications in the session. The rest of + the session is encrypted using a conventional cipher, currently Blowfish + or 3DES, with 3DES being used by default. The client selects the encryp- + tion algorithm to use from those offered by the server. + + For protocol 2, forward security 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, currently 128-bit + AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES. The + client selects the encryption algorithm to use from those offered by the + server. Additionally, session integrity is provided through a crypto- + graphic message authentication code (hmac-sha1 or hmac-md5). + + Finally, the server and the client enter an authentication dialog. The + client tries to authenticate itself using host-based authentication, pub- + lic 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 defini- + tion of a locked account is system dependant. 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 Linux). 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 some- + thing 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 con- + nections, or forwarding the authentication agent connection over the se- + cure 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 connec- + tions 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, runs it; else if /etc/ssh/sshrc exists, + runs it; otherwise runs xauth. The ``rc'' files are given the + X11 authentication protocol and cookie in standard input. See + SSHRC, below. + + 9. Runs user's shell or command. + +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 pro- + duce any output on stdout; stderr must be used instead. If X11 forward- + ing 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. + +AUTHORIZED_KEYS FILE FORMAT + AuthorizedKeysFile specifies the file containing public keys for public + key authentication; if none is specified, the default is + ~/.ssh/authorized_keys. Each line of the file contains one key (empty + lines and lines starting with a `#' are ignored as comments). Protocol 1 + public keys consist of the following space-separated fields: options, + bits, exponent, modulus, comment. Protocol 2 public key consist of: op- + tions, keytype, base64-encoded key, comment. The options field is op- + tional; its presence is determined by whether the line starts with a num- + ber or not (the options field never starts with a number). The bits, ex- + ponent, modulus, and comment fields give the RSA key for protocol version + 1; the comment field is not used for anything (but may be convenient for + the user to identify the key). For protocol version 2 the keytype is + ``ssh-dss'' or ``ssh-rsa''. + + Note that lines in this file are usually several hundred bytes long (be- + cause of the size of the public key encoding) up to a limit of 8 kilo- + bytes, which permits DSA keys up to 8 kilobits and RSA keys up to 16 + kilobits. You don't want to type them in; instead, copy the + identity.pub, id_dsa.pub, or the id_rsa.pub file and edit it. + + sshd enforces a minimum RSA key modulus size for protocol 1 and protocol + 2 keys of 768 bits. + + The options (if present) consist of comma-separated option specifica- + tions. No spaces are permitted, except within double quotes. The fol- + lowing option specifications are supported (note that option keywords are + case-insensitive): + + command="command" + Specifies that the command is executed whenever this key is used + for authentication. The command 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 chan- + nel is required, one must not request a pty or should specify no- + pty. A quote may be included in the command by quoting it with a + backslash. This option might be useful to restrict certain pub- + lic 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. The command originally supplied by the + client is available in the SSH_ORIGINAL_COMMAND environment vari- + able. Note that this option applies to shell, command or subsys- + tem execution. + + environment="NAME=value" + Specifies that the string is to be added to the environment when + logging in using this key. Environment variables set this way + override other default environment values. Multiple options of + this type are permitted. Environment processing is disabled by + default and is controlled via the PermitUserEnvironment option. + This option is automatically disabled if UseLogin is enabled. + + from="pattern-list" + Specifies that in addition to public key authentication, the + canonical name of the remote host must be present in the comma- + separated list of patterns. The purpose of this option is to op- + tionally increase security: public key authentication by itself + does not trust the network or name servers or anything (but the + key); however, if somebody somehow steals the key, the key per- + mits an intruder to log in from anywhere in the world. This ad- + ditional option makes using a stolen key more difficult (name + servers and/or routers would have to be compromised in addition + to just the key). + + See PATTERNS in ssh_config(5) for more information on patterns. + + no-agent-forwarding + Forbids authentication agent forwarding when this key is used for + authentication. + + no-port-forwarding + 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 command option. + + no-pty Prevents tty allocation (a request to allocate a pty will fail). + + no-X11-forwarding + Forbids X11 forwarding when this key is used for authentication. + Any X11 forward requests by the client will return an error. + + permitopen="host:port" + Limit local ``ssh -L'' port forwarding such that it may only con- + nect to the specified host and port. IPv6 addresses can be spec- + ified with an alternative syntax: host/port. Multiple permitopen + options may be applied separated by commas. No pattern matching + is performed on the specified hostnames, they must be literal do- + mains or addresses. + + tunnel="n" + Force a tun(4) device on the server. Without this option, the + next available device will be used if the client requests a tun- + nel. + + An example authorized_keys file: + + # Comments allowed at start of line + ssh-rsa AAAAB3Nza...LiPk== user@example.net + from="*.sales.example.net,!pc.sales.example.net" ssh-rsa + AAAAB2...19Q== john@example.net + command="dump /home",no-pty,no-port-forwarding ssh-dss + AAAAC3...51R== example.net + permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss + AAAAB5...21S== + tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== + jane@example.net + +SSH_KNOWN_HOSTS FILE FORMAT + The /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts 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 auto- + matically: whenever the user connects from an unknown host, its key is + added to the per-user file. + + Each line in these files contains the following fields: hostnames, bits, + exponent, modulus, comment. The fields are separated by spaces. + + Hostnames is a comma-separated list of patterns (`*' and `?' act as wild- + cards); each pattern in turn is matched against the canonical host name + (when authenticating a client) or against the user-supplied name (when + authenticating a server). A pattern may also be preceded by `!' to indi- + cate negation: if the host name matches a negated pattern, it is not ac- + cepted (by that line) even if it matched another pattern on the line. A + hostname or address may optionally be enclosed within `[' and `]' brack- + ets then followed by `:' and a non-standard port number. + + Alternately, hostnames may be stored in a hashed form which hides host + names and addresses should the file's contents be disclosed. Hashed + hostnames start with a `|' character. Only one hashed hostname may ap- + pear on a single line and none of the above negation or wildcard opera- + tors may be applied. + + Bits, exponent, and modulus are taken directly from the RSA host key; + they can be obtained, for example, from /etc/ssh/ssh_host_key.pub. 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, authentication is accepted if any + matching line has the proper key. It is thus permissible (but not recom- + mended) to have several 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 contain con- + flicting 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 /etc/ssh/ssh_host_key.pub + and adding the host names at the front. + + An example ssh_known_hosts file: + + # Comments allowed at start of line + closenet,...,192.0.2.53 1024 37 159...93 closenet.example.net + cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....= + # A hashed hostname + |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa + AAAA1234.....= + +FILES + ~/.hushlogin + This file is used to suppress printing the last login time and + /etc/motd, if PrintLastLog and PrintMotd, respectively, are en- + abled. It does not suppress printing of the banner specified by + Banner. + + ~/.rhosts + This file is used for host-based authentication (see ssh(1) for + more information). On some machines this file may need to be + world-readable if the user's home directory is on an NFS parti- + tion, because sshd reads it as root. Additionally, this file + must be owned by the user, and must not have write permissions + for anyone else. The recommended permission for most machines is + read/write for the user, and not accessible by others. + + ~/.shosts + This file is used in exactly the same way as .rhosts, but allows + host-based authentication without permitting login with + rlogin/rsh. + + ~/.ssh/authorized_keys + Lists the public keys (RSA/DSA) 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 + permissions are read/write for the user, and not accessible by + others. + + If this file, the ~/.ssh directory, or the user's home directory + are writable by other users, then the file could be modified or + replaced by unauthorized users. In this case, sshd will not al- + low it to be used unless the StrictModes option has been set to + ``no''. The recommended permissions can be set by executing + ``chmod go-w ~/ ~/.ssh ~/.ssh/authorized_keys''. + + ~/.ssh/environment + 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 processing is disabled by default and + is controlled via the PermitUserEnvironment option. + + ~/.ssh/known_hosts + 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. + + ~/.ssh/rc + 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. + + /etc/hosts.allow + /etc/hosts.deny + Access controls that should be enforced by tcp-wrappers are de- + fined here. Further details are described in hosts_access(5). + + /etc/hosts.equiv + This file is for host-based authentication (see ssh(1)). It + should only be writable by root. + + /etc/moduli + Contains Diffie-Hellman groups used for the "Diffie-Hellman Group + Exchange". The file format is described in moduli(5). + + /etc/motd + See motd(5). + + /etc/nologin + If this file exists, sshd refuses to let anyone except root log + in. The contents of the file are displayed to anyone trying to + log in, and non-root connections are refused. The file should be + world-readable. + + /etc/shosts.equiv + This file is used in exactly the same way as hosts.equiv, but al- + lows host-based authentication without permitting login with + rlogin/rsh. + + /etc/ssh/ssh_known_hosts + 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 de- + scribed above. This file should be writable only by root/the + owner and should be world-readable. + + /etc/ssh/ssh_host_key + /etc/ssh/ssh_host_dsa_key + /etc/ssh/ssh_host_rsa_key + These three 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 sshd does not start if + these files are group/world-accessible. + + /etc/ssh/ssh_host_key.pub + /etc/ssh/ssh_host_dsa_key.pub + /etc/ssh/ssh_host_rsa_key.pub + These three files contain the public parts of the host keys. + These files should be world-readable 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 ssh-keygen(1). + + /etc/ssh/sshd_config + Contains configuration data for sshd. The file format and con- + figuration options are described in sshd_config(5). + + /etc/ssh/sshrc + Similar to ~/.ssh/rc, 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. + + /var/empty + chroot(2) directory used by sshd during privilege separation in + the pre-authentication phase. The directory should not contain + any files and must be owned by root and not group or world- + writable. + + /var/run/sshd.pid + Contains the process ID of the sshd 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-read- + able. + +SEE ALSO + scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), + chroot(2), hosts_access(5), login.conf(5), moduli(5), sshd_config(5), + inetd(8), sftp-server(8) + +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 cre- + ated 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. + +CAVEATS + System security is not improved unless rshd, rlogind, and rexecd are dis- + abled (thus completely disabling rlogin and rsh into the machine). + +OpenBSD 4.1 September 25, 1999 9 |