-First, if the machine the user logs in from is listed in
-.Pa /etc/hosts.equiv
-or
-.Pa /etc/shosts.equiv
-on the remote machine, and the user names are
-the same on both sides, the user is immediately permitted to log in.
-Second, if
-.Pa \&.rhosts
-or
-.Pa \&.shosts
-exists in the user's home directory on the
-remote machine and contains a line containing the name of the client
-machine and the name of the user on that machine, the user is
-permitted to log in.
-This form of authentication alone is normally not
-allowed by the server because it is not secure.
-.Pp
-The second authentication method is the
-.Pa rhosts
-or
-.Pa hosts.equiv
-method combined with RSA-based host authentication.
-It means that if the login would be permitted by
-.Pa $HOME/.rhosts ,
-.Pa $HOME/.shosts ,
-.Pa /etc/hosts.equiv ,
-or
-.Pa /etc/shosts.equiv ,
-and if additionally the server can verify the client's
-host key (see
-.Pa /etc/ssh_known_hosts
-and
-.Pa $HOME/.ssh/known_hosts
-in the
-.Sx FILES
-section), only then login is permitted.
-This authentication method closes security holes due to IP
-spoofing, DNS spoofing and routing spoofing.
-[Note to the administrator:
-.Pa /etc/hosts.equiv ,
-.Pa $HOME/.rhosts ,
-and the rlogin/rsh protocol in general, are inherently insecure and should be
-disabled if security is desired.]
-.Pp
-As a third authentication method,
-.Nm
-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
-.Pa $HOME/.ssh/authorized_keys
-lists the public keys that are permitted for logging
-in.
-When the user logs in, the
-.Nm
-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
-.Nm
-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
-challenge using the private key, proving that he/she knows the private
-key but without disclosing it to the server.
-.Pp
-.Nm
-implements the RSA authentication protocol automatically.
-The user creates his/her RSA key pair by running
-.Xr ssh-keygen 1 .
-This stores the private key in
-.Pa $HOME/.ssh/identity
-and the public key in
-.Pa $HOME/.ssh/identity.pub
-in the user's home directory.
-The user should then copy the
-.Pa identity.pub
-to
-.Pa $HOME/.ssh/authorized_keys
-in his/her home directory on the remote machine (the
-.Pa authorized_keys
-file corresponds to the conventional
-.Pa $HOME/.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 password.
-RSA authentication is much
-more secure than rhosts authentication.
-.Pp
-The most convenient way to use RSA authentication may be with an
-authentication agent.
-See
-.Xr ssh-agent 1
-for more information.
-.Pp
-If other authentication methods fail,
-.Nm
-prompts the user for a password.
-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.
-.Pp
-.Ss SSH protocol version 2
-.Pp
-When a user connects using the protocol version 2
-different authentication methods are available.
-Using the default values for
-.Cm PreferredAuthentications ,
-the client will try to authenticate first using the public key method;
-if this method fails password authentication is attempted,
-and finally if this method fails keyboard-interactive authentication
-is attempted.
-If this method fails password authentication is
-tried.
-.Pp
-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,
-.Pa $HOME/.ssh/id_dsa
-or
-.Pa $HOME/.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
-.Pa $HOME/.ssh/authorized_keys2
-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.
-.Pp
-If public key authentication fails or is not available a password
-can be sent encrypted to the remote host for proving the user's identity.
-.Pp
-Additionally,
-.Nm
-supports hostbased or challenge response authentication.
-.Pp
-Protocol 2 provides additional mechanisms for confidentiality
-(the traffic is encrypted using 3DES, Blowfish, CAST128 or Arcfour)
-and integrity (hmac-md5, hmac-sha1).
-Note that protocol 1 lacks a strong mechanism for ensuring the
-integrity of the connection.
-.Pp
-.Ss Login session and remote execution
-.Pp
-When the user's identity has been accepted by the server, the server
-either 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.
-.Pp
-If a pseudo-terminal has been allocated (normal login session), the
-user may use the escape characters noted below.
-.Pp
-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
-.Dq none
-will also make the session transparent even if a tty is used.
-.Pp
-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 status of the remote program is returned as the exit status
-of
-.Nm ssh .
-.Pp
-.Ss Escape Characters
-.Pp
-When a pseudo terminal has been requested, ssh supports a number of functions
-through the use of an escape character.
-.Pp
-A single tilde character can be sent as
-.Ic ~~
-(or by following the tilde by a character other than those described above).
-The escape character must always follow a newline to be interpreted as
-special.
-The escape character can be changed in configuration files using the
-.Cm EscapeChar
-configuration directive or on the command line by the
-.Fl e
-option.
-.Pp
-The supported escapes (assuming the default
-.Ql ~ )
-are: