mirror of
				https://github.com/PowerShell/Win32-OpenSSH.git
				synced 2025-10-31 03:34:16 +01:00 
			
		
		
		
	
		
			
				
	
	
		
			636 lines
		
	
	
		
			33 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			636 lines
		
	
	
		
			33 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| SSHD(8)                     System Manager's Manual                    SSHD(8)
 | |
| 
 | |
| NAME
 | |
|      sshd M-bM-^@M-^S OpenSSH SSH daemon
 | |
| 
 | |
| SYNOPSIS
 | |
|      sshd [-46DdeiqTt] [-b bits] [-C connection_spec]
 | |
|           [-c host_certificate_file] [-E log_file] [-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
 | |
|      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.
 | |
| 
 | |
|      -b bits
 | |
|              Specifies the number of bits in the ephemeral protocol version 1
 | |
|              server key (default 1024).
 | |
| 
 | |
|      -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 to the specified user, host, and address
 | |
|              will be set before the configuration is written to standard
 | |
|              output.  The connection parameters are supplied as keyword=value
 | |
|              pairs.  The keywords are M-bM-^@M-^\userM-bM-^@M-^], M-bM-^@M-^\hostM-bM-^@M-^], M-bM-^@M-^\laddrM-bM-^@M-^], M-bM-^@M-^\lportM-bM-^@M-^], and
 | |
|              M-bM-^@M-^\addrM-bM-^@M-^].  All are required and may be supplied in any order,
 | |
|              either with multiple -C options or as a comma-separated list.
 | |
| 
 | |
|      -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 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_key for protocol version 1, and
 | |
|              /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key.
 | |
|              /etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key for
 | |
|              protocol 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).  If SSH protocol
 | |
|              1 is enabled, sshd should not  normally be run from inetd because
 | |
|              it needs to generate the server key before it can respond to the
 | |
|              client, and this may take some time.  Clients may have to wait
 | |
|              too long if the key was regenerated every time.
 | |
| 
 | |
|      -k key_gen_time
 | |
|              Specifies how often the ephemeral protocol version 1 server key
 | |
|              is regenerated (default 3600 seconds, or one hour).  The
 | |
|              motivation 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 zero indicates that the key will never be
 | |
|              regenerated.
 | |
| 
 | |
|      -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 RhostsRSAAuthentication,
 | |
|              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 protocols 1 and 2.  The default is to
 | |
|      use protocol 2 only, though this can be changed via the Protocol option
 | |
|      in sshd_config(5).  Protocol 2 supports DSA, ECDSA, Ed25519 and RSA keys;
 | |
|      protocol 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 1024 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
 | |
|      generates 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 encryption 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
 | |
|      cryptographic message authentication code (hmac-md5, hmac-sha1, umac-64,
 | |
|      umac-128, hmac-ripemd160, hmac-sha2-256 or hmac-sha2-512).
 | |
| 
 | |
|      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 dependant. Some platforms have
 | |
|      their own account database (eg AIX) and some modify the passwd field (
 | |
|      M-bM-^@M-^X*LK*M-bM-^@M-^Y on Solaris and UnixWare, M-bM-^@M-^X*M-bM-^@M-^Y on HP-UX, containing M-bM-^@M-^XNologinM-bM-^@M-^Y on
 | |
|      Tru64, a leading M-bM-^@M-^X*LOCKED*M-bM-^@M-^Y on FreeBSD and a leading M-bM-^@M-^X!M-bM-^@M-^Y 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 M-bM-^@M-^XNPM-bM-^@M-^Y or M-bM-^@M-^X*NP*M-bM-^@M-^Y ).
 | |
| 
 | |
|      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.  The M-bM-^@M-^\rcM-bM-^@M-^] 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.
 | |
| 
 | |
| AUTHORIZED_KEYS FILE FORMAT
 | |
|      AuthorizedKeysFile specifies the files containing public keys for public
 | |
|      key authentication; if none is specified, the default is
 | |
|      ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2.  Each line of the
 | |
|      file contains one key (empty lines and lines starting with a M-bM-^@M-^X#M-bM-^@M-^Y 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: options, keytype, base64-encoded key,
 | |
|      comment.  The options field is optional; its presence is determined by
 | |
|      whether the line starts with a number or not (the options field never
 | |
|      starts with a number).  The bits, exponent, 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 M-bM-^@M-^\ecdsa-sha2-nistp256M-bM-^@M-^],
 | |
|      M-bM-^@M-^\ecdsa-sha2-nistp384M-bM-^@M-^], M-bM-^@M-^\ecdsa-sha2-nistp521M-bM-^@M-^], M-bM-^@M-^\ssh-ed25519M-bM-^@M-^], M-bM-^@M-^\ssh-dssM-bM-^@M-^] or
 | |
|      M-bM-^@M-^\ssh-rsaM-bM-^@M-^].
 | |
| 
 | |
|      Note that lines in this file are usually several hundred bytes long
 | |
|      (because of the size of the public key encoding) up to a limit of 8
 | |
|      kilobytes, 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, id_ecdsa.pub, id_ed25519.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
 | |
|      specifications.  No spaces are permitted, except within double quotes.
 | |
|      The following option specifications are supported (note that option
 | |
|      keywords are case-insensitive):
 | |
| 
 | |
|      cert-authority
 | |
|              Specifies that the listed key is a certification authority (CA)
 | |
|              that is trusted to validate signed certificates for user
 | |
|              authentication.
 | |
| 
 | |
|              Certificates may encode access restrictions similar to these key
 | |
|              options.  If both certificate restrictions and key options are
 | |
|              present, the most restrictive union of the two is applied.
 | |
| 
 | |
|      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
 | |
|              channel 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 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.  The command originally
 | |
|              supplied by the client is available in the SSH_ORIGINAL_COMMAND
 | |
|              environment variable.  Note that this option applies to shell,
 | |
|              command or subsystem execution.  Also note that this command may
 | |
|              be superseded by either a sshd_config(5) ForceCommand directive
 | |
|              or a command embedded in a certificate.
 | |
| 
 | |
|      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, either
 | |
|              the canonical name of the remote host or its IP address must be
 | |
|              present in the comma-separated list of patterns.  See PATTERNS in
 | |
|              ssh_config(5) for more information on patterns.
 | |
| 
 | |
|              In addition to the wildcard matching that may be applied to
 | |
|              hostnames or addresses, a from stanza may match IP addresses
 | |
|              using CIDR address/masklen notation.
 | |
| 
 | |
|              The purpose of this option is to optionally 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 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 compromised in addition to just the key).
 | |
| 
 | |
|      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-user-rc
 | |
|              Disables execution of ~/.ssh/rc.
 | |
| 
 | |
|      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 port forwarding with ssh(1) -L such that it may only
 | |
|              connect to the specified host and port.  IPv6 addresses can be
 | |
|              specified by enclosing the address in square brackets.  Multiple
 | |
|              permitopen options may be applied separated by commas.  No
 | |
|              pattern matching is performed on the specified hostnames, they
 | |
|              must be literal domains or addresses.  A port specification of *
 | |
|              matches any port.
 | |
| 
 | |
|      principals="principals"
 | |
|              On a cert-authority line, specifies allowed principals for
 | |
|              certificate authentication 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 cert-authority option.
 | |
| 
 | |
|      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
 | |
|              tunnel.
 | |
| 
 | |
|      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
 | |
|      automatically: 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: markers
 | |
|      (optional), hostnames, bits, exponent, modulus, comment.  The fields are
 | |
|      separated by spaces.
 | |
| 
 | |
|      The marker is optional, but if it is present then it must be one of
 | |
|      M-bM-^@M-^\@cert-authorityM-bM-^@M-^], to indicate that the line contains a certification
 | |
|      authority (CA) key, or M-bM-^@M-^\@revokedM-bM-^@M-^], 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 (M-bM-^@M-^X*M-bM-^@M-^Y and M-bM-^@M-^X?M-bM-^@M-^Y act as
 | |
|      wildcards); 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 M-bM-^@M-^X!M-bM-^@M-^Y 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 M-bM-^@M-^X[M-bM-^@M-^Y and M-bM-^@M-^X]M-bM-^@M-^Y
 | |
|      brackets then followed by M-bM-^@M-^X:M-bM-^@M-^Y 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 M-bM-^@M-^X|M-bM-^@M-^Y character.  Only one hashed hostname may
 | |
|      appear on a single line and none of the above negation or wildcard
 | |
|      operators 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 M-bM-^@M-^X#M-bM-^@M-^Y and empty lines are ignored as comments.
 | |
| 
 | |
|      When performing host authentication, authentication 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 authority that signed the certificate.  For a key to be
 | |
|      trusted as a certification authority, it must use the M-bM-^@M-^\@cert-authorityM-bM-^@M-^]
 | |
|      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 including the M-bM-^@M-^\@revokedM-bM-^@M-^] marker at
 | |
|      the beginning of the key line, and are never accepted for authentication
 | |
|      or as certification authorities, but instead will produce a warning from
 | |
|      ssh(1) when they are encountered.
 | |
| 
 | |
|      It is permissible (but not recommended) 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 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, ssh-keyscan(1) or by taking
 | |
|      /etc/ssh/ssh_host_key.pub and adding the host names at the front.
 | |
|      ssh-keygen(1) also offers some basic automated editing for
 | |
|      ~/.ssh/known_hosts 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
 | |
|         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.....=
 | |
|         # 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...
 | |
| 
 | |
| FILES
 | |
|      ~/.hushlogin
 | |
|              This file is used to suppress printing the last login time and
 | |
|              /etc/motd, if PrintLastLog and PrintMotd, respectively, are
 | |
|              enabled.  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
 | |
|              partition, 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/
 | |
|              This directory is the default location for all user-specific
 | |
|              configuration 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.
 | |
| 
 | |
|      ~/.ssh/authorized_keys
 | |
|              Lists the public keys (DSA, 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 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
 | |
|              allow it to be used unless the StrictModes option has been set to
 | |
|              M-bM-^@M-^\noM-bM-^@M-^].
 | |
| 
 | |
|      ~/.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
 | |
|              M-bM-^@M-^X#M-bM-^@M-^Y), 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.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
 | |
|              allows host-based authentication without permitting login with
 | |
|              rlogin/rsh.
 | |
| 
 | |
|      /etc/ssh/ssh_host_key
 | |
|      /etc/ssh/ssh_host_dsa_key
 | |
|      /etc/ssh/ssh_host_ecdsa_key
 | |
|      /etc/ssh/ssh_host_ed25519_key
 | |
|      /etc/ssh/ssh_host_rsa_key
 | |
|              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 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_ecdsa_key.pub
 | |
|      /etc/ssh/ssh_host_ed25519_key.pub
 | |
|      /etc/ssh/ssh_host_rsa_key.pub
 | |
|              These 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/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
 | |
|              described above.  This file should be writable only by root/the
 | |
|              owner and should be world-readable.
 | |
| 
 | |
|      /etc/ssh/sshd_config
 | |
|              Contains configuration data for sshd.  The file format and
 | |
|              configuration 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-
 | |
|              readable.
 | |
| 
 | |
| SEE ALSO
 | |
|      scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1),
 | |
|      ssh-keyscan(1), chroot(2), 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
 | |
|      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.
 | |
| 
 | |
| OpenBSD 5.8                      July 3, 2015                      OpenBSD 5.8
 |