packages icon
 (SSH client) is a program  for  logging  into  a  remote  machine  and  for
 executing  commands  on a remote machine.  It is intended to provide secure
 encrypted communications between  two  untrusted  hosts  over  an  insecure
 network.   X11  connections,  arbitrary  TCP  ports and sockets can also be
 forwarded over the secure channel.  connects and logs  into  the  specified
 which  may  be specified as either or a URI of the form The user must prove
 his/her identity to the remote machine using one of  several  methods  (see
 below).   If a is specified, it is executed on the remote host instead of a
 login shell.  The options are as follows:  Forces  to  use  IPv4  addresses
 only.   Forces  to  use  IPv6  addresses  only.   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  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.    Disables
 forwarding  of the authentication agent connection.  Bind to the address of
 before attempting to connect to the destination host.  This is only  useful
 on  systems  with  more  than one address.  Use on the local machine as the
 source address of the connection.  Only useful on systems  with  more  than
 one  address.   Requests  compression of all data (including stdin, stdout,
 stderr, and data for forwarded X11, TCP and connections).  The  compression
 algorithm  is  the same used by 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 option.  Selects the cipher specification for encrypting the
 session.   is  a  comma-separated  list  of  ciphers  listed  in  order  of
 preference.  See the keyword in for more information.   Specifies  a  local
 application-level  port  forwarding.   This works by allocating a socket to
 listen to on the local side, optionally bound to the specified  Whenever  a
 connection  is  made  to  this  port,  the connection 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 will act as a SOCKS server.  Only  root
 can  forward  privileged  ports.   Dynamic  port  forwardings  can  also be
 specified in the configuration file.  IPv6 addresses can  be  specified  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  setting.  However, an explicit may be used to bind the connection to a
 specific address.  The of indicates that the listening port  be  bound  for
 local use only, while an empty address or indicates that the port should be
 available from all interfaces.  Append debug logs to  instead  of  standard
 error.   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 disables any escapes and makes the session
 fully transparent.  Specifies an alternative per-user  configuration  file.
 If  a  configuration  file  is  given  on the command line, the system-wide
 configuration  file  will  be  ignored.   The  default  for  the   per-user
 configuration  file  is  Requests  to  go to background just before command
 execution.  This is useful if is going to ask for passwords or passphrases,
 but  the user wants it in the background.  This implies The recommended way
 to start X11 programs at a remote  site  is  with  something  like  If  the
 configuration option is set to then a client started with will wait for all
 remote port forwards to be successfully established before  placing  itself
 in  the background.  Causes to print its configuration after evaluating and
 blocks and exit.  Allows remote hosts to connect to local forwarded  ports.
 If  used on a multiplexed connection, then this option must be specified on
 the master process.  Specify the  PKCS#11  shared  library  should  use  to
 communicate  with  a  PKCS#11  token  providing the user's private RSA key.
 Selects a file from  which  the  identity  (private  key)  for  public  key
 authentication  is  read.   The  default  is and Identity files may also be
 specified on a per-host basis in the configuration file.  It is possible to
 have  multiple  options (and multiple identities specified in configuration
 files).   If  no  certificates  have  been  explicitly  specified  by   the
 directive,  will also try to load certificate information from the filename
 obtained by appending to identity filenames.  Connect to the target host by
 first  making  a  connection  to  the  jump  host  described  by  and  then
 establishing a TCP forwarding  to  the  ultimate  destination  from  there.
 Multiple jump hops may be specified separated by comma characters.  This is
 a shortcut to specify  a  configuration  directive.   Enables  GSSAPI-based
 authentication  and  forwarding  (delegation)  of GSSAPI credentials to the
 server.  Disables forwarding (delegation)  of  GSSAPI  credentials  to  the
 server.  Specifies that connections to the given TCP port or Unix socket on
 the local (client) host are to be forwarded to the given host and port,  or
 Unix  socket,  on  the  remote  side.  This works by allocating a socket to
 listen to either a TCP on the local side, optionally bound to the specified
 or  to  a  Unix socket.  Whenever a connection is made to the local port or
 socket, the  connection  is  forwarded  over  the  secure  channel,  and  a
 connection  is  made  to  either  port  or  the Unix socket from the remote
 machine.  Port forwardings can also be specified in the configuration file.
 Only  the  superuser  can  forward privileged ports.  IPv6 addresses can be
 specified by enclosing the address in square  brackets.   By  default,  the
 local  port  is bound in accordance with the setting.  However, an explicit
 may be used to bind the connection to a specific address.  The of indicates
 that the listening port be bound for local use only, while an empty address
 or indicates that  the  port  should  be  available  from  all  interfaces.
 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.  Places the client
 into  mode  for connection sharing.  Multiple options places into mode with
 confirmation required before slave connections are accepted.  Refer to  the
 description  of  in  for  details.   A comma-separated list of MAC (message
 authentication code) algorithms, specified in order of preference.  See the
 keyword  for  more  information.  Do not execute a remote command.  This is
 useful for just forwarding ports.  Redirects stdin from (actually, prevents
 reading  from  stdin).  This must be used when is run in the background.  A
 common trick is to use this to run X11 programs on a remote  machine.   For
 example,  will  start an emacs on shadows.cs.hut.fi, and the X11 connection
 will be automatically forwarded over an  encrypted  channel.   The  program
 will  be  put in the background.  (This does not work if needs to ask for a
 password or passphrase; see also the option.) Control an active  connection
 multiplexing master process.  When the option is specified, the argument is
 interpreted and passed to the master process.  Valid commands  are:  (check
 that  the  master process is running), (request forwardings without command
 execution),  (cancel  forwardings),  (request  the  master  to  exit),  and
 (request  the master to stop accepting further multiplexing requests).  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  listed  below,  and  their
 possible  values,  see  Port to connect to on the remote host.  This can be
 specified on a per-host basis in the configuration file.  Queries  for  the
 algorithms  supported  for the specified version 2.  The available features
 are: (supported  symmetric  ciphers),  (supported  symmetric  ciphers  that
 support  authenticated  encryption),  (supported  message integrity codes),
 (key exchange algorithms), (key  types),  (certificate  key  types),  (non-
 certificate key types), and (supported SSH protocol versions).  Quiet mode.
 Causes most warning and diagnostic messages to  be  suppressed.   Specifies
 that  connections  to  the  given  TCP  port  or  Unix socket on the remote
 (server) host are to be  forwarded  to  the  local  side.   This  works  by
 allocating  a  socket  to listen to either a TCP or to a Unix socket on the
 remote side.  Whenever a connection is made to this port  or  Unix  socket,
 the  connection  is  forwarded over the secure channel, and a connection is
 made from the local machine to either an explicit destination specified  by
 port  or  or, if no explicit destination was specified, will act as a SOCKS
 4/5 proxy and forward connections to  the  destinations  requested  by  the
 remote  SOCKS  client.   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  brackets.   By  default,  TCP  listening
 sockets  on  the server will be bound to the loopback interface only.  This
 may be overridden by specifying a An empty or the  address  indicates  that
 the  remote  socket  should  listen on all interfaces.  Specifying a remote
 will only succeed if the server's option is enabled (see If the argument is
 the listen port will be dynamically allocated on the server and reported to
 the client at run time.  When used together with the allocated port will be
 printed to the standard output.  Specifies the location of a control socket
 for connection sharing, or the string to disable connection sharing.  Refer
 to  the  description  of  and  in  for  details.   May  be  used to request
 invocation of a subsystem on the remote system.  Subsystems facilitate  the
 use of SSH as a secure transport for other applications (e.g. The subsystem
 is specified as the remote command.   Disable  pseudo-terminal  allocation.
 Force  pseudo-terminal  allocation.   This can be used to execute arbitrary
 screen-based programs on a remote machine, which can be very  useful,  e.g.
 when  implementing  menu  services.  Multiple options force tty allocation,
 even if has no local tty.  Display the version number  and  exit.   Verbose
 mode.   Causes  to  print  debugging  messages about its progress.  This is
 helpful  in  debugging  connection,   authentication,   and   configuration
 problems.   Multiple  options  increase  the  verbosity.  The maximum is 3.
 Requests that standard input and output on the client be  forwarded  to  on
 over the secure channel.  Implies and though these can be overridden in the
 configuration file or using command line options.  Requests  tunnel  device
 forwarding with the specified devices between the client and the server The
 devices may be specified by numerical ID or the keyword which uses the next
 available  tunnel device.  If is not specified, it defaults to See also the
 and directives in If the directive is unset, it will be set to the  default
 tunnel  mode,  which  is If a different forwarding mode it desired, then it
 should be specified before  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
 extension  restrictions  by  default.   Please  refer to the option and the
 directive in for  more  information.   Disables  X11  forwarding.   Enables
 trusted  X11  forwarding.  Trusted X11 forwardings are not subjected to the
 X11 SECURITY extension controls.  Send log  information  using  the  system
 module.   By  default this information is sent to stderr.  may additionally
 obtain configuration data from a per-user configuration file and a  system-
 wide  configuration  file.   The  file format and configuration options are
 described in The OpenSSH SSH client supports SSH protocol 2.   The  methods
 available  for  authentication are: GSSAPI-based authentication, host-based
 authentication,    public    key     authentication,     challenge-response
 authentication,  and  password  authentication.  Authentication methods are
 tried in the order specified above,  though  can  be  used  to  change  the
 default  order.  Host-based authentication works as follows: If the machine
 the user logs in from is listed in or on the remote machine, and  the  user
 names  are  the  same on both sides, or if the files or 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 login.  Additionally, the  server  be  able  to  verify  the
 client's  host  key  (see  the  description  of  and below) for login to be
 permitted.  This authentication method closes  security  holes  due  to  IP
 spoofing,  DNS spoofing, and routing spoofing.  [Note to the administrator:
 and the rlogin/rsh protocol in general, are inherently insecure and  should
 be  disabled  if  security  is desired.] Public key authentication works as
 follows:  The  scheme  is   based   on   public-key   cryptography,   using
 cryptosystems where encryption and decryption are done using separate keys,
 and it is unfeasible to derive the decryption key from the encryption  key.
 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.  implements public key authentication protocol
 automatically, using one of the DSA, ECDSA, Ed25519 or RSA algorithms.  The
 HISTORY  section  of  contains  a  brief  discussion  of  the  DSA  and RSA
 algorithms.  The file lists the public keys that are permitted for  logging
 in.   When the user logs in, the program tells the server which key pair it
 would like to use for authentication.  The client proves that it has access
 to  the private key and the server checks that the corresponding public key
 is authorized to accept the account.  The server may inform the  client  of
 errors  that  prevented  public  key  authentication  from succeeding after
 authentication completes using a different method.  These may be viewed  by
 increasing  the  to  or  higher (e.g. by using the flag).  The user creates
 his/her key pair by running This stores the private key in (DSA),  (ECDSA),
 (Ed25519), or (RSA) and stores the public key in (DSA), (ECDSA), (Ed25519),
 or (RSA) in the user's home directory.   The  user  should  then  copy  the
 public  key  to  in his/her home directory on the remote machine.  The file
 corresponds to the conventional 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.  A variation on public key authentication  is  available  in  the
 form  of  certificate  authentication:  instead  of a set of public/private
 keys, signed certificates are used.  This has the advantage that  a  single
 trusted certification authority can be used in place of many public/private
 keys.  See the CERTIFICATES section of  for  more  information.   The  most
 convenient  way to use public key or certificate authentication may be with
 an authentication agent.  See and (optionally) the directive  in  for  more
 information.   Challenge-response  authentication  works  as  follows:  The
 server sends an arbitrary text, and prompts for a  response.   Examples  of
 challenge-response authentication include Authentication (see and PAM (some
 systems).  Finally, if other authentication methods fail, 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.  automatically maintains and
 checks a database containing identification for all hosts it has ever  been
 used  with.   Host  keys  are  stored  in  in  the  user's  home directory.
 Additionally, the file is automatically checked for known hosts.   Any  new
 hosts   are   automatically   added  to  the  user's  file.   If  a  host's
 identification  ever  changes,  warns  about  this  and  disables  password
 authentication  to  prevent  server  spoofing or man-in-the-middle attacks,
 which could otherwise be used to circumvent the encryption.  The 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  either  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
 remote command or shell will be automatically encrypted.  If an interactive
 session  is  requested by default will only request a pseudo-terminal (pty)
 for interactive sessions when the client has one.  The  flags  and  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
 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.  When a pseudo-terminal has been
 requested, 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  character  can  be  changed  in  configuration  files   using   the
 configuration  directive  or  on  the  command  line  by  the  option.  The
 supported escapes (assuming the default are: Disconnect.   Background  List
 forwarded  connections.   Background  at  logout when waiting for forwarded
 connection  /  X11  sessions  to  terminate.   Display  a  list  of  escape
 characters.   Send  a  BREAK  to the remote system (only useful if the peer
 supports it).  Open command line.  Currently this allows  the  addition  of
 port  forwardings  using  the  and options (see above).  It also allows the
 cancellation of existing port-forwardings with for local,  for  remote  and
 for  dynamic  port-forwardings.  allows the user to execute a local command
 if the option is enabled in Basic help  is  available,  using  the  option.
 Request  rekeying  of the connection (only useful if the peer supports it).
 Decrease the verbosity when errors are being written to  stderr.   Increase
 the  verbosity  when  errors  are  being  written to stderr.  Forwarding of
 arbitrary TCP connections over the secure channel can be  specified  either
 on  the  command line or in a configuration file.  One possible application
 of TCP forwarding is a secure connection to a mail server; another is going
 through   firewalls.    In   the  example  below,  we  look  at  encrypting
 communication between an IRC client and server, even though the IRC  server
 does not directly support encrypted communications.  This works as follows:
 the user connects to the remote host using specifying a port to be used  to
 forward  connections  to  the  remote server.  After that it is possible to
 start the  service  which  is  to  be  encrypted  on  the  client  machine,
 connecting  to  the  same  local  port,  and  will  encrypt and forward the
 connection.  The following example  tunnels  an  IRC  session  from  client
 machine  (localhost)  to  remote  server  $  ssh  -f -L 1234:localhost:6667
 server.example.com sleep 10 $ irc -c '#users' -p 1234 pinky 127.0.0.1  This
 tunnels  a  connection  to  IRC  server joining channel nickname using port
 1234.  It doesn't matter which port is used, as long as it's  greater  than
 1023 (remember, only root can open sockets on privileged ports) and doesn't
 conflict with any ports already in use.  The  connection  is  forwarded  to
 port  6667  on  the  remote  server, since that's the standard port for IRC
 services.  The option backgrounds and the remote command  is  specified  to
 allow  an  amount of time (10 seconds, in the example) to start the service
 which is to be tunnelled.  If no  connections  are  made  within  the  time
 specified, will exit.  If the variable is set to (or see the description of
 the and options above) and the user is using X11 (the 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 encrypted channel, and the connection to
 the real X server will be made from the local machine.  The user should not
 manually set Forwarding of X11 connections can be configured on the command
 line or in configuration files.  The value set by will point to the  server
 machine,  but with a display number greater than zero.  This is normal, and
 happens because creates a X server on the server machine for forwarding the
 connections  over  the  encrypted  channel.  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  variable  is  set  to (or see the description of the and
 options  above)  and  the  user  is  using  an  authentication  agent,  the
 connection  to  the  agent  is  automatically forwarded to the remote side.
 When connecting to a server for  the  first  time,  a  fingerprint  of  the
 server's  public  key  is presented to the user (unless the option has been
 disabled).  Fingerprints can be determined  using  If  the  fingerprint  is
 already  known,  it can be matched and the key can be accepted or rejected.
 If only legacy (MD5) fingerprints for the server are available, the  option
 may  be  used  to downgrade the fingerprint algorithm to match.  Because of
 the difficulty of comparing  host  keys  just  by  looking  at  fingerprint
 strings,  there  is  also  support  to compare host keys visually, using By
 setting the option to a small ASCII graphic gets displayed on  every  login
 to  a  server,  no  matter if the session itself is interactive or not.  By
 learning the pattern a known server produces, a user can  easily  find  out
 that  the  host  key  has  changed  when  a completely different pattern is
 displayed.  Because these patterns are not unambiguous however,  a  pattern
 that  looks similar to the pattern remembered only gives a good probability
 that the host key is the same, not guaranteed proof.  To get a  listing  of
 the  fingerprints  along  with  their  random  art for all known hosts, the
 following command line can be used:  If  the  fingerprint  is  unknown,  an
 alternative  method of verification is available: SSH fingerprints verified
 by DNS.  An additional resource record (RR), SSHFP, is added to a  zonefile
 and the connecting client is able to match the fingerprint with that of the
 key presented.  In this example, we are connecting a client  to  a  server,
 The  SSHFP  resource  records  should  first  be  added to the zonefile for
 host.example.com: $ ssh-keygen -r host.example.com.  The output lines  will
 have  to  be  added  to  the zonefile.  To check that the zone is answering
 fingerprint   queries:   Finally   the   client   connects:   $   ssh    -o
 "VerifyHostKeyDNS ask" host.example.com [...] Matching host key fingerprint
 found in DNS.  Are you sure you want to continue connecting (yes/no)?   See
 the  option  in for more information.  contains support for Virtual Private
 Network (VPN) tunnelling using  the  network  pseudo-device,  allowing  two
 networks  to be joined securely.  The configuration option controls whether
 the server supports this, and at what level (layer 2 or  3  traffic).   The
 following  example  would  connect  client network 10.0.50.0/24 with remote
 network 10.0.99.0/24 using a point-to-point  connection  from  10.1.1.1  to
 10.1.1.2, provided that the SSH server running on the gateway to the remote
 network, at 192.168.1.15, allows it.  On  the  client:  #  ssh  -f  -w  0:1
 192.168.1.15 true # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
 # route add 10.0.99.0/24 10.1.1.2 On the server: # ifconfig  tun1  10.1.1.2
 10.1.1.1  netmask  255.255.255.252 # route add 10.0.50.0/24 10.1.1.1 Client
 access may be more finely tuned via the file (see  below)  and  the  server
 option.  The following entry would permit connections on device 1 from user
 and on  tun  device  2  from  user  if  is  set  to  tunnel="1",command="sh
 /etc/netstart  tun1"  ssh-rsa ... jane tunnel="2",command="sh /etc/netstart
 tun2" ssh-rsa ... john Since an SSH-based setup entails a  fair  amount  of
 overhead,  it  may be more suited to temporary setups, such as for wireless
 VPNs.  More permanent VPNs are better provided by tools such  as  and  will
 normally  set  the  following environment variables: The variable indicates
 the location of the X11 server.  It is automatically set by to point  to  a
 value  of the form where indicates the host where the shell runs, and is an
 integer  1.  uses this special value to forward X11  connections  over  the
 secure  channel.  The user should normally not set explicitly, as that will
 render the X11 connection insecure (and will require the user  to  manually
 copy  any  required  authorization cookies).  Set to the path of the user's
 home directory.  Synonym for set for compatibility with  systems  that  use
 this  variable.  Set to the path of the user's mailbox.  Set to the default
 as specified when compiling  If  needs  a  passphrase,  it  will  read  the
 passphrase  from  the  current  terminal if it was run from a terminal.  If
 does not have a terminal associated with  it  but  and  are  set,  it  will
 execute  the  program  specified  by  and  open  an  X11 window to read the
 passphrase.  This is particularly useful when calling  from  a  or  related
 script.   (Note  that  on some machines it may be necessary to redirect the
 input from to make this work.) Identifies the path  of  a  socket  used  to
 communicate  with  the agent.  Identifies the client and server ends of the
 connection.  The variable contains four space-separated values:  client  IP
 address,  client  port  number,  server IP address, and server port number.
 This variable contains the original command line if  a  forced  command  is
 executed.   It  can be used to extract the original arguments.  This is set
 to the name of the tty (path to the device)  associated  with  the  current
 shell  or command.  If the current session has no tty, this variable is not
 set.  Optionally set by to contain the interface names assigned  if  tunnel
 forwarding  was  requested  by the client.  Optionally set by this variable
 may contain a pathname to a file  that  lists  the  authentication  methods
 successfully  used  when  the session was established, including any public
 keys that were used.  This variable is set to  indicate  the  present  time
 zone  if it was set when the daemon was started (i.e. the daemon passes the
 value on to new connections).  Set to the name  of  the  user  logging  in.
 Additionally,  reads and adds lines of the format to the environment if the
 file exists and users are allowed to change their  environment.   For  more
 information,   see   the  option  in  This  file  is  used  for  host-based
 authentication (see above).  On some machines this  file  may  need  to  be
 world-readable if the user's home directory is on an NFS partition, because
 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.   This file is used in exactly the same way as but allows host-
 based  authentication  without  permitting  login  with  rlogin/rsh.   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.   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  in  the  manual  page.
 This  file  is  not  highly  sensitive, but the recommended permissions are
 read/write for the user, and not accessible by others.  This  is  the  per-
 user  configuration  file.   The  file format and configuration options are
 described in Because of the potential for abuse, this file must have strict
 permissions: read/write for the user, and not writable by others.  Contains
 additional definitions for environment variables; see above.  Contains  the
 private  key  for  authentication.   These files contain sensitive data and
 should  be  readable  by  the   user   but   not   accessible   by   others
 (read/write/execute).   will  simply  ignore  a  private  key file if it is
 accessible by  others.   It  is  possible  to  specify  a  passphrase  when
 generating the key which will be used to encrypt the sensitive part of this
 file using AES-128.  Contains the public  key  for  authentication.   These
 files  are  not  sensitive  and  can  (but need not) be readable by anyone.
 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.  See for further
 details of the format of this file.  Commands in this file are executed  by
 when  the  user  logs  in,  just  before  the  user's shell (or command) is
 started.  See the manual page for  more  information.   This  file  is  for
 host-based authentication (see above).  It should only be writable by root.
 This file is used  in  exactly  the  same  way  as  but  allows  host-based
 authentication   without  permitting  login  with  rlogin/rsh.   Systemwide
 configuration  file.   The  file  format  and  configuration  options   are
 described in These files contain the private parts of the host keys and are
 used for host-based authentication.  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.  It should be  world-
 readable.  See for further details of the format of this file.  Commands in
 this file are executed by when the user logs in,  just  before  the  user's
 shell  (or  command) is started.  See the manual page for more information.
 exits with the exit status of the remote command or with 255  if  an  error
 occurred.   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.