Import OpenSSH 4.2p1.

1 files changed, 730 insertions, 0 deletions

diff --git a/ssh.0 b/ssh.0
new file mode 100644
index 000000000..274fab8b5
--- /dev/null
+++ b/ssh.0
@@ -0,0 +1,730 @@
+SSH(1)                     OpenBSD Reference Manual                     SSH(1)
+
+NAME
+     ssh - OpenSSH SSH client (remote login program)
+
+SYNOPSIS
+     ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
+         [-D port] [-e escape_char] [-F configfile] [-i identity_file]
+         [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]
+         [-O ctl_cmd] [-o option] [-p port]
+         [-R [bind_address:]port:host:hostport] [-S ctl_path] [user@]hostname
+         [command]
+
+DESCRIPTION
+     ssh (SSH client) is a program for logging into a remote machine and for
+     executing commands on a remote machine.  It is intended to replace rlogin
+     and rsh, and provide secure encrypted communications between two untrust-
+     ed hosts over an insecure network.  X11 connections and arbitrary TCP/IP
+     ports can also be forwarded over the secure channel.
+
+     ssh connects and logs into the specified hostname (with optional user
+     name).  The user must prove his/her identity to the remote machine using
+     one of several methods depending on the protocol version used.
+
+     If command is specified, command is executed on the remote host instead
+     of a login shell.
+
+   SSH protocol version 1
+     The first authentication method is the rhosts or hosts.equiv method com-
+     bined with RSA-based host authentication.  If the machine the user logs
+     in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote
+     machine, and the user names are the same on both sides, or if the files
+     ~/.rhosts or ~/.shosts exist in the user's home directory on the remote
+     machine and contain a line containing the name of the client machine and
+     the name of the user on that machine, the user is considered for log in.
+     Additionally, if the server can verify the client's host key (see
+     /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts in the FILES section),
+     only then is login permitted.  This authentication method closes security
+     holes due to IP spoofing, DNS spoofing and routing spoofing.  [Note to
+     the administrator: /etc/hosts.equiv, ~/.rhosts, and the rlogin/rsh proto-
+     col in general, are inherently insecure and should be disabled if securi-
+     ty is desired.]
+
+     As a second authentication method, ssh supports RSA based authentication.
+     The scheme is based on public-key cryptography: there are cryptosystems
+     where encryption and decryption are done using separate keys, and it is
+     not possible to derive the decryption key from the encryption key.  RSA
+     is one such system.  The idea is that each user creates a public/private
+     key pair for authentication purposes.  The server knows the public key,
+     and only the user knows the private key.
+
+     The file ~/.ssh/authorized_keys lists the public keys that are permitted
+     for logging in.  When the user logs in, the ssh program tells the server
+     which key pair it would like to use for authentication.  The server
+     checks if this key is permitted, and if so, sends the user (actually the
+     ssh program running on behalf of the user) a challenge, a random number,
+     encrypted by the user's public key.  The challenge can only be decrypted
+     using the proper private key.  The user's client then decrypts the chal-
+     lenge using the private key, proving that he/she knows the private key
+     but without disclosing it to the server.
+
+     ssh implements the RSA authentication protocol automatically.  The user
+     creates his/her RSA key pair by running ssh-keygen(1).  This stores the
+     private key in ~/.ssh/identity and stores the public key in
+     ~/.ssh/identity.pub in the user's home directory.  The user should then
+     copy the identity.pub to ~/.ssh/authorized_keys in his/her home directory
+     on the remote machine (the authorized_keys file corresponds to the con-
+     ventional ~/.rhosts file, and has one key per line, though the lines can
+     be very long).  After this, the user can log in without giving the pass-
+     word.
+
+     The most convenient way to use RSA authentication may be with an authen-
+     tication agent.  See ssh-agent(1) for more information.
+
+     If other authentication methods fail, ssh prompts the user for a pass-
+     word.  The password is sent to the remote host for checking; however,
+     since all communications are encrypted, the password cannot be seen by
+     someone listening on the network.
+
+   SSH protocol version 2
+     When a user connects using protocol version 2, similar authentication
+     methods are available.  Using the default values for
+     PreferredAuthentications, the client will try to authenticate first using
+     the hostbased method; if this method fails, public key authentication is
+     attempted, and finally if this method fails, keyboard-interactive and
+     password authentication are tried.
+
+     The public key method is similar to RSA authentication described in the
+     previous section and allows the RSA or DSA algorithm to be used: The
+     client uses his private key, ~/.ssh/id_dsa or ~/.ssh/id_rsa, to sign the
+     session identifier and sends the result to the server.  The server checks
+     whether the matching public key is listed in ~/.ssh/authorized_keys and
+     grants access if both the key is found and the signature is correct.  The
+     session identifier is derived from a shared Diffie-Hellman value and is
+     only known to the client and the server.
+
+     If public key authentication fails or is not available, a password can be
+     sent encrypted to the remote host to prove the user's identity.
+
+     Additionally, ssh supports hostbased or challenge response authentica-
+     tion.
+
+     Protocol 2 provides additional mechanisms for confidentiality (the traf-
+     fic is encrypted using AES, 3DES, Blowfish, CAST128 or Arcfour) and in-
+     tegrity (hmac-md5, hmac-sha1, hmac-ripemd160).  Note that protocol 1
+     lacks a strong mechanism for ensuring the integrity of the connection.
+
+   Login session and remote execution
+     When the user's identity has been accepted by the server, the server ei-
+     ther executes the given command, or logs into the machine and gives the
+     user a normal shell on the remote machine.  All communication with the
+     remote command or shell will be automatically encrypted.
+
+     If a pseudo-terminal has been allocated (normal login session), the user
+     may use the escape characters noted below.
+
+     If no pseudo-tty has been allocated, the session is transparent and can
+     be used to reliably transfer binary data.  On most systems, setting the
+     escape character to ``none'' will also make the session transparent even
+     if a tty is used.
+
+     The session terminates when the command or shell on the remote machine
+     exits and all X11 and TCP/IP connections have been closed.  The exit sta-
+     tus of the remote program is returned as the exit status of ssh.
+
+   Escape Characters
+     When a pseudo-terminal has been requested, ssh supports a number of func-
+     tions through the use of an escape character.
+
+     A single tilde character can be sent as ~~ or by following the tilde by a
+     character other than those described below.  The escape character must
+     always follow a newline to be interpreted as special.  The escape charac-
+     ter can be changed in configuration files using the EscapeChar configura-
+     tion directive or on the command line by the -e option.
+
+     The supported escapes (assuming the default `~') are:
+
+     ~.      Disconnect.
+
+     ~^Z     Background ssh.
+
+     ~#      List forwarded connections.
+
+     ~&      Background ssh at logout when waiting for forwarded connection /
+             X11 sessions to terminate.
+
+     ~?      Display a list of escape characters.
+
+     ~B      Send a BREAK to the remote system (only useful for SSH protocol
+             version 2 and if the peer supports it).
+
+     ~C      Open command line.  Currently this allows the addition of port
+             forwardings using the -L and -R options (see below).  It also al-
+             lows the cancellation of existing remote port-forwardings using
+             -KR hostport.  Basic help is available, using the -h option.
+
+     ~R      Request rekeying of the connection (only useful for SSH protocol
+             version 2 and if the peer supports it).
+
+   X11 and TCP forwarding
+     If the ForwardX11 variable is set to ``yes'' (or see the description of
+     the -X and -x options described later) and the user is using X11 (the
+     DISPLAY environment variable is set), the connection to the X11 display
+     is automatically forwarded to the remote side in such a way that any X11
+     programs started from the shell (or command) will go through the encrypt-
+     ed channel, and the connection to the real X server will be made from the
+     local machine.  The user should not manually set DISPLAY.  Forwarding of
+     X11 connections can be configured on the command line or in configuration
+     files.
+
+     The DISPLAY value set by ssh will point to the server machine, but with a
+     display number greater than zero.  This is normal, and happens because
+     ssh creates a ``proxy'' X server on the server machine for forwarding the
+     connections over the encrypted channel.
+
+     ssh will also automatically set up Xauthority data on the server machine.
+     For this purpose, it will generate a random authorization cookie, store
+     it in Xauthority on the server, and verify that any forwarded connections
+     carry this cookie and replace it by the real cookie when the connection
+     is opened.  The real authentication cookie is never sent to the server
+     machine (and no cookies are sent in the plain).
+
+     If the ForwardAgent variable is set to ``yes'' (or see the description of
+     the -A and -a options described later) and the user is using an authenti-
+     cation agent, the connection to the agent is automatically forwarded to
+     the remote side.
+
+     Forwarding of arbitrary TCP/IP connections over the secure channel can be
+     specified either on the command line or in a configuration file.  One
+     possible application of TCP/IP forwarding is a secure connection to an
+     electronic purse; another is going through firewalls.
+
+   Server authentication
+     ssh automatically maintains and checks a database containing identifica-
+     tions for all hosts it has ever been used with.  Host keys are stored in
+     ~/.ssh/known_hosts in the user's home directory.  Additionally, the file
+     /etc/ssh/ssh_known_hosts is automatically checked for known hosts.  Any
+     new hosts are automatically added to the user's file.  If a host's iden-
+     tification ever changes, ssh warns about this and disables password au-
+     thentication to prevent a trojan horse from getting the user's password.
+     Another purpose of this mechanism is to prevent man-in-the-middle attacks
+     which could otherwise be used to circumvent the encryption.  The
+     StrictHostKeyChecking option can be used to prevent logins to machines
+     whose host key is not known or has changed.
+
+     ssh can be configured to verify host identification using fingerprint re-
+     source records (SSHFP) published in DNS.  The VerifyHostKeyDNS option can
+     be used to control how DNS lookups are performed.  SSHFP resource records
+     can be generated using ssh-keygen(1).
+
+     The options are as follows:
+
+     -1      Forces ssh to try protocol version 1 only.
+
+     -2      Forces ssh to try protocol version 2 only.
+
+     -4      Forces ssh to use IPv4 addresses only.
+
+     -6      Forces ssh to use IPv6 addresses only.
+
+     -A      Enables forwarding of the authentication agent connection.  This
+             can also be specified on a per-host basis in a configuration
+             file.
+
+             Agent forwarding should be enabled with caution.  Users with the
+             ability to bypass file permissions on the remote host (for the
+             agent's Unix-domain socket) can access the local agent through
+             the forwarded connection.  An attacker cannot obtain key material
+             from the agent, however they can perform operations on the keys
+             that enable them to authenticate using the identities loaded into
+             the agent.
+
+     -a      Disables forwarding of the authentication agent connection.
+
+     -b bind_address
+             Use bind_address on the local machine as the source address of
+             the connection.  Only useful on systems with more than one ad-
+             dress.
+
+     -C      Requests compression of all data (including stdin, stdout,
+             stderr, and data for forwarded X11 and TCP/IP connections).  The
+             compression algorithm is the same used by gzip(1), and the
+             ``level'' can be controlled by the CompressionLevel option for
+             protocol version 1.  Compression is desirable on modem lines and
+             other slow connections, but will only slow down things on fast
+             networks.  The default value can be set on a host-by-host basis
+             in the configuration files; see the Compression option.
+
+     -c cipher_spec
+             Selects the cipher specification for encrypting the session.
+
+             Protocol version 1 allows specification of a single cipher.  The
+             suported values are ``3des'', ``blowfish'' and ``des''.  3des
+             (triple-des) is an encrypt-decrypt-encrypt triple with three dif-
+             ferent keys.  It is believed to be secure.  blowfish is a fast
+             block cipher; it appears very secure and is much faster than
+             3des.  des is only supported in the ssh client for interoperabil-
+             ity with legacy protocol 1 implementations that do not support
+             the 3des cipher.  Its use is strongly discouraged due to crypto-
+             graphic weaknesses.  The default is ``3des''.
+
+             For protocol version 2 cipher_spec is a comma-separated list of
+             ciphers listed in order of preference.  The supported ciphers are
+             ``3des-cbc'', ``aes128-cbc'', ``aes192-cbc'', ``aes256-cbc'',
+             ``aes128-ctr'', ``aes192-ctr'', ``aes256-ctr'', ``arcfour128'',
+             ``arcfour256'', ``arcfour'', ``blowfish-cbc'', and
+             ``cast128-cbc''.  The default is
+
+               ``aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
+                 arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
+                 aes192-ctr,aes256-ctr''
+
+     -D port
+             Specifies a local ``dynamic'' application-level port forwarding.
+             This works by allocating a socket to listen to port on the local
+             side, and whenever a connection is made to this port, the connec-
+             tion is forwarded over the secure channel, and the application
+             protocol is then used to determine where to connect to from the
+             remote machine.  Currently the SOCKS4 and SOCKS5 protocols are
+             supported, and ssh will act as a SOCKS server.  Only root can
+             forward privileged ports.  Dynamic port forwardings can also be
+             specified in the configuration file.
+
+     -e ch | ^ch | none
+             Sets the escape character for sessions with a pty (default: `~').
+             The escape character is only recognized at the beginning of a
+             line.  The escape character followed by a dot (`.') closes the
+             connection; followed by control-Z suspends the connection; and
+             followed by itself sends the escape character once.  Setting the
+             character to ``none'' disables any escapes and makes the session
+             fully transparent.
+
+     -F configfile
+             Specifies an alternative per-user configuration file.  If a con-
+             figuration file is given on the command line, the system-wide
+             configuration file (/etc/ssh/ssh_config) will be ignored.  The
+             default for the per-user configuration file is ~/.ssh/config.
+
+     -f      Requests ssh to go to background just before command execution.
+             This is useful if ssh is going to ask for passwords or passphras-
+             es, but the user wants it in the background.  This implies -n.
+             The recommended way to start X11 programs at a remote site is
+             with something like ssh -f host xterm.
+
+     -g      Allows remote hosts to connect to local forwarded ports.
+
+     -I smartcard_device
+             Specifies which smartcard device to use.  The argument is the de-
+             vice ssh should use to communicate with a smartcard used for
+             storing the user's private RSA key.
+
+     -i identity_file
+             Selects a file from which the identity (private key) for RSA or
+             DSA authentication is read.  The default is ~/.ssh/identity for
+             protocol version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for pro-
+             tocol version 2.  Identity files may also be specified on a per-
+             host basis in the configuration file.  It is possible to have
+             multiple -i options (and multiple identities specified in config-
+             uration files).
+
+     -k      Disables forwarding (delegation) of GSSAPI credentials to the
+             server.
+
+     -L [bind_address:]port:host:hostport
+             Specifies that the given port on the local (client) host is to be
+             forwarded to the given host and port on the remote side.  This
+             works by allocating a socket to listen to port on the local side,
+             optionally bound to the specified bind_address.  Whenever a con-
+             nection is made to this port, the connection is forwarded over
+             the secure channel, and a connection is made to host port
+             hostport from the remote machine.  Port forwardings can also be
+             specified in the configuration file.  IPv6 addresses can be spec-
+             ified with an alternative syntax: [bind_address/]port/host/host-
+             port or by enclosing the address in square brackets.  Only the
+             superuser can forward privileged ports.  By default, the local
+             port is bound in accordance with the GatewayPorts setting.  How-
+             ever, an explicit bind_address may be used to bind the connection
+             to a specific address.  The bind_address of ``localhost'' indi-
+             cates that the listening port be bound for local use only, while
+             an empty address or `*' indicates that the port should be avail-
+             able from all interfaces.
+
+     -l login_name
+             Specifies the user to log in as on the remote machine.  This also
+             may be specified on a per-host basis in the configuration file.
+
+     -M      Places the ssh client into ``master'' mode for connection shar-
+             ing.  Refer to the description of ControlMaster in ssh_config(5)
+             for details.
+
+     -m mac_spec
+             Additionally, for protocol version 2 a comma-separated list of
+             MAC (message authentication code) algorithms can be specified in
+             order of preference.  See the MACs keyword for more information.
+
+     -N      Do not execute a remote command.  This is useful for just for-
+             warding ports (protocol version 2 only).
+
+     -n      Redirects stdin from /dev/null (actually, prevents reading from
+             stdin).  This must be used when ssh is run in the background.  A
+             common trick is to use this to run X11 programs on a remote ma-
+             chine.  For example, ssh -n shadows.cs.hut.fi emacs & will start
+             an emacs on shadows.cs.hut.fi, and the X11 connection will be au-
+             tomatically forwarded over an encrypted channel.  The ssh program
+             will be put in the background.  (This does not work if ssh needs
+             to ask for a password or passphrase; see also the -f option.)
+
+     -O ctl_cmd
+             Control an active connection multiplexing master process.  When
+             the -O option is specified, the ctl_cmd argument is interpreted
+             and passed to the master process.  Valid commands are: ``check''
+             (check that the master process is running) and ``exit'' (request
+             the master to exit).
+
+     -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 listed below, and their possible values, see ssh_config(5).
+
+                   AddressFamily
+                   BatchMode
+                   BindAddress
+                   ChallengeResponseAuthentication
+                   CheckHostIP
+                   Cipher
+                   Ciphers
+                   ClearAllForwardings
+                   Compression
+                   CompressionLevel
+                   ConnectionAttempts
+                   ConnectTimeout
+                   ControlMaster
+                   ControlPath
+                   DynamicForward
+                   EscapeChar
+                   ForwardAgent
+                   ForwardX11
+                   ForwardX11Trusted
+                   GatewayPorts
+                   GlobalKnownHostsFile
+                   GSSAPIAuthentication
+                   GSSAPIDelegateCredentials
+                   HashKnownHosts
+                   Host
+                   HostbasedAuthentication
+                   HostKeyAlgorithms
+                   HostKeyAlias
+                   HostName
+                   IdentityFile
+                   IdentitiesOnly
+                   KbdInteractiveDevices
+                   LocalForward
+                   LogLevel
+                   MACs
+                   NoHostAuthenticationForLocalhost
+                   NumberOfPasswordPrompts
+                   PasswordAuthentication
+                   Port
+                   PreferredAuthentications
+                   Protocol
+                   ProxyCommand
+                   PubkeyAuthentication
+                   RemoteForward
+                   RhostsRSAAuthentication
+                   RSAAuthentication
+                   SendEnv
+                   ServerAliveInterval
+                   ServerAliveCountMax
+                   SmartcardDevice
+                   StrictHostKeyChecking
+                   TCPKeepAlive
+                   UsePrivilegedPort
+                   User
+                   UserKnownHostsFile
+                   VerifyHostKeyDNS
+                   XAuthLocation
+
+     -p port
+             Port to connect to on the remote host.  This can be specified on
+             a per-host basis in the configuration file.
+
+     -q      Quiet mode.  Causes all warning and diagnostic messages to be
+             suppressed.
+
+     -R [bind_address:]port:host:hostport
+             Specifies that the given port on the remote (server) host is to
+             be forwarded to the given host and port on the local side.  This
+             works by allocating a socket to listen to port on the remote
+             side, and whenever a connection is made to this port, the connec-
+             tion is forwarded over the secure channel, and a connection is
+             made to host port hostport from the local machine.
+
+             Port forwardings can also be specified in the configuration file.
+             Privileged ports can be forwarded only when logging in as root on
+             the remote machine.  IPv6 addresses can be specified by enclosing
+             the address in square braces or using an alternative syntax:
+             [bind_address/]host/port/hostport.
+
+             By default, the listening socket on the server will be bound to
+             the loopback interface only.  This may be overriden by specifying
+             a bind_address.  An empty bind_address, or the address `*', indi-
+             cates that the remote socket should listen on all interfaces.
+             Specifying a remote bind_address will only succeed if the serv-
+             er's GatewayPorts option is enabled (see sshd_config(5)).
+
+     -S ctl_path
+             Specifies the location of a control socket for connection shar-
+             ing.  Refer to the description of ControlPath and ControlMaster
+             in ssh_config(5) for details.
+
+     -s      May be used to request invocation of a subsystem on the remote
+             system.  Subsystems are a feature of the SSH2 protocol which fa-
+             cilitate the use of SSH as a secure transport for other applica-
+             tions (eg. sftp(1)).  The subsystem is specified as the remote
+             command.
+
+     -T      Disable pseudo-tty allocation.
+
+     -t      Force pseudo-tty allocation.  This can be used to execute arbi-
+             trary screen-based programs on a remote machine, which can be
+             very useful, e.g., when implementing menu services.  Multiple -t
+             options force tty allocation, even if ssh has no local tty.
+
+     -V      Display the version number and exit.
+
+     -v      Verbose mode.  Causes ssh to print debugging messages about its
+             progress.  This is helpful in debugging connection, authentica-
+             tion, and configuration problems.  Multiple -v options increase
+             the verbosity.  The maximum is 3.
+
+     -X      Enables X11 forwarding.  This can also be specified on a per-host
+             basis in a configuration file.
+
+             X11 forwarding should be enabled with caution.  Users with the
+             ability to bypass file permissions on the remote host (for the
+             user's X authorization database) can access the local X11 display
+             through the forwarded connection.  An attacker may then be able
+             to perform activities such as keystroke monitoring.
+
+             For this reason, X11 forwarding is subjected to X11 SECURITY ex-
+             tension restrictions by default.  Please refer to the ssh -Y op-
+             tion and the ForwardX11Trusted directive in ssh_config(5) for
+             more information.
+
+     -x      Disables X11 forwarding.
+
+     -Y      Enables trusted X11 forwarding.  Trusted X11 forwardings are not
+             subjected to the X11 SECURITY extension controls.
+
+CONFIGURATION FILES
+     ssh may additionally obtain configuration data from a per-user configura-
+     tion file and a system-wide configuration file.  The file format and con-
+     figuration options are described in ssh_config(5).
+
+ENVIRONMENT
+     ssh will normally set the following environment variables:
+
+     DISPLAY  The DISPLAY variable indicates the location of the X11 server.
+              It is automatically set by ssh to point to a value of the form
+              ``hostname:n'' where hostname indicates the host where the shell
+              runs, and n is an integer >= 1.  ssh uses this special value to
+              forward X11 connections over the secure channel.  The user
+              should normally not set DISPLAY explicitly, as that will render
+              the X11 connection insecure (and will require the user to manu-
+              ally copy any required authorization cookies).
+
+     HOME     Set to the path of the user's home directory.
+
+     LOGNAME  Synonym for USER; set for compatibility with systems that use
+              this variable.
+
+     MAIL     Set to the path of the user's mailbox.
+
+     PATH     Set to the default PATH, as specified when compiling ssh.
+
+     SSH_ASKPASS
+              If ssh needs a passphrase, it will read the passphrase from the
+              current terminal if it was run from a terminal.  If ssh does not
+              have a terminal associated with it but DISPLAY and SSH_ASKPASS
+              are set, it will execute the program specified by SSH_ASKPASS
+              and open an X11 window to read the passphrase.  This is particu-
+              larly useful when calling ssh from a .xsession or related
+              script.  (Note that on some machines it may be necessary to
+              redirect the input from /dev/null to make this work.)
+
+     SSH_AUTH_SOCK
+              Identifies the path of a unix-domain socket used to communicate
+              with the agent.
+
+     SSH_CONNECTION
+              Identifies the client and server ends of the connection.  The
+              variable contains four space-separated values: client ip-ad-
+              dress, client port number, server ip-address and server port
+              number.
+
+     SSH_ORIGINAL_COMMAND
+              The variable contains the original command line if a forced com-
+              mand is executed.  It can be used to extract the original argu-
+              ments.
+
+     SSH_TTY  This is set to the name of the tty (path to the device) associ-
+              ated with the current shell or command.  If the current session
+              has no tty, this variable is not set.
+
+     TZ       The timezone variable is set to indicate the present timezone if
+              it was set when the daemon was started (i.e., the daemon passes
+              the value on to new connections).
+
+     USER     Set to the name of the user logging in.
+
+     Additionally, ssh reads ~/.ssh/environment, and adds lines of the format
+     ``VARNAME=value'' to the environment if the file exists and if users are
+     allowed to change their environment.  For more information, see the
+     PermitUserEnvironment option in sshd_config(5).
+
+FILES
+     ~/.ssh/known_hosts
+             Records host keys for all hosts the user has logged into that are
+             not in /etc/ssh/ssh_known_hosts.  See sshd(8).
+
+     ~/.ssh/identity, ~/.ssh/id_dsa, ~/.ssh/id_rsa
+             Contains the authentication identity of the user.  They are for
+             protocol 1 RSA, protocol 2 DSA, and protocol 2 RSA, respectively.
+             These files contain sensitive data and should be readable by the
+             user but not accessible by others (read/write/execute).  Note
+             that ssh ignores a private key file if it is accessible by oth-
+             ers.  It is possible to specify a passphrase when generating the
+             key; the passphrase will be used to encrypt the sensitive part of
+             this file using 3DES.
+
+     ~/.ssh/identity.pub, ~/.ssh/id_dsa.pub, ~/.ssh/id_rsa.pub
+             Contains the public key for authentication (public part of the
+             identity file in human-readable form).  The contents of the
+             ~/.ssh/identity.pub file should be added to the file
+             ~/.ssh/authorized_keys on all machines where the user wishes to
+             log in using protocol version 1 RSA authentication.  The contents
+             of the ~/.ssh/id_dsa.pub and ~/.ssh/id_rsa.pub file should be
+             added to ~/.ssh/authorized_keys on all machines where the user
+             wishes to log in using protocol version 2 DSA/RSA authentication.
+             These files are not sensitive and can (but need not) be readable
+             by anyone.  These files are never used automatically and are not
+             necessary; they are only provided for the convenience of the us-
+             er.
+
+     ~/.ssh/config
+             This is the per-user configuration file.  The file format and
+             configuration options are described in ssh_config(5).  Because of
+             the potential for abuse, this file must have strict permissions:
+             read/write for the user, and not accessible by others.
+
+     ~/.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 in the
+             sshd(8) manual page.  In the simplest form the format is the same
+             as the .pub identity files.  This file is not highly sensitive,
+             but the recommended permissions are read/write for the user, and
+             not accessible by others.
+
+     /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.  This file should be world-
+             readable.  This file contains public keys, one per line, in the
+             following format (fields separated by spaces): system name, pub-
+             lic key and optional comment field.  When different names are
+             used for the same machine, all such names should be listed, sepa-
+             rated by commas.  The format is described in the sshd(8) manual
+             page.
+
+             The canonical system name (as returned by name servers) is used
+             by sshd(8) to verify the client host when logging in; other names
+             are needed because ssh does not convert the user-supplied name to
+             a canonical name before checking the key, because someone with
+             access to the name servers would then be able to fool host au-
+             thentication.
+
+     /etc/ssh/ssh_config
+             Systemwide configuration file.  The file format and configuration
+             options are described in ssh_config(5).
+
+     /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 and
+             are used for RhostsRSAAuthentication and HostbasedAuthentication.
+             If the protocol version 1 RhostsRSAAuthentication method is used,
+             ssh must be setuid root, since the host key is readable only by
+             root.  For protocol version 2, ssh uses ssh-keysign(8) to access
+             the host keys for HostbasedAuthentication.  This eliminates the
+             requirement that ssh be setuid root when that authentication
+             method is used.  By default ssh is not setuid root.
+
+     ~/.rhosts
+             This file is used in RhostsRSAAuthentication and
+             HostbasedAuthentication authentication to list the host/user
+             pairs that are permitted to log in.  (Note that this file is also
+             used by rlogin and rsh, which makes using this file insecure.)
+             Each line of the file contains a host name (in the canonical form
+             returned by name servers), and then a user name on that host,
+             separated by a space.  On some machines this file may need to be
+             world-readable if the user's home directory is on a NFS parti-
+             tion, because sshd(8) 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.
+
+             Note that sshd(8) allows authentication only in combination with
+             client host key authentication before permitting log in.  If the
+             server machine does not have the client's host key in
+             /etc/ssh/ssh_known_hosts, it can be stored in ~/.ssh/known_hosts.
+             The easiest way to do this is to connect back to the client from
+             the server machine using ssh; this will automatically add the
+             host key to ~/.ssh/known_hosts.
+
+     ~/.shosts
+             This file is used exactly the same way as .rhosts.  The purpose
+             for having this file is to be able to use RhostsRSAAuthentication
+             and HostbasedAuthentication authentication without permitting lo-
+             gin with rlogin or rsh(1).
+
+     /etc/hosts.equiv
+             This file is used during RhostsRSAAuthentication and
+             HostbasedAuthentication authentication.  It contains canonical
+             hosts names, one per line (the full format is described in the
+             sshd(8) manual page).  If the client host is found in this file,
+             login is automatically permitted provided client and server user
+             names are the same.  Additionally, successful client host key au-
+             thentication is required.  This file should only be writable by
+             root.
+
+     /etc/shosts.equiv
+             This file is processed exactly as /etc/hosts.equiv.  This file
+             may be useful to permit logins using ssh but not using
+             rsh/rlogin.
+
+     /etc/ssh/sshrc
+             Commands in this file are executed by ssh when the user logs in
+             just before the user's shell (or command) is started.  See the
+             sshd(8) manual page for more information.
+
+     ~/.ssh/rc
+             Commands in this file are executed by ssh when the user logs in
+             just before the user's shell (or command) is started.  See the
+             sshd(8) manual page for more information.
+
+     ~/.ssh/environment
+             Contains additional definitions for environment variables, see
+             section ENVIRONMENT above.
+
+DIAGNOSTICS
+     ssh exits with the exit status of the remote command or with 255 if an
+     error occurred.
+
+SEE ALSO
+     gzip(1), rsh(1), scp(1), sftp(1), ssh-add(1), ssh-agent(1),
+     ssh-keygen(1), telnet(1), hosts.equiv(5), ssh_config(5), ssh-keysign(8),
+     sshd(8)
+
+     T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH
+     Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January
+     2002, work in progress material.
+
+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.
+
+OpenBSD 3.8                   September 25, 1999                            12