are used.  This has  the  advantage  that  a  single
       trusted certification authority can be used in place of many public/pri‐
       vate  keys.   See the CERTIFICATES section of ssh‐keygen(1) for more in‐
       formation.

       The most convenient way to use public key or certificate  authentication
       may  be with an authentication agent.  See ssh‐agent(1) and (optionally)
       the AddKeysToAgent directive in ssh_config(5) for more information.

       Keyboard‐interactive authentication works as follows: The  server  sends
       an  arbitrary "challenge" text and prompts for a response, possibly mul‐
       tiple times.  Examples of  keyboard‐interactive  authentication  include
       BSD  Authentication  (see  login.conf(5)) and PAM (some non‐OpenBSD sys‐
       tems).

       Finally, if other authentication methods fail, ssh prompts the user  for
       a  password.  The password is sent to the remote host for checking; how‐
       ever, since all communications are encrypted,  the  password  cannot  be
       seen by someone listening on the network.

       ssh automatically maintains and checks a database containing identifica‐
       tion  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 server spoofing  or  man‐in‐the‐middle  attacks,
       which  could  otherwise  be  used  to  circumvent  the  encryption.  The
       StrictHostKeyChecking option can be used to control logins  to  machines
       whose host key is not known or has changed.

       When the user’s identity has been accepted by the server, the server ei‐
       ther  executes  the given command in a non‐interactive session or, if no
       command has been specified, logs into the machine and gives the  user  a
       normal  shell as an interactive session.  All communication with the re‐
       mote command or shell will be automatically encrypted.

       If an interactive session is requested, ssh by default will only request
       a pseudo‐terminal (pty) for interactive sessions  when  the  client  has
       one.  The flags -T and -t can be used to override this behaviour.

       If  a  pseudo‐terminal  has  been allocated, the user may use the escape
       characters noted below.

       If no pseudo‐terminal 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 connections have been closed.

ESCAPE CHARACTERS
       When  a  pseudo‐terminal  has  been  requested, ssh supports a number of
       functions 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 char‐
       acter can be changed in configuration files using the EscapeChar config‐
       uration 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 if the peer  sup‐
               ports it).