{
    "mode": "man",
    "parameter": "SSH_CONFIG",
    "section": "5",
    "url": "https://www.chedong.com/phpMan.php/man/SSH_CONFIG/5/json",
    "generated": "2026-11-08T00:25:09Z",
    "sections": {
        "NAME": {
            "content": "sshconfig — OpenSSH client configuration file\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "ssh(1) obtains configuration data from the following sources in the following order:\n\n1.   command-line options\n2.   user's configuration file (~/.ssh/config)\n3.   system-wide configuration file (/etc/ssh/sshconfig)\n\nUnless  noted otherwise, for each parameter, the first obtained value will be used.  The con‐\nfiguration files contain sections separated by Host specifications, and that section is  only\napplied  for  hosts  that  match one of the patterns given in the specification.  The matched\nhost name is usually the one given on the command line (see the  CanonicalizeHostname  option\nfor exceptions).\n\nSince  the  first  obtained value for each parameter is used, more host-specific declarations\nshould be given near the beginning of the file, and general defaults at the end.\n\nNote  that  the  Debian  openssh-client  package  sets  several  options   as   standard   in\n/etc/ssh/sshconfig which are not the default in ssh(1):\n\n•   Include /etc/ssh/sshconfig.d/*.conf\n•   SendEnv LANG LC*\n•   HashKnownHosts yes\n•   GSSAPIAuthentication yes\n\n/etc/ssh/sshconfig.d/*.conf files are included at the start of the system-wide configuration\nfile, so options set there will override those in /etc/ssh/sshconfig.\n\nThe  file  contains  keyword-argument pairs, one per line.  Lines starting with ‘#’ and empty\nlines are interpreted as comments.  Arguments may optionally be enclosed in double quotes (\")\nin order to represent arguments containing spaces.  Configuration options may be separated by\nwhitespace or optional whitespace and exactly one ‘=’; the latter format is useful  to  avoid\nthe  need  to  quote whitespace when specifying configuration options using the ssh, scp, and\nsftp -o option.\n\nThe possible keywords and their meanings are as follows (note that keywords are case-insensi‐\ntive and arguments are case-sensitive):\n\nHost    Restricts the following declarations (up to the next Host or  Match  keyword)  to  be\nonly for those hosts that match one of the patterns given after the keyword.  If more\nthan  one  pattern is provided, they should be separated by whitespace.  A single ‘*’\nas a pattern can be used to provide global defaults for all hosts.  The host is  usu‐\nally  the  hostname  argument given on the command line (see the CanonicalizeHostname\nkeyword for exceptions).\n\nA pattern entry may be negated by prefixing it with an exclamation mark (‘!’).  If  a\nnegated  entry  is matched, then the Host entry is ignored, regardless of whether any\nother patterns on the line match.  Negated matches are therefore  useful  to  provide\nexceptions for wildcard matches.\n\nSee “PATTERNS” for more information on patterns.\n\nMatch   Restricts  the  following  declarations  (up to the next Host or Match keyword) to be\nused only when the conditions following the Match keyword are satisfied.  Match  con‐\nditions are specified using one or more criteria or the single token all which always\nmatches.   The available criteria keywords are: canonical, final, exec, localnetwork,\nhost, originalhost, Tag, user, and localuser.  The all criteria must appear alone  or\nimmediately  after  canonical  or final.  Other criteria may be combined arbitrarily.\nAll criteria but all, canonical, and final require  an  argument.   Criteria  may  be\nnegated by prepending an exclamation mark (‘!’).\n\nThe canonical keyword matches only when the configuration file is being re-parsed af‐\nter  hostname  canonicalization  (see  the CanonicalizeHostname option).  This may be\nuseful to specify conditions that work with canonical host names only.\n\nThe final keyword requests that the configuration be re-parsed (regardless of whether\nCanonicalizeHostname is enabled), and  matches  only  during  this  final  pass.   If\nCanonicalizeHostname is enabled, then canonical and final match during the same pass.\n\nThe  exec keyword executes the specified command under the user's shell.  If the com‐\nmand returns a zero exit status then the condition is considered true.  Commands con‐\ntaining whitespace characters must be quoted.  Arguments to exec  accept  the  tokens\ndescribed in the “TOKENS” section.\n\nThe  localnetwork  keyword  matches  the addresses of active local network interfaces\nagainst the supplied list of networks in CIDR format.  This  may  be  convenient  for\nvarying the effective configuration on devices that roam between networks.  Note that\nnetwork  address is not a trustworthy criteria in many situations (e.g. when the net‐\nwork is automatically configured using DHCP) and so caution should be applied if  us‐\ning it to control security-sensitive configuration.\n\nThe  other keywords' criteria must be single entries or comma-separated lists and may\nuse the wildcard and negation operators described in  the  “PATTERNS”  section.   The\ncriteria for the host keyword are matched against the target hostname, after any sub‐\nstitution  by the Hostname or CanonicalizeHostname options.  The originalhost keyword\nmatches against the hostname as it was specified on  the  command-line.   The  tagged\nkeyword  matches  a tag name specified by a prior Tag directive or on the ssh(1) com‐\nmand-line using the -P flag.  The user keyword matches against the target username on\nthe remote host.  The localuser keyword matches against the name of  the  local  user\nrunning ssh(1) (this keyword may be useful in system-wide sshconfig files).\n",
            "subsections": [
                {
                    "name": "AddKeysToAgent",
                    "content": "Specifies  whether  keys should be automatically added to a running ssh-agent(1).  If\nthis option is set to yes and a key is loaded from a file, the key and its passphrase\nare added to the agent with the default lifetime, as if by ssh-add(1).  If  this  op‐\ntion  is  set  to ask, ssh(1) will require confirmation using the SSHASKPASS program\nbefore adding a key (see ssh-add(1) for details).  If this option is set to  confirm,\neach  use  of  the  key  must  be  confirmed,  as  if  the -c option was specified to\nssh-add(1).  If this option is set to no, no keys are added  to  the  agent.   Alter‐\nnately, this option may be specified as a time interval using the format described in\nthe  “TIME  FORMATS”  section  of  sshdconfig(5)  to  specify  the key's lifetime in\nssh-agent(1), after which it will automatically be removed.  The argument must be  no\n(the  default),  yes, confirm (optionally followed by a time interval), ask or a time\ninterval.\n"
                },
                {
                    "name": "AddressFamily",
                    "content": "Specifies which address family to use when connecting.  Valid arguments are any  (the\ndefault), inet (use IPv4 only), or inet6 (use IPv6 only).\n"
                },
                {
                    "name": "BatchMode",
                    "content": "If  set  to  yes, user interaction such as password prompts and host key confirmation\nrequests will be disabled.  In addition, the ServerAliveInterval option will  be  set\nto  300  seconds  by default (Debian-specific).  This option is useful in scripts and\nother batch jobs where no user is present to interact with ssh(1), and  where  it  is\ndesirable  to  detect  a broken network swiftly.  The argument must be yes or no (the\ndefault).\n"
                },
                {
                    "name": "BindAddress",
                    "content": "Use the specified address on the local machine as the source address of  the  connec‐\ntion.  Only useful on systems with more than one address.\n"
                },
                {
                    "name": "BindInterface",
                    "content": "Use the address of the specified interface on the local machine as the source address\nof the connection.\n"
                },
                {
                    "name": "CanonicalDomains",
                    "content": "When  CanonicalizeHostname  is enabled, this option specifies the list of domain suf‐\nfixes in which to search for the specified destination host.\n"
                },
                {
                    "name": "CanonicalizeFallbackLocal",
                    "content": "Specifies whether to fail with an error when hostname  canonicalization  fails.   The\ndefault,  yes,  will attempt to look up the unqualified hostname using the system re‐\nsolver's search rules.  A value  of  no  will  cause  ssh(1)  to  fail  instantly  if\nCanonicalizeHostname is enabled and the target hostname cannot be found in any of the\ndomains specified by CanonicalDomains.\n"
                },
                {
                    "name": "CanonicalizeHostname",
                    "content": "Controls  whether  explicit hostname canonicalization is performed.  The default, no,\nis not to perform any name rewriting and let the system resolver handle all  hostname\nlookups.   If  set  to  yes  then,  for connections that do not use a ProxyCommand or\nProxyJump, ssh(1) will attempt to canonicalize the hostname specified on the  command\nline  using  the CanonicalDomains suffixes and CanonicalizePermittedCNAMEs rules.  If\nCanonicalizeHostname is set to always, then canonicalization is  applied  to  proxied\nconnections too.\n\nIf this option is enabled, then the configuration files are processed again using the\nnew  target name to pick up any new configuration in matching Host and Match stanzas.\nA value of none disables the use of a ProxyJump host.\n"
                },
                {
                    "name": "CanonicalizeMaxDots",
                    "content": "Specifies the maximum number of dot characters in a hostname before  canonicalization\nis disabled.  The default, 1, allows a single dot (i.e. hostname.subdomain).\n"
                },
                {
                    "name": "CanonicalizePermittedCNAMEs",
                    "content": "Specifies  rules  to  determine whether CNAMEs should be followed when canonicalizing\nhostnames.     The    rules    consist    of    one    or    more    arguments     of\nsourcedomainlist:targetdomainlist,  where sourcedomainlist is a pattern-list of\ndomains that may follow CNAMEs in canonicalization, and targetdomainlist is a  pat‐\ntern-list of domains that they may resolve to.\n\nFor  example,  \"*.a.example.com:*.b.example.com,*.c.example.com\" will allow hostnames\nmatching \"*.a.example.com\" to be canonicalized to names in the  \"*.b.example.com\"  or\n\"*.c.example.com\" domains.\n\nA  single  argument of \"none\" causes no CNAMEs to be considered for canonicalization.\nThis is the default behaviour.\n"
                },
                {
                    "name": "CASignatureAlgorithms",
                    "content": "Specifies which algorithms are allowed for signing of certificates by certificate au‐\nthorities (CAs).  The default is:\n\nssh-ed25519,ecdsa-sha2-nistp256,\necdsa-sha2-nistp384,ecdsa-sha2-nistp521,\nsk-ssh-ed25519@openssh.com,\nsk-ecdsa-sha2-nistp256@openssh.com,\nrsa-sha2-512,rsa-sha2-256\n\nIf the specified list begins with a ‘+’ character, then the specified algorithms will\nbe appended to the default set instead of replacing them.  If the specified list  be‐\ngins  with  a ‘-’ character, then the specified algorithms (including wildcards) will\nbe removed from the default set instead of replacing them.\n\nssh(1) will not accept host certificates signed using  algorithms  other  than  those\nspecified.\n"
                },
                {
                    "name": "CertificateFile",
                    "content": "Specifies  a file from which the user's certificate is read.  A corresponding private\nkey must be provided separately in order to  use  this  certificate  either  from  an\nIdentityFile   directive   or   -i  flag  to  ssh(1),  via  ssh-agent(1),  or  via  a\nPKCS11Provider or SecurityKeyProvider.\n\nArguments to CertificateFile may use the tilde syntax to refer to a user's  home  di‐\nrectory,  the  tokens  described in the “TOKENS” section and environment variables as\ndescribed in the “ENVIRONMENT VARIABLES” section.\n\nIt is possible to have multiple certificate files specified in  configuration  files;\nthese  certificates  will  be tried in sequence.  Multiple CertificateFile directives\nwill add to the list of certificates used for authentication.\n"
                },
                {
                    "name": "ChannelTimeout",
                    "content": "Specifies whether and how quickly ssh(1) should close  inactive  channels.   Timeouts\nare specified as one or more “type=interval” pairs separated by whitespace, where the\n“type” must be a channel type name (as described in the table below), optionally con‐\ntaining wildcard characters.\n\nThe timeout value “interval” is specified in seconds or may use any of the units doc‐\numented in the “TIME FORMATS” section.  For example, “session=5m” would cause the in‐\nteractive  session  to terminate after five minutes of inactivity.  Specifying a zero\nvalue disables the inactivity timeout.\n\nThe available channel types include:\n\nagent-connection\nOpen connections to ssh-agent(1).\n\ndirect-tcpip, direct-streamlocal@openssh.com\nOpen TCP or Unix socket (respectively) connections that have been established\nfrom a ssh(1) local forwarding, i.e. LocalForward or DynamicForward.\n\nforwarded-tcpip, forwarded-streamlocal@openssh.com\nOpen TCP or Unix socket (respectively) connections that have been established\nto a sshd(8)  listening  on  behalf  of  a  ssh(1)  remote  forwarding,  i.e.\nRemoteForward.\n\nsession\nThe  interactive  main  session,  including shell session, command execution,\nscp(1), sftp(1), etc.\n\ntun-connection\nOpen TunnelForward connections.\n\nx11-connection\nOpen X11 forwarding sessions.\n\nNote that in all the above cases, terminating an inactive session does not  guarantee\nto  remove  all  resources  associated  with the session, e.g. shell processes or X11\nclients relating to the session may continue to execute.\n\nMoreover, terminating an inactive channel or session does not necessarily  close  the\nSSH  connection,  nor does it prevent a client from requesting another channel of the\nsame type.  In particular, expiring an inactive forwarding session does  not  prevent\nanother identical forwarding from being subsequently created.\n\nThe default is not to expire channels of any type for inactivity.\n"
                },
                {
                    "name": "CheckHostIP",
                    "content": "If  set to yes, ssh(1) will additionally check the host IP address in the knownhosts\nfile.  This allows it to detect if a host key changed due to DNS  spoofing  and  will\nadd  addresses  of destination hosts to ~/.ssh/knownhosts in the process, regardless\nof the setting of StrictHostKeyChecking.  If the option is set to no  (the  default),\nthe check will not be executed.\n"
                },
                {
                    "name": "Ciphers",
                    "content": "Specifies  the  ciphers allowed and their order of preference.  Multiple ciphers must\nbe comma-separated.  If the specified list begins with  a  ‘+’  character,  then  the\nspecified  ciphers will be appended to the default set instead of replacing them.  If\nthe specified list begins with a ‘-’ character, then the specified ciphers (including\nwildcards) will be removed from the default set instead of replacing  them.   If  the\nspecified list begins with a ‘^’ character, then the specified ciphers will be placed\nat the head of the default set.\n\nThe supported ciphers are:\n\n3des-cbc\naes128-cbc\naes192-cbc\naes256-cbc\naes128-ctr\naes192-ctr\naes256-ctr\naes128-gcm@openssh.com\naes256-gcm@openssh.com\nchacha20-poly1305@openssh.com\n\nThe default is:\n\nchacha20-poly1305@openssh.com,\naes128-ctr,aes192-ctr,aes256-ctr,\naes128-gcm@openssh.com,aes256-gcm@openssh.com\n\nThe list of available ciphers may also be obtained using \"ssh -Q cipher\".\n"
                },
                {
                    "name": "ClearAllForwardings",
                    "content": "Specifies  that all local, remote, and dynamic port forwardings specified in the con‐\nfiguration files or on the command line be cleared.  This option is primarily  useful\nwhen used from the ssh(1) command line to clear port forwardings set in configuration\nfiles,  and  is automatically set by scp(1) and sftp(1).  The argument must be yes or\nno (the default).\n"
                },
                {
                    "name": "Compression",
                    "content": "Specifies whether to use compression.  The argument must be yes or no (the default).\n"
                },
                {
                    "name": "ConnectionAttempts",
                    "content": "Specifies the number of tries (one per second) to make before exiting.  The  argument\nmust be an integer.  This may be useful in scripts if the connection sometimes fails.\nThe default is 1.\n"
                },
                {
                    "name": "ConnectTimeout",
                    "content": "Specifies the timeout (in seconds) used when connecting to the SSH server, instead of\nusing  the  default system TCP timeout.  This timeout is applied both to establishing\nthe connection and to performing the initial SSH protocol handshake and key exchange.\n"
                },
                {
                    "name": "ControlMaster",
                    "content": "Enables the sharing of multiple sessions over a single network connection.  When  set\nto  yes,  ssh(1)  will listen for connections on a control socket specified using the\nControlPath argument.  Additional sessions can connect to this socket using the  same\nControlPath  with  ControlMaster set to no (the default).  These sessions will try to\nreuse the master instance's network connection rather than initiating new  ones,  but\nwill fall back to connecting normally if the control socket does not exist, or is not\nlistening.\n\nSetting  this to ask will cause ssh(1) to listen for control connections, but require\nconfirmation using ssh-askpass(1).  If the ControlPath cannot be opened, ssh(1)  will\ncontinue without connecting to a master instance.\n\nX11 and ssh-agent(1) forwarding is supported over these multiplexed connections, how‐\never  the display and agent forwarded will be the one belonging to the master connec‐\ntion i.e. it is not possible to forward multiple displays or agents.\n\nTwo additional options allow for opportunistic multiplexing: try to use a master con‐\nnection but fall back to creating a new one if one does not already exist.  These op‐\ntions are: auto and autoask.  The latter requires confirmation like the ask option.\n"
                },
                {
                    "name": "ControlPath",
                    "content": "Specify the path to the control socket used for connection sharing  as  described  in\nthe  ControlMaster  section  above  or the string none to disable connection sharing.\nArguments to ControlPath may use the tilde syntax to refer to a  user's  home  direc‐\ntory,  the  tokens described in the “TOKENS” section and environment variables as de‐\nscribed  in  the  “ENVIRONMENT  VARIABLES”  section.   It  is  recommended  that  any\nControlPath used for opportunistic connection sharing include at least %h, %p, and %r\n(or  alternatively  %C)  and  be  placed in a directory that is not writable by other\nusers.  This ensures that shared connections are uniquely identified.\n"
                },
                {
                    "name": "ControlPersist",
                    "content": "When used in conjunction with ControlMaster, specifies  that  the  master  connection\nshould  remain  open  in the background (waiting for future client connections) after\nthe initial client connection has been closed.  If set to no (the default), then  the\nmaster  connection  will not be placed into the background, and will close as soon as\nthe initial client connection is closed.  If set to yes or 0, then the master connec‐\ntion will remain in the background indefinitely (until killed or closed via a  mecha‐\nnism  such  as  the \"ssh -O exit\").  If set to a time in seconds, or a time in any of\nthe formats documented in sshdconfig(5), then  the  backgrounded  master  connection\nwill  automatically terminate after it has remained idle (with no client connections)\nfor the specified time.\n"
                },
                {
                    "name": "DynamicForward",
                    "content": "Specifies that a TCP port on the local machine be forwarded over the secure  channel,\nand  the  application protocol is then used to determine where to connect to from the\nremote machine.\n\nThe argument must be [bindaddress:]port.  IPv6 addresses can be specified by enclos‐\ning addresses in square brackets.  By default, the local port is bound in  accordance\nwith the GatewayPorts setting.  However, an explicit bindaddress may be used to bind\nthe  connection  to a specific address.  The bindaddress of localhost indicates that\nthe listening port be bound for local use only, while an empty address or  ‘*’  indi‐\ncates that the port should be available from all interfaces.\n\nCurrently  the  SOCKS4  and  SOCKS5 protocols are supported, and ssh(1) will act as a\nSOCKS server.  Multiple forwardings may be specified, and additional forwardings  can\nbe given on the command line.  Only the superuser can forward privileged ports.\n"
                },
                {
                    "name": "EnableEscapeCommandline",
                    "content": "Enables  the command line option in the EscapeChar menu for interactive sessions (de‐\nfault ‘~C’).  By default, the command line is disabled.\n"
                },
                {
                    "name": "EnableSSHKeysign",
                    "content": "Setting  this   option   to   yes   in   the   global   client   configuration   file\n/etc/ssh/sshconfig  enables  the  use  of  the  helper program ssh-keysign(8) during\nHostbasedAuthentication.  The argument must be yes or no (the default).  This  option\nshould be placed in the non-hostspecific section.  See ssh-keysign(8) for more infor‐\nmation.\n"
                },
                {
                    "name": "EscapeChar",
                    "content": "Sets  the  escape  character (default: ‘~’).  The escape character can also be set on\nthe command line.  The argument should be a single character, ‘^’ followed by a  let‐\nter,  or  none to disable the escape character entirely (making the connection trans‐\nparent for binary data).\n"
                },
                {
                    "name": "ExitOnForwardFailure",
                    "content": "Specifies whether ssh(1) should terminate the connection if it cannot set up all  re‐\nquested  dynamic,  tunnel, local, and remote port forwardings, (e.g. if either end is\nunable to bind and listen on a specified port).  Note that ExitOnForwardFailure  does\nnot  apply to connections made over port forwardings and will not, for example, cause\nssh(1) to exit if TCP connections to the ultimate forwarding destination  fail.   The\nargument must be yes or no (the default).\n"
                },
                {
                    "name": "FingerprintHash",
                    "content": "Specifies  the  hash  algorithm used when displaying key fingerprints.  Valid options\nare: md5 and sha256 (the default).\n"
                },
                {
                    "name": "ForkAfterAuthentication",
                    "content": "Requests ssh to go to background just before command execution.  This  is  useful  if\nssh  is going to ask for passwords or passphrases, but the user wants it in the back‐\nground.  This implies the StdinNull configuration option being  set  to  “yes”.   The\nrecommended  way to start X11 programs at a remote site is with something like ssh -f\nhost xterm, which is the same as ssh host xterm if the  ForkAfterAuthentication  con‐\nfiguration option is set to “yes”.\n\nIf  the  ExitOnForwardFailure  configuration  option  is  set to “yes”, then a client\nstarted with the ForkAfterAuthentication configuration option being set to “yes” will\nwait for all remote port forwards to be successfully established before  placing  it‐\nself in the background.  The argument to this keyword must be yes (same as the -f op‐\ntion) or no (the default).\n"
                },
                {
                    "name": "ForwardAgent",
                    "content": "Specifies  whether  the  connection to the authentication agent (if any) will be for‐\nwarded to the remote machine.  The argument may be yes, no (the default), an explicit\npath to an agent socket or the name of an environment variable (beginning  with  ‘$’)\nin which to find the path.\n\nAgent  forwarding  should  be enabled with caution.  Users with the ability to bypass\nfile permissions on the remote host (for the agent's Unix-domain socket)  can  access\nthe  local agent through the forwarded connection.  An attacker cannot obtain key ma‐\nterial from the agent, however they can perform operations on the  keys  that  enable\nthem to authenticate using the identities loaded into the agent.\n"
                },
                {
                    "name": "ForwardX11",
                    "content": "Specifies  whether  X11  connections will be automatically redirected over the secure\nchannel and DISPLAY set.  The argument must be yes or no (the default).\n\nX11 forwarding should be enabled with caution.  Users with the ability to bypass file\npermissions on the remote host (for the user's X11 authorization database) can access\nthe local X11 display through the forwarded connection.  An attacker may then be able\nto perform activities such as keystroke monitoring if the ForwardX11Trusted option is\nalso enabled.\n"
                },
                {
                    "name": "ForwardX11Timeout",
                    "content": "Specify a timeout for untrusted X11 forwarding using  the  format  described  in  the\n“TIME  FORMATS”  section of sshdconfig(5).  X11 connections received by ssh(1) after\nthis time will be refused.  Setting ForwardX11Timeout to zero will disable the  time‐\nout and permit X11 forwarding for the life of the connection.  The default is to dis‐\nable untrusted X11 forwarding after twenty minutes has elapsed.\n"
                },
                {
                    "name": "ForwardX11Trusted",
                    "content": "If  this option is set to yes, (the Debian-specific default), remote X11 clients will\nhave full access to the original X11 display.\n\nIf this option is set to no (the upstream default), remote X11 clients will  be  con‐\nsidered  untrusted  and  prevented  from stealing or tampering with data belonging to\ntrusted X11 clients.  Furthermore, the xauth(1) token used for the  session  will  be\nset  to  expire  after  20 minutes.  Remote clients will be refused access after this\ntime.\n\nSee the X11 SECURITY extension specification for full details on the restrictions im‐\nposed on untrusted clients.\n"
                },
                {
                    "name": "GatewayPorts",
                    "content": "Specifies whether remote hosts are allowed to connect to local forwarded  ports.   By\ndefault,  ssh(1) binds local port forwardings to the loopback address.  This prevents\nother remote hosts from connecting to forwarded ports.  GatewayPorts can be  used  to\nspecify that ssh should bind local port forwardings to the wildcard address, thus al‐\nlowing  remote  hosts  to connect to forwarded ports.  The argument must be yes or no\n(the default).\n"
                },
                {
                    "name": "GlobalKnownHostsFile",
                    "content": "Specifies one or more files to use for the global host  key  database,  separated  by\nwhitespace.  The default is /etc/ssh/sshknownhosts, /etc/ssh/sshknownhosts2.\n"
                },
                {
                    "name": "GSSAPIAuthentication",
                    "content": "Specifies whether user authentication based on GSSAPI is allowed.  The default is no.\n"
                },
                {
                    "name": "GSSAPIClientIdentity",
                    "content": "If  set,  specifies the GSSAPI client identity that ssh should use when connecting to\nthe server. The default is unset, which means that the default identity will be used.\n"
                },
                {
                    "name": "GSSAPIDelegateCredentials",
                    "content": "Forward (delegate) credentials to the server.  The default is no.\n"
                },
                {
                    "name": "GSSAPIKeyExchange",
                    "content": "Specifies whether key exchange based on GSSAPI may be used. When using GSSAPI key ex‐\nchange the server need not have a host key.  The default is “no”.\n"
                },
                {
                    "name": "GSSAPIRenewalForcesRekey",
                    "content": "If set to “yes” then renewal of the client's GSSAPI credentials will force the rekey‐\ning of the ssh connection. With a compatible server, this will delegate  the  renewed\ncredentials to a session on the server.\n\nChecks  are  made to ensure that credentials are only propagated when the new creden‐\ntials match the old ones on the originating client and  where  the  receiving  server\nstill has the old set in its cache.\n\nThe default is “no”.\n\nFor this to work GSSAPIKeyExchange needs to be enabled in the server and also used by\nthe client.\n"
                },
                {
                    "name": "GSSAPIServerIdentity",
                    "content": "If  set,  specifies the GSSAPI server identity that ssh should expect when connecting\nto the server. The default is unset, which means  that  the  expected  GSSAPI  server\nidentity will be determined from the target hostname.\n"
                },
                {
                    "name": "GSSAPITrustDns",
                    "content": "Set to “yes” to indicate that the DNS is trusted to securely canonicalize the name of\nthe  host  being connected to. If “no”, the hostname entered on the command line will\nbe passed untouched to the GSSAPI library.  The default is “no”.\n"
                },
                {
                    "name": "GSSAPIKexAlgorithms",
                    "content": "The list of key exchange algorithms that are offered for GSSAPI key exchange.  Possi‐\nble values are\n\ngss-gex-sha1-,\ngss-group1-sha1-,\ngss-group14-sha1-,\ngss-group14-sha256-,\ngss-group16-sha512-,\ngss-nistp256-sha256-,\ngss-curve25519-sha256-\n\nThe                                     default                                    is\n“gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-,gss-gex-sha1-,gss-group14-sha1-”.\nThis option only applies to connections using GSSAPI.\n"
                },
                {
                    "name": "HashKnownHosts",
                    "content": "Indicates that ssh(1) should hash host names and addresses when  they  are  added  to\n~/.ssh/knownhosts.   These  hashed names may be used normally by ssh(1) and sshd(8),\nbut they do not visually reveal identifying information if the  file's  contents  are\ndisclosed.  The default is no.  Note that existing names and addresses in known hosts\nfiles  will  not  be  converted  automatically,  but  may  be  manually  hashed using\nssh-keygen(1).  Use of this option may break facilities such as  tab-completion  that\nrely on being able to read unhashed host names from ~/.ssh/knownhosts.\n"
                },
                {
                    "name": "HostbasedAcceptedAlgorithms",
                    "content": "Specifies  the signature algorithms that will be used for hostbased authentication as\na comma-separated list of patterns.  Alternately if the specified list begins with  a\n‘+’  character,  then  the specified signature algorithms will be appended to the de‐\nfault set instead of replacing them.  If the specified list begins with a ‘-’ charac‐\nter, then the specified signature algorithms (including wildcards)  will  be  removed\nfrom  the default set instead of replacing them.  If the specified list begins with a\n‘^’ character, then the specified signature algorithms will be placed at the head  of\nthe default set.  The default for this option is:\n\nssh-ed25519-cert-v01@openssh.com,\necdsa-sha2-nistp256-cert-v01@openssh.com,\necdsa-sha2-nistp384-cert-v01@openssh.com,\necdsa-sha2-nistp521-cert-v01@openssh.com,\nsk-ssh-ed25519-cert-v01@openssh.com,\nsk-ecdsa-sha2-nistp256-cert-v01@openssh.com,\nrsa-sha2-512-cert-v01@openssh.com,\nrsa-sha2-256-cert-v01@openssh.com,\nssh-ed25519,\necdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,\nsk-ssh-ed25519@openssh.com,\nsk-ecdsa-sha2-nistp256@openssh.com,\nrsa-sha2-512,rsa-sha2-256\n\nThe -Q option of ssh(1) may be used to list supported signature algorithms.  This was\nformerly named HostbasedKeyTypes.\n"
                },
                {
                    "name": "HostbasedAuthentication",
                    "content": "Specifies  whether to try rhosts based authentication with public key authentication.\nThe argument must be yes or no (the default).\n"
                },
                {
                    "name": "HostKeyAlgorithms",
                    "content": "Specifies the host key signature algorithms that the client wants to use in order  of\npreference.   Alternately if the specified list begins with a ‘+’ character, then the\nspecified signature algorithms will be appended to the default set instead of replac‐\ning them.  If the specified list begins with a ‘-’ character, then the specified sig‐\nnature algorithms (including wildcards) will be removed from the default set  instead\nof replacing them.  If the specified list begins with a ‘^’ character, then the spec‐\nified  signature  algorithms  will be placed at the head of the default set.  The de‐\nfault for this option is:\n\nssh-ed25519-cert-v01@openssh.com,\necdsa-sha2-nistp256-cert-v01@openssh.com,\necdsa-sha2-nistp384-cert-v01@openssh.com,\necdsa-sha2-nistp521-cert-v01@openssh.com,\nsk-ssh-ed25519-cert-v01@openssh.com,\nsk-ecdsa-sha2-nistp256-cert-v01@openssh.com,\nrsa-sha2-512-cert-v01@openssh.com,\nrsa-sha2-256-cert-v01@openssh.com,\nssh-ed25519,\necdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,\nsk-ecdsa-sha2-nistp256@openssh.com,\nsk-ssh-ed25519@openssh.com,\nrsa-sha2-512,rsa-sha2-256\n\nIf hostkeys are known for the destination host then this default is modified to  pre‐\nfer their algorithms.\n\nThe  list  of  available  signature  algorithms  may  also  be obtained using \"ssh -Q\nHostKeyAlgorithms\".\n"
                },
                {
                    "name": "HostKeyAlias",
                    "content": "Specifies an alias that should be used instead of the real host name when looking  up\nor  saving  the host key in the host key database files and when validating host cer‐\ntificates.  This option is useful for  tunneling  SSH  connections  or  for  multiple\nservers running on a single host.\n"
                },
                {
                    "name": "Hostname",
                    "content": "Specifies  the  real host name to log into.  This can be used to specify nicknames or\nabbreviations for hosts.  Arguments to Hostname accept the tokens  described  in  the\n“TOKENS”  section.  Numeric IP addresses are also permitted (both on the command line\nand in Hostname specifications).  The default is the name given on the command line.\n"
                },
                {
                    "name": "IdentitiesOnly",
                    "content": "Specifies that ssh(1) should only use the configured authentication identity and cer‐\ntificate files (either the default files,  or  those  explicitly  configured  in  the\nsshconfig  files  or  passed  on the ssh(1) command-line), even if ssh-agent(1) or a\nPKCS11Provider or SecurityKeyProvider offers more identities.  The argument  to  this\nkeyword  must  be  yes  or  no (the default).  This option is intended for situations\nwhere ssh-agent offers many different identities.\n"
                },
                {
                    "name": "IdentityAgent",
                    "content": "Specifies the Unix-domain socket used to communicate with the authentication agent.\n\nThis option overrides the SSHAUTHSOCK environment variable and can be used  to  se‐\nlect  a  specific  agent.  Setting the socket name to none disables the use of an au‐\nthentication agent.  If the string \"SSHAUTHSOCK\" is specified, the location of  the\nsocket  will  be  read from the SSHAUTHSOCK environment variable.  Otherwise if the\nspecified value begins with a ‘$’ character, then it will be treated as  an  environ‐\nment variable containing the location of the socket.\n\nArguments  to IdentityAgent may use the tilde syntax to refer to a user's home direc‐\ntory, the tokens described in the “TOKENS” section and environment variables  as  de‐\nscribed in the “ENVIRONMENT VARIABLES” section.\n"
                },
                {
                    "name": "IdentityFile",
                    "content": "Specifies  a  file  from  which  the  user's  DSA, ECDSA, authenticator-hosted ECDSA,\nEd25519, authenticator-hosted Ed25519 or RSA authentication identity  is  read.   You\ncan  also  specify  a  public  key  file to use the corresponding private key that is\nloaded in ssh-agent(1) when the private key file is not present locally.  The default\nis    ~/.ssh/idrsa,    ~/.ssh/idecdsa,    ~/.ssh/idecdsask,    ~/.ssh/ided25519,\n~/.ssh/ided25519sk  and ~/.ssh/iddsa.  Additionally, any identities represented by\nthe authentication agent will be used for  authentication  unless  IdentitiesOnly  is\nset.   If  no  certificates have been explicitly specified by CertificateFile, ssh(1)\nwill try to load certificate information from  the  filename  obtained  by  appending\n-cert.pub to the path of a specified IdentityFile.\n\nArguments  to  IdentityFile may use the tilde syntax to refer to a user's home direc‐\ntory or the tokens described in the “TOKENS” section.   Alternately  an  argument  of\nnone may be used to indicate no identity files should be loaded.\n\nIt  is possible to have multiple identity files specified in configuration files; all\nthese identities will be tried in sequence.  Multiple  IdentityFile  directives  will\nadd  to  the list of identities tried (this behaviour differs from that of other con‐\nfiguration directives).\n\nIdentityFile may be used in conjunction with IdentitiesOnly to select  which  identi‐\nties in an agent are offered during authentication.  IdentityFile may also be used in\nconjunction  with CertificateFile in order to provide any certificate also needed for\nauthentication with the identity.\n"
                },
                {
                    "name": "IgnoreUnknown",
                    "content": "Specifies a pattern-list of unknown options to be ignored if they are encountered  in\nconfiguration  parsing.   This  may be used to suppress errors if sshconfig contains\noptions that are unrecognised by ssh(1).  It is  recommended  that  IgnoreUnknown  be\nlisted  early  in the configuration file as it will not be applied to unknown options\nthat appear before it.\n"
                },
                {
                    "name": "Include",
                    "content": "Include the specified configuration file(s).  Multiple pathnames may be specified and\neach pathname may contain glob(7) wildcards and, for user configurations,  shell-like\n‘~’ references to user home directories.  Wildcards will be expanded and processed in\nlexical  order.  Files without absolute paths are assumed to be in ~/.ssh if included\nin a user configuration file or /etc/ssh if included from  the  system  configuration\nfile.   Include  directive  may appear inside a Match or Host block to perform condi‐\ntional inclusion.\n\nIPQoS   Specifies the IPv4 type-of-service or DSCP class for  connections.   Accepted  values\nare af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1,\ncs2,  cs3,  cs4,  cs5, cs6, cs7, ef, le, lowdelay, throughput, reliability, a numeric\nvalue, or none to use the operating system default.  This option may take one or  two\narguments,  separated by whitespace.  If one argument is specified, it is used as the\npacket class unconditionally.  If two values are specified, the  first  is  automati‐\ncally  selected for interactive sessions and the second for non-interactive sessions.\nThe default is lowdelay for interactive sessions and throughput  for  non-interactive\nsessions.\n"
                },
                {
                    "name": "KbdInteractiveAuthentication",
                    "content": "Specifies  whether  to use keyboard-interactive authentication.  The argument to this\nkeyword must be yes (the default) or no.  ChallengeResponseAuthentication is a depre‐\ncated alias for this.\n"
                },
                {
                    "name": "KbdInteractiveDevices",
                    "content": "Specifies the list of methods to use in keyboard-interactive authentication.   Multi‐\nple method names must be comma-separated.  The default is to use the server specified\nlist.   The  methods  available  vary  depending on what the server supports.  For an\nOpenSSH server, it may be zero or more of: bsdauth and pam.\n"
                },
                {
                    "name": "KexAlgorithms",
                    "content": "Specifies the available KEX (Key Exchange) algorithms.  Multiple algorithms  must  be\ncomma-separated.   If the specified list begins with a ‘+’ character, then the speci‐\nfied algorithms will be appended to the default set instead of  replacing  them.   If\nthe  specified  list  begins with a ‘-’ character, then the specified algorithms (in‐\ncluding wildcards) will be removed from the default set instead  of  replacing  them.\nIf the specified list begins with a ‘^’ character, then the specified algorithms will\nbe placed at the head of the default set.  The default is:\n\nsntrup761x25519-sha512@openssh.com,\ncurve25519-sha256,curve25519-sha256@libssh.org,\necdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,\ndiffie-hellman-group-exchange-sha256,\ndiffie-hellman-group16-sha512,\ndiffie-hellman-group18-sha512,\ndiffie-hellman-group14-sha256\n\nThe  list  of  available  key  exchange algorithms may also be obtained using \"ssh -Q\nkex\".\n"
                },
                {
                    "name": "KnownHostsCommand",
                    "content": "Specifies a command to use to obtain a list of host keys, in addition to those listed\nin UserKnownHostsFile and GlobalKnownHostsFile.  This command is executed  after  the\nfiles  have  been  read.  It may write host key lines to standard output in identical\nformat to the usual files (described in the “VERIFYING HOST KEYS” section in ssh(1)).\nArguments to KnownHostsCommand accept the tokens described in the  “TOKENS”  section.\nThe  command  may  be  invoked multiple times per connection: once when preparing the\npreference list of host key algorithms to use, again to obtain the host key  for  the\nrequested  host name and, if CheckHostIP is enabled, one more time to obtain the host\nkey matching the server's address.  If the command exits abnormally or returns a non-\nzero exit status then the connection is terminated.\n"
                },
                {
                    "name": "LocalCommand",
                    "content": "Specifies a command to execute on the local machine after successfully connecting  to\nthe  server.  The command string extends to the end of the line, and is executed with\nthe user's shell.  Arguments to LocalCommand  accept  the  tokens  described  in  the\n“TOKENS” section.\n\nThe  command  is  run  synchronously  and  does not have access to the session of the\nssh(1) that spawned it.  It should not be used for interactive commands.\n\nThis directive is ignored unless PermitLocalCommand has been enabled.\n"
                },
                {
                    "name": "LocalForward",
                    "content": "Specifies that a TCP port on the local machine be forwarded over the  secure  channel\nto the specified host and port from the remote machine.  The first argument specifies\nthe listener and may be [bindaddress:]port or a Unix domain socket path.  The second\nargument  is the destination and may be host:hostport or a Unix domain socket path if\nthe remote host supports it.\n\nIPv6 addresses can be specified by enclosing addresses in square brackets.   Multiple\nforwardings  may be specified, and additional forwardings can be given on the command\nline.  Only the superuser can forward privileged ports.  By default, the  local  port\nis  bound  in  accordance  with  the  GatewayPorts  setting.   However,  an  explicit\nbindaddress may be  used  to  bind  the  connection  to  a  specific  address.   The\nbindaddress  of  localhost  indicates that the listening port be bound for local use\nonly, while an empty address or ‘*’ indicates that the port should be available  from\nall  interfaces.   Unix  domain  socket  paths  may  use  the tokens described in the\n“TOKENS”  section  and  environment  variables  as  described  in  the   “ENVIRONMENT\nVARIABLES” section.\n"
                },
                {
                    "name": "LogLevel",
                    "content": "Gives the verbosity level that is used when logging messages from ssh(1).  The possi‐\nble  values  are:  QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DE‐\nBUG3.  The default is INFO.  DEBUG and DEBUG1 are equivalent.  DEBUG2 and DEBUG3 each\nspecify higher levels of verbose output.\n"
                },
                {
                    "name": "LogVerbose",
                    "content": "Specify one or more overrides to LogLevel.  An override consists of a  pattern  lists\nthat matches the source file, function and line number to force detailed logging for.\nFor example, an override pattern of:\n\nkex.c:*:1000,*:kexexchangeidentification():*,packet.c:*\n\nwould   enable   detailed   logging  for  line  1000  of  kex.c,  everything  in  the\nkexexchangeidentification() function, and all code in the packet.c file.  This  op‐\ntion is intended for debugging and no overrides are enabled by default.\n\nMACs    Specifies  the  MAC  (message authentication code) algorithms in order of preference.\nThe MAC algorithm is used for data integrity protection.  Multiple algorithms must be\ncomma-separated.  If the specified list begins with a ‘+’ character, then the  speci‐\nfied  algorithms  will  be appended to the default set instead of replacing them.  If\nthe specified list begins with a ‘-’ character, then the  specified  algorithms  (in‐\ncluding  wildcards)  will  be removed from the default set instead of replacing them.\nIf the specified list begins with a ‘^’ character, then the specified algorithms will\nbe placed at the head of the default set.\n\nThe algorithms that contain \"-etm\" calculate the MAC after encryption  (encrypt-then-\nmac).  These are considered safer and their use recommended.\n\nThe default is:\n\numac-64-etm@openssh.com,umac-128-etm@openssh.com,\nhmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,\nhmac-sha1-etm@openssh.com,\numac-64@openssh.com,umac-128@openssh.com,\nhmac-sha2-256,hmac-sha2-512,hmac-sha1\n\nThe list of available MAC algorithms may also be obtained using \"ssh -Q mac\".\n"
                },
                {
                    "name": "NoHostAuthenticationForLocalhost",
                    "content": "Disable host authentication for localhost (loopback addresses).  The argument to this\nkeyword must be yes or no (the default).\n"
                },
                {
                    "name": "NumberOfPasswordPrompts",
                    "content": "Specifies the number of password prompts before giving up.  The argument to this key‐\nword must be an integer.  The default is 3.\n"
                },
                {
                    "name": "ObscureKeystrokeTiming",
                    "content": "Specifies  whether  ssh(1) should try to obscure inter-keystroke timings from passive\nobservers of network traffic.  If enabled, then for interactive sessions, ssh(1) will\nsend keystrokes at fixed intervals of a few tens of milliseconds and will  send  fake\nkeystroke  packets  for  some time after typing ceases.  The argument to this keyword\nmust be yes, no or an interval specifier  of  the  form  interval:milliseconds  (e.g.\ninterval:80  for 80 milliseconds).  The default is to obscure keystrokes using a 20ms\npacket interval.  Note that smaller intervals will result in  higher  fake  keystroke\npacket rates.\n"
                },
                {
                    "name": "PasswordAuthentication",
                    "content": "Specifies  whether to use password authentication.  The argument to this keyword must\nbe yes (the default) or no.\n"
                },
                {
                    "name": "PermitLocalCommand",
                    "content": "Allow local command execution via the LocalCommand option or using the  !command  es‐\ncape sequence in ssh(1).  The argument must be yes or no (the default).\n"
                },
                {
                    "name": "PermitRemoteOpen",
                    "content": "Specifies  the  destinations  to  which  remote TCP port forwarding is permitted when\nRemoteForward is used as a SOCKS proxy.  The forwarding specification must be one  of\nthe following forms:\n\nPermitRemoteOpen host:port\nPermitRemoteOpen IPv4addr:port\nPermitRemoteOpen [IPv6addr]:port\n\nMultiple  forwards  may be specified by separating them with whitespace.  An argument\nof any can be used to remove all restrictions and permit any forwarding requests.  An\nargument of none can be used to prohibit all forwarding requests.  The  wildcard  ‘*’\ncan be used for host or port to allow all hosts or ports respectively.  Otherwise, no\npattern matching or address lookups are performed on supplied names.\n"
                },
                {
                    "name": "PKCS11Provider",
                    "content": "Specifies  which  PKCS#11 provider to use or none to indicate that no provider should\nbe used (the default).  The argument to this keyword is a path to the PKCS#11  shared\nlibrary ssh(1) should use to communicate with a PKCS#11 token providing keys for user\nauthentication.\n\nPort    Specifies the port number to connect on the remote host.  The default is 22.\n"
                },
                {
                    "name": "PreferredAuthentications",
                    "content": "Specifies  the order in which the client should try authentication methods.  This al‐\nlows a client to prefer one method (e.g. keyboard-interactive)  over  another  method\n(e.g. password).  The default is:\n\ngssapi-with-mic,hostbased,publickey,\nkeyboard-interactive,password\n"
                },
                {
                    "name": "ProxyCommand",
                    "content": "Specifies the command to use to connect to the server.  The command string extends to\nthe end of the line, and is executed using the user's shell ‘exec’ directive to avoid\na lingering shell process.\n\nArguments  to  ProxyCommand accept the tokens described in the “TOKENS” section.  The\ncommand can be basically anything, and should read from its standard input and  write\nto  its  standard  output.  It should eventually connect an sshd(8) server running on\nsome machine, or execute sshd -i somewhere.  Host key management will be  done  using\nthe  Hostname of the host being connected (defaulting to the name typed by the user).\nSetting the command to none disables this option entirely.  Note that CheckHostIP  is\nnot available for connects with a proxy command.\n\nThis  directive is useful in conjunction with nc(1) and its proxy support.  For exam‐\nple, the following directive would connect via an HTTP proxy at 192.0.2.0:\n\nProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p\n"
                },
                {
                    "name": "ProxyJump",
                    "content": "Specifies one or more jump proxies as either [user@]host[:port] or an ssh URI.   Mul‐\ntiple  proxies may be separated by comma characters and will be visited sequentially.\nSetting this option will cause ssh(1) to connect to the target host by first making a\nssh(1) connection to the specified ProxyJump host and then establishing  a  TCP  for‐\nwarding  to  the  ultimate target from there.  Setting the host to none disables this\noption entirely.\n\nNote that this option will compete with the ProxyCommand option - whichever is speci‐\nfied first will prevent later instances of the other from taking effect.\n\nNote also that the configuration for the destination host (either  supplied  via  the\ncommand-line  or  the  configuration  file)  is  not generally applied to jump hosts.\n~/.ssh/config should be used if specific configuration is required for jump hosts.\n"
                },
                {
                    "name": "ProxyUseFdpass",
                    "content": "Specifies that ProxyCommand will pass a connected file descriptor back to ssh(1)  in‐\nstead of continuing to execute and pass data.  The default is no.\n"
                },
                {
                    "name": "PubkeyAcceptedAlgorithms",
                    "content": "Specifies the signature algorithms that will be used for public key authentication as\na  comma-separated list of patterns.  If the specified list begins with a ‘+’ charac‐\nter, then the algorithms after it will be appended to the default instead of  replac‐\ning  it.  If the specified list begins with a ‘-’ character, then the specified algo‐\nrithms (including wildcards) will be removed from the default set instead of  replac‐\ning  them.  If the specified list begins with a ‘^’ character, then the specified al‐\ngorithms will be placed at the head of the default set.  The default for this  option\nis:\n\nssh-ed25519-cert-v01@openssh.com,\necdsa-sha2-nistp256-cert-v01@openssh.com,\necdsa-sha2-nistp384-cert-v01@openssh.com,\necdsa-sha2-nistp521-cert-v01@openssh.com,\nsk-ssh-ed25519-cert-v01@openssh.com,\nsk-ecdsa-sha2-nistp256-cert-v01@openssh.com,\nrsa-sha2-512-cert-v01@openssh.com,\nrsa-sha2-256-cert-v01@openssh.com,\nssh-ed25519,\necdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,\nsk-ssh-ed25519@openssh.com,\nsk-ecdsa-sha2-nistp256@openssh.com,\nrsa-sha2-512,rsa-sha2-256\n\nThe  list  of  available  signature  algorithms  may  also  be obtained using \"ssh -Q\nPubkeyAcceptedAlgorithms\".\n"
                },
                {
                    "name": "PubkeyAuthentication",
                    "content": "Specifies whether to try public key authentication.  The  argument  to  this  keyword\nmust  be  yes (the default), no, unbound or host-bound.  The final two options enable\npublic key authentication while respectively disabling or enabling the OpenSSH  host-\nbound authentication protocol extension required for restricted ssh-agent(1) forward‐\ning.\n"
                },
                {
                    "name": "RekeyLimit",
                    "content": "Specifies  the  maximum amount of data that may be transmitted or received before the\nsession key is renegotiated, optionally followed by a maximum amount of time that may\npass before the session key is renegotiated.  The  first  argument  is  specified  in\nbytes  and may have a suffix of ‘K’, ‘M’, or ‘G’ to indicate Kilobytes, Megabytes, or\nGigabytes, respectively.  The default is between ‘1G’ and ‘4G’, depending on the  ci‐\npher.  The optional second value is specified in seconds and may use any of the units\ndocumented  in  the  TIME  FORMATS  section of sshdconfig(5).  The default value for\nRekeyLimit is default none, which means that rekeying is performed after the cipher's\ndefault amount of data has been sent or received and no time based rekeying is done.\n"
                },
                {
                    "name": "RemoteCommand",
                    "content": "Specifies a command to execute on the remote machine after successfully connecting to\nthe server.  The command string extends to the end of the line, and is executed  with\nthe  user's  shell.   Arguments  to  RemoteCommand accept the tokens described in the\n“TOKENS” section.\n"
                },
                {
                    "name": "RemoteForward",
                    "content": "Specifies that a TCP port on the remote machine be forwarded over the secure channel.\nThe remote port may either be forwarded to a specified host and port from  the  local\nmachine,  or  may  act as a SOCKS 4/5 proxy that allows a remote client to connect to\narbitrary destinations from the local machine.  The first argument is  the  listening\nspecification  and  may  be [bindaddress:]port or, if the remote host supports it, a\nUnix domain socket path.  If forwarding to a specific destination then the second ar‐\ngument must be host:hostport or a Unix domain socket path, otherwise if  no  destina‐\ntion  argument is specified then the remote forwarding will be established as a SOCKS\nproxy.  When acting as a SOCKS proxy, the destination of the connection  can  be  re‐\nstricted by PermitRemoteOpen.\n\nIPv6  addresses can be specified by enclosing addresses in square brackets.  Multiple\nforwardings may be specified, and additional forwardings can be given on the  command\nline.   Privileged  ports can be forwarded only when logging in as root on the remote\nmachine.  Unix domain socket paths may use the tokens described in the “TOKENS”  sec‐\ntion and environment variables as described in the “ENVIRONMENT VARIABLES” section.\n\nIf  the  port  argument  is  0,  the listen port will be dynamically allocated on the\nserver and reported to the client at run time.\n\nIf the bindaddress is not specified, the default is to only  bind  to  loopback  ad‐\ndresses.   If  the bindaddress is ‘*’ or an empty string, then the forwarding is re‐\nquested to listen on all interfaces.  Specifying a remote bindaddress will only suc‐\nceed if the server's GatewayPorts option is enabled (see sshdconfig(5)).\n"
                },
                {
                    "name": "RequestTTY",
                    "content": "Specifies whether to request a pseudo-tty for the session.  The argument may  be  one\nof:  no  (never  request  a  TTY), yes (always request a TTY when standard input is a\nTTY), force (always request a TTY) or auto (request a TTY when opening a  login  ses‐\nsion).  This option mirrors the -t and -T flags for ssh(1).\n"
                },
                {
                    "name": "RequiredRSASize",
                    "content": "Specifies the minimum RSA key size (in bits) that ssh(1) will accept.  User authenti‐\ncation  keys smaller than this limit will be ignored.  Servers that present host keys\nsmaller than this limit will cause the connection to be terminated.  The  default  is\n1024 bits.  Note that this limit may only be raised from the default.\n"
                },
                {
                    "name": "RevokedHostKeys",
                    "content": "Specifies  revoked  host  public  keys.  Keys listed in this file will be refused for\nhost authentication.  Note that if this file does not exist or is not readable,  then\nhost  authentication  will be refused for all hosts.  Keys may be specified as a text\nfile, listing one public key per line, or as an OpenSSH Key Revocation List (KRL)  as\ngenerated  by  ssh-keygen(1).   For  more information on KRLs, see the KEY REVOCATION\nLISTS section in ssh-keygen(1).  Arguments to RevokedHostKeys may use the tilde  syn‐\ntax to refer to a user's home directory, the tokens described in the “TOKENS” section\nand environment variables as described in the “ENVIRONMENT VARIABLES” section.\n"
                },
                {
                    "name": "SecurityKeyProvider",
                    "content": "Specifies  a path to a library that will be used when loading any FIDO authenticator-\nhosted keys, overriding the default of using the built-in USB HID support.\n\nIf the specified value begins with a ‘$’ character, then it will be treated as an en‐\nvironment variable containing the path to the library.\n"
                },
                {
                    "name": "SendEnv",
                    "content": "Specifies what variables from the local environ(7) should be sent to the server.  The\nserver must also support it, and the server must be configured to accept these  envi‐\nronment variables.  Note that the TERM environment variable is always sent whenever a\npseudo-terminal  is  requested as it is required by the protocol.  Refer to AcceptEnv\nin sshdconfig(5) for how to configure the server.  Variables are specified by  name,\nwhich  may  contain wildcard characters.  Multiple environment variables may be sepa‐\nrated by whitespace or spread across multiple SendEnv directives.\n\nSee “PATTERNS” for more information on patterns.\n\nIt is possible to clear previously set SendEnv variable names by  prefixing  patterns\nwith -.  The default is not to send any environment variables.\n"
                },
                {
                    "name": "ServerAliveCountMax",
                    "content": "Sets the number of server alive messages (see below) which may be sent without ssh(1)\nreceiving  any  messages  back  from  the server.  If this threshold is reached while\nserver alive messages are being sent, ssh will disconnect from the server,  terminat‐\ning  the  session.   It is important to note that the use of server alive messages is\nvery different from TCPKeepAlive (below).  The server alive messages are sent through\nthe encrypted channel and therefore will not be spoofable.  The TCP keepalive  option\nenabled  by  TCPKeepAlive  is spoofable.  The server alive mechanism is valuable when\nthe client or server depend on knowing when a connection has become unresponsive.\n\nThe default value is 3.  If, for example, ServerAliveInterval (see below) is  set  to\n15  and  ServerAliveCountMax  is left at the default, if the server becomes unrespon‐\nsive, ssh will disconnect after approximately 45 seconds.\n"
                },
                {
                    "name": "ServerAliveInterval",
                    "content": "Sets a timeout interval in seconds after which if no data has been received from  the\nserver,  ssh(1)  will  send  a message through the encrypted channel to request a re‐\nsponse from the server.  The default is 0, indicating that these messages will not be\nsent to the server,  or  300  if  the  BatchMode  option  is  set  (Debian-specific).\nProtocolKeepAlives  and  SetupTimeOut  are  Debian-specific compatibility aliases for\nthis option.\n"
                },
                {
                    "name": "SessionType",
                    "content": "May be used to either request invocation of a subsystem on the remote system,  or  to\nprevent the execution of a remote command at all.  The latter is useful for just for‐\nwarding  ports.   The  argument to this keyword must be none (same as the -N option),\nsubsystem (same as the -s option) or default (shell or command execution).\n\nSetEnv  Directly specify one or more environment variables and their contents to be  sent  to\nthe  server.   Similarly  to  SendEnv,  with  the exception of the TERM variable, the\nserver must be prepared to accept the environment variable.\n"
                },
                {
                    "name": "StdinNull",
                    "content": "Redirects stdin from /dev/null (actually, prevents reading from stdin).  Either  this\nor  the equivalent -n option must be used when ssh is run in the background.  The ar‐\ngument to this keyword must be yes (same as the -n option) or no (the default).\n"
                },
                {
                    "name": "StreamLocalBindMask",
                    "content": "Sets the octal file creation mode mask  (umask)  used  when  creating  a  Unix-domain\nsocket  file  for local or remote port forwarding.  This option is only used for port\nforwarding to a Unix-domain socket file.\n\nThe default value is 0177, which creates a Unix-domain socket file that  is  readable\nand  writable  only by the owner.  Note that not all operating systems honor the file\nmode on Unix-domain socket files.\n"
                },
                {
                    "name": "StreamLocalBindUnlink",
                    "content": "Specifies whether to remove an existing Unix-domain socket file for local  or  remote\nport  forwarding  before  creating  a new one.  If the socket file already exists and\nStreamLocalBindUnlink is not enabled, ssh will be unable to forward the port  to  the\nUnix-domain  socket file.  This option is only used for port forwarding to a Unix-do‐\nmain socket file.\n\nThe argument must be yes or no (the default).\n"
                },
                {
                    "name": "StrictHostKeyChecking",
                    "content": "If this flag is set to yes, ssh(1) will never automatically  add  host  keys  to  the\n~/.ssh/knownhosts  file, and refuses to connect to hosts whose host key has changed.\nThis provides maximum protection against man-in-the-middle (MITM) attacks, though  it\ncan  be  annoying when the /etc/ssh/sshknownhosts file is poorly maintained or when\nconnections to new hosts are frequently made.  This option forces the user  to  manu‐\nally add all new hosts.\n\nIf  this  flag  is set to accept-new then ssh will automatically add new host keys to\nthe user's knownhosts file, but will not permit connections to  hosts  with  changed\nhost  keys.   If  this  flag is set to no or off, ssh will automatically add new host\nkeys to the user known hosts files  and  allow  connections  to  hosts  with  changed\nhostkeys  to  proceed, subject to some restrictions.  If this flag is set to ask (the\ndefault), new host keys will be added to the user known host  files  only  after  the\nuser  has  confirmed that is what they really want to do, and ssh will refuse to con‐\nnect to hosts whose host key has changed.  The host keys of known hosts will be veri‐\nfied automatically in all cases.\n"
                },
                {
                    "name": "SyslogFacility",
                    "content": "Gives the facility code that is used when logging messages from ssh(1).  The possible\nvalues are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4,  LOCAL5,  LO‐\nCAL6, LOCAL7.  The default is USER.\n"
                },
                {
                    "name": "TCPKeepAlive",
                    "content": "Specifies  whether  the  system should send TCP keepalive messages to the other side.\nIf they are sent, death of the connection or crash of one of  the  machines  will  be\nproperly  noticed.   This  option  only  uses TCP keepalives (as opposed to using ssh\nlevel keepalives), so takes a long time to notice when the connection dies.  As such,\nyou probably want the ServerAliveInterval option as well.  However, this  means  that\nconnections will die if the route is down temporarily, and some people find it annoy‐\ning.\n\nThe  default  is  yes (to send TCP keepalive messages), and the client will notice if\nthe network goes down or the remote host dies.  This is  important  in  scripts,  and\nmany users want it too.\n\nTo  disable  TCP  keepalive  messages,  the  value  should  be  set  to no.  See also\nServerAliveInterval for protocol-level keepalives.\n\nTag     Specify a configuration tag name that may be later used by a Match directive  to  se‐\nlect a block of configuration.\n\nTunnel  Request  tun(4)  device  forwarding  between the client and the server.  The argument\nmust be yes, point-to-point (layer 3), ethernet  (layer  2),  or  no  (the  default).\nSpecifying yes requests the default tunnel mode, which is point-to-point.\n"
                },
                {
                    "name": "TunnelDevice",
                    "content": "Specifies  the  tun(4)  devices  to  open  on  the  client (localtun) and the server\n(remotetun).\n\nThe argument must be localtun[:remotetun].  The devices may be specified by numeri‐\ncal ID or the  keyword  any,  which  uses  the  next  available  tunnel  device.   If\nremotetun is not specified, it defaults to any.  The default is any:any.\n"
                },
                {
                    "name": "UpdateHostKeys",
                    "content": "Specifies  whether ssh(1) should accept notifications of additional hostkeys from the\nserver sent after authentication has completed and add  them  to  UserKnownHostsFile.\nThe  argument must be yes, no or ask.  This option allows learning alternate hostkeys\nfor a server and supports graceful key rotation by allowing a server to send replace‐\nment public keys before old ones are removed.\n\nAdditional hostkeys are only accepted if the key used to authenticate  the  host  was\nalready  trusted  or  explicitly accepted by the user, the host was authenticated via\nUserKnownHostsFile (i.e. not GlobalKnownHostsFile) and the host was authenticated us‐\ning a plain key and not a certificate.\n\nUpdateHostKeys is enabled by default if the  user  has  not  overridden  the  default\nUserKnownHostsFile   setting   and   has   not  enabled  VerifyHostKeyDNS,  otherwise\nUpdateHostKeys will be set to no.\n\nIf UpdateHostKeys is set to ask, then the user is asked to confirm the  modifications\nto the knownhosts file.  Confirmation is currently incompatible with ControlPersist,\nand will be disabled if it is enabled.\n\nPresently,    only    sshd(8)    from   OpenSSH   6.8   and   greater   support   the\n\"hostkeys@openssh.com\" protocol extension used  to  inform  the  client  of  all  the\nserver's hostkeys.\n\nUser    Specifies  the  user  to log in as.  This can be useful when a different user name is\nused on different machines.  This saves the trouble of having to remember to give the\nuser name on the command line.\n"
                },
                {
                    "name": "UserKnownHostsFile",
                    "content": "Specifies one or more files to use for the  user  host  key  database,  separated  by\nwhitespace.   Each filename may use tilde notation to refer to the user's home direc‐\ntory, the tokens described in the “TOKENS” section and environment variables  as  de‐\nscribed in the “ENVIRONMENT VARIABLES” section.  A value of none causes ssh(1) to ig‐\nnore  any  user-specific  known  hosts  files.   The  default  is ~/.ssh/knownhosts,\n~/.ssh/knownhosts2.\n"
                },
                {
                    "name": "VerifyHostKeyDNS",
                    "content": "Specifies whether to verify the remote key using DNS and SSHFP resource records.   If\nthis  option is set to yes, the client will implicitly trust keys that match a secure\nfingerprint from DNS.  Insecure fingerprints will be handled as if  this  option  was\nset  to  ask.  If this option is set to ask, information on fingerprint match will be\ndisplayed, but the user will still need to confirm new host  keys  according  to  the\nStrictHostKeyChecking option.  The default is no.\n\nSee also “VERIFYING HOST KEYS” in ssh(1).\n"
                },
                {
                    "name": "VisualHostKey",
                    "content": "If  this  flag is set to yes, an ASCII art representation of the remote host key fin‐\ngerprint is printed in addition to the fingerprint string at login  and  for  unknown\nhost  keys.   If  this  flag  is  set to no (the default), no fingerprint strings are\nprinted at login and only the fingerprint string will be  printed  for  unknown  host\nkeys.\n"
                },
                {
                    "name": "XAuthLocation",
                    "content": "Specifies the full pathname of the xauth(1) program.  The default is /usr/bin/xauth.\n"
                }
            ]
        },
        "PATTERNS": {
            "content": "A  pattern  consists  of zero or more non-whitespace characters, ‘*’ (a wildcard that matches\nzero or more characters), or ‘?’ (a wildcard that matches exactly one character).  For  exam‐\nple,  to  specify a set of declarations for any host in the \".co.uk\" set of domains, the fol‐\nlowing pattern could be used:\n\nHost *.co.uk\n\nThe following pattern would match any host in the 192.168.0.[0-9] network range:\n\nHost 192.168.0.?\n\nA pattern-list is a comma-separated list of patterns.  Patterns within pattern-lists  may  be\nnegated  by preceding them with an exclamation mark (‘!’).  For example, to allow a key to be\nused from anywhere within an organization except from the \"dialup\" pool, the following  entry\n(in authorizedkeys) could be used:\n\nfrom=\"!*.dialup.example.com,*.example.com\"\n\nNote  that  a negated match will never produce a positive result by itself.  For example, at‐\ntempting to match \"host3\" against the following pattern-list will fail:\n\nfrom=\"!host1,!host2\"\n\nThe solution here is to include a term that will yield a positive match, such as a wildcard:\n\nfrom=\"!host1,!host2,*\"\n",
            "subsections": []
        },
        "TOKENS": {
            "content": "Arguments to some keywords can make use of tokens, which are expanded at runtime:\n\n%%    A literal ‘%’.\n%C    Hash of %l%h%p%r%j.\n%d    Local user's home directory.\n%f    The fingerprint of the server's host key.\n%H    The knownhosts hostname or address that is being searched for.\n%h    The remote hostname.\n%I    A string describing the reason for a KnownHostsCommand execution: either  ADDRESS\nwhen  looking  up  a host by address (only when CheckHostIP is enabled), HOSTNAME\nwhen searching by hostname, or ORDER when preparing the host key algorithm  pref‐\nerence list to use for the destination host.\n%i    The local user ID.\n%j    The  contents  of the ProxyJump option, or the empty string if this option is un‐\nset.\n%K    The base64 encoded host key.\n%k    The host key alias if specified, otherwise the original remote hostname given  on\nthe command line.\n%L    The local hostname.\n%l    The local hostname, including the domain name.\n%n    The original remote hostname, as given on the command line.\n%p    The remote port.\n%r    The remote username.\n%T    The  local  tun(4)  or tap(4) network interface assigned if tunnel forwarding was\nrequested, or \"NONE\" otherwise.\n%t    The type of the server host key, e.g.  ssh-ed25519.\n%u    The local username.\n\nCertificateFile, ControlPath, IdentityAgent, IdentityFile,  KnownHostsCommand,  LocalForward,\nMatch  exec, RemoteCommand, RemoteForward, RevokedHostKeys, and UserKnownHostsFile accept the\ntokens %%, %C, %d, %h, %i, %j, %k, %L, %l, %n, %p, %r, and %u.\n\nKnownHostsCommand additionally accepts the tokens %f, %H, %I, %K and %t.\n\nHostname accepts the tokens %% and %h.\n\nLocalCommand accepts all tokens.\n\nProxyCommand and ProxyJump accept the tokens %%, %h, %n, %p, and %r.\n\nNote that some of these directives build commands  for  execution  via  the  shell.   Because\nssh(1)  performs  no  filtering  or escaping of characters that have special meaning in shell\ncommands (e.g. quotes), it is the user's responsibility to ensure that the  arguments  passed\nto ssh(1) do not contain such characters and that tokens are appropriately quoted when used.\n",
            "subsections": []
        },
        "ENVIRONMENT VARIABLES": {
            "content": "Arguments  to  some  keywords  can  be  expanded at runtime from environment variables on the\nclient by enclosing them in ${}, for example ${HOME}/.ssh would refer to the user's .ssh  di‐\nrectory.   If  a specified environment variable does not exist then an error will be returned\nand the setting for that keyword will be ignored.\n\nThe keywords CertificateFile, ControlPath,  IdentityAgent,  IdentityFile,  KnownHostsCommand,\nand   UserKnownHostsFile  support  environment  variables.   The  keywords  LocalForward  and\nRemoteForward support environment variables only for Unix domain socket paths.\n",
            "subsections": []
        },
        "FILES": {
            "content": "~/.ssh/config\nThis is the per-user configuration file.  The format of this file is described above.\nThis file is used by the SSH client.  Because of the potential for abuse,  this  file\nmust  have  strict  permissions: read/write for the user, and not writable by others.\nIt may be group-writable provided that the group in question contains only the user.\n\n/etc/ssh/sshconfig\nSystemwide configuration file.  This file provides defaults for those values that are\nnot specified in the user's configuration file, and for those users who do not have a\nconfiguration file.  This file must be world-readable.\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "ssh(1)\n",
            "subsections": []
        },
        "AUTHORS": {
            "content": "OpenSSH is a derivative of the original and free ssh 1.2.12 release by  Tatu  Ylonen.   Aaron\nCampbell,  Bob  Beck,  Markus  Friedl,  Niels Provos, Theo de Raadt and Dug Song removed many\nbugs, re-added newer features and created OpenSSH.  Markus Friedl contributed the support for\nSSH protocol versions 1.5 and 2.0.\n\nDebian                                    October 12, 2023                             SSHCONFIG(5)",
            "subsections": []
        }
    },
    "summary": "sshconfig — OpenSSH client configuration file",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "ssh",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/ssh/1/json"
        }
    ]
}