1SSH_CONFIG(5) BSD File Formats Manual SSH_CONFIG(5)
2
4 ssh_config — OpenSSH client configuration file
5
7 ssh(1) obtains configuration data from the following sources in the fol‐
8 lowing order:
9 1. command-line options
11 2. user's configuration file (~/.ssh/config)
12 3. system-wide configuration file (/etc/ssh/ssh_config)
13 Unless noted otherwise, for each parameter, the first obtained value will
15 be used. The configuration files contain sections separated by Host
16 specifications, and that section is only applied for hosts that match one
17 of the patterns given in the specification. The matched host name is
18 usually the one given on the command line (see the CanonicalizeHostname
19 option for exceptions).
20 Since the first obtained value for each parameter is used, more host-spe‐
22 cific declarations should be given near the beginning of the file, and
23 general defaults at the end.
24 The file contains keyword-argument pairs, one per line. Lines starting
26 with ‘#’ and empty lines are interpreted as comments. Arguments may op‐
27 tionally be enclosed in double quotes (") in order to represent arguments
28 containing spaces. Configuration options may be separated by whitespace
29 or optional whitespace and exactly one ‘=’; the latter format is useful
30 to avoid the need to quote whitespace when specifying configuration op‐
31 tions using the ssh, scp, and sftp -o option.
32 The possible keywords and their meanings are as follows (note that key‐
34 words are case-insensitive and arguments are case-sensitive):
35 Host Restricts the following declarations (up to the next Host or
37 Match keyword) to be only for those hosts that match one of the
38 patterns given after the keyword. If more than one pattern is
39 provided, they should be separated by whitespace. A single ‘*’
40 as a pattern can be used to provide global defaults for all
41 hosts. The host is usually the hostname argument given on the
42 command line (see the CanonicalizeHostname keyword for excep‐
43 tions).
44 A pattern entry may be negated by prefixing it with an exclama‐
46 tion mark (‘!’). If a negated entry is matched, then the Host
47 entry is ignored, regardless of whether any other patterns on the
48 line match. Negated matches are therefore useful to provide ex‐
49 ceptions for wildcard matches.
50 See PATTERNS for more information on patterns.
52 Match Restricts the following declarations (up to the next Host or
54 Match keyword) to be used only when the conditions following the
55 Match keyword are satisfied. Match conditions are specified us‐
56 ing one or more criteria or the single token all which always
57 matches. The available criteria keywords are: canonical, final,
58 exec, host, originalhost, user, and localuser. The all criteria
59 must appear alone or immediately after canonical or final. Other
60 criteria may be combined arbitrarily. All criteria but all,
61 canonical, and final require an argument. Criteria may be
62 negated by prepending an exclamation mark (‘!’).
63 The canonical keyword matches only when the configuration file is
65 being re-parsed after hostname canonicalization (see the
66 CanonicalizeHostname option). This may be useful to specify con‐
67 ditions that work with canonical host names only.
68 The final keyword requests that the configuration be re-parsed
70 (regardless of whether CanonicalizeHostname is enabled), and
71 matches only during this final pass. If CanonicalizeHostname is
72 enabled, then canonical and final match during the same pass.
73 The exec keyword executes the specified command under the user's
75 shell. If the command returns a zero exit status then the condi‐
76 tion is considered true. Commands containing whitespace charac‐
77 ters must be quoted. Arguments to exec accept the tokens de‐
78 scribed in the TOKENS section.
79 The other keywords' criteria must be single entries or comma-sep‐
81 arated lists and may use the wildcard and negation operators de‐
82 scribed in the PATTERNS section. The criteria for the host key‐
83 word are matched against the target hostname, after any substitu‐
84 tion by the Hostname or CanonicalizeHostname options. The
85 originalhost keyword matches against the hostname as it was spec‐
86 ified on the command-line. The user keyword matches against the
87 target username on the remote host. The localuser keyword
88 matches against the name of the local user running ssh(1) (this
89 keyword may be useful in system-wide ssh_config files).
90 AddKeysToAgent
92 Specifies whether keys should be automatically added to a running
93 ssh-agent(1). If this option is set to yes and a key is loaded
94 from a file, the key and its passphrase are added to the agent
95 with the default lifetime, as if by ssh-add(1). If this option
96 is set to ask, ssh(1) will require confirmation using the
97 SSH_ASKPASS program before adding a key (see ssh-add(1) for de‐
98 tails). If this option is set to confirm, each use of the key
99 must be confirmed, as if the -c option was specified to
100 ssh-add(1). If this option is set to no, no keys are added to
101 the agent. Alternately, this option may be specified as a time
102 interval using the format described in the TIME FORMATS section
103 of sshd_config(5) to specify the key's lifetime in ssh-agent(1),
104 after which it will automatically be removed. The argument must
105 be no (the default), yes, confirm (optionally followed by a time
106 interval), ask or a time interval.
107 AddressFamily
109 Specifies which address family to use when connecting. Valid ar‐
110 guments are any (the default), inet (use IPv4 only), or inet6
111 (use IPv6 only).
112 BatchMode
114 If set to yes, user interaction such as password prompts and host
115 key confirmation requests will be disabled. This option is use‐
116 ful in scripts and other batch jobs where no user is present to
117 interact with ssh(1). The argument must be yes or no (the de‐
118 fault).
119 BindAddress
121 Use the specified address on the local machine as the source ad‐
122 dress of the connection. Only useful on systems with more than
123 one address.
124 BindInterface
126 Use the address of the specified interface on the local machine
127 as the source address of the connection.
128 CanonicalDomains
130 When CanonicalizeHostname is enabled, this option specifies the
131 list of domain suffixes in which to search for the specified des‐
132 tination host.
133 CanonicalizeFallbackLocal
135 Specifies whether to fail with an error when hostname canonical‐
136 ization fails. The default, yes, will attempt to look up the un‐
137 qualified hostname using the system resolver's search rules. A
138 value of no will cause ssh(1) to fail instantly if
139 CanonicalizeHostname is enabled and the target hostname cannot be
140 found in any of the domains specified by CanonicalDomains.
141 CanonicalizeHostname
143 Controls whether explicit hostname canonicalization is performed.
144 The default, no, is not to perform any name rewriting and let the
145 system resolver handle all hostname lookups. If set to yes then,
146 for connections that do not use a ProxyCommand or ProxyJump,
147 ssh(1) will attempt to canonicalize the hostname specified on the
148 command line using the CanonicalDomains suffixes and
149 CanonicalizePermittedCNAMEs rules. If CanonicalizeHostname is
150 set to always, then canonicalization is applied to proxied con‐
151 nections too.
152 If this option is enabled, then the configuration files are pro‐
154 cessed again using the new target name to pick up any new config‐
155 uration in matching Host and Match stanzas. A value of none dis‐
156 ables the use of a ProxyJump host.
157 CanonicalizeMaxDots
159 Specifies the maximum number of dot characters in a hostname be‐
160 fore canonicalization is disabled. The default, 1, allows a sin‐
161 gle dot (i.e. hostname.subdomain).
162 CanonicalizePermittedCNAMEs
164 Specifies rules to determine whether CNAMEs should be followed
165 when canonicalizing hostnames. The rules consist of one or more
166 arguments of source_domain_list:target_domain_list, where
167 source_domain_list is a pattern-list of domains that may follow
168 CNAMEs in canonicalization, and target_domain_list is a pattern-
169 list of domains that they may resolve to.
170 For example, "*.a.example.com:*.b.example.com,*.c.example.com"
172 will allow hostnames matching "*.a.example.com" to be canonical‐
173 ized to names in the "*.b.example.com" or "*.c.example.com" do‐
174 mains.
175 A single argument of "none" causes no CNAMEs to be considered for
177 canonicalization. This is the default behaviour.
178 CASignatureAlgorithms
180 The default is handled system-wide by crypto-policies(7). Infor‐
181 mation about defaults, how to modify the defaults and how to cus‐
182 tomize existing policies with sub-policies are present in manual
183 page update-crypto-policies(8).
184 Specifies which algorithms are allowed for signing of certifi‐
186 cates by certificate authorities (CAs). If the specified list
187 begins with a ‘+’ character, then the specified algorithms will
188 be appended to the default set instead of replacing them. If the
189 specified list begins with a ‘-’ character, then the specified
190 algorithms (including wildcards) will be removed from the default
191 set instead of replacing them.
192 ssh(1) will not accept host certificates signed using algorithms
194 other than those specified.
195 CertificateFile
197 Specifies a file from which the user's certificate is read. A
198 corresponding private key must be provided separately in order to
199 use this certificate either from an IdentityFile directive or -i
200 flag to ssh(1), via ssh-agent(1), or via a PKCS11Provider or
201 SecurityKeyProvider.
202 Arguments to CertificateFile may use the tilde syntax to refer to
204 a user's home directory, the tokens described in the TOKENS sec‐
205 tion and environment variables as described in the ENVIRONMENT
206 VARIABLES section.
207 It is possible to have multiple certificate files specified in
209 configuration files; these certificates will be tried in se‐
210 quence. Multiple CertificateFile directives will add to the list
211 of certificates used for authentication.
212 CheckHostIP
214 If set to yes, ssh(1) will additionally check the host IP address
215 in the known_hosts file. This allows it to detect if a host key
216 changed due to DNS spoofing and will add addresses of destination
217 hosts to ~/.ssh/known_hosts in the process, regardless of the
218 setting of StrictHostKeyChecking. If the option is set to no
219 (the default), the check will not be executed.
220 Ciphers
222 The default is handled system-wide by crypto-policies(7). Infor‐
223 mation about defaults, how to modify the defaults and how to cus‐
224 tomize existing policies with sub-policies are present in manual
225 page update-crypto-policies(8).
226 Specifies the ciphers allowed and their order of preference.
228 Multiple ciphers must be comma-separated. If the specified list
229 begins with a ‘+’ character, then the specified ciphers will be
230 appended to the built-in openssh default set instead of replacing
231 them. If the specified list begins with a ‘-’ character, then
232 the specified ciphers (including wildcards) will be removed from
233 the built-in openssh default set instead of replacing them. If
234 the specified list begins with a ‘^’ character, then the speci‐
235 fied ciphers will be placed at the head of the built-in openssh
236 default set.
237 The supported ciphers are:
239 3des-cbc
241 aes128-cbc
242 aes192-cbc
243 aes256-cbc
244 aes128-ctr
245 aes192-ctr
246 aes256-ctr
247 aes128-gcm@openssh.com
248 aes256-gcm@openssh.com
249 chacha20-poly1305@openssh.com
250 The list of available ciphers may also be obtained using "ssh -Q
252 cipher".
253 ClearAllForwardings
255 Specifies that all local, remote, and dynamic port forwardings
256 specified in the configuration files or on the command line be
257 cleared. This option is primarily useful when used from the
258 ssh(1) command line to clear port forwardings set in configura‐
259 tion files, and is automatically set by scp(1) and sftp(1). The
260 argument must be yes or no (the default).
261 Compression
263 Specifies whether to use compression. The argument must be yes
264 or no (the default).
265 ConnectionAttempts
267 Specifies the number of tries (one per second) to make before ex‐
268 iting. The argument must be an integer. This may be useful in
269 scripts if the connection sometimes fails. The default is 1.
270 ConnectTimeout
272 Specifies the timeout (in seconds) used when connecting to the
273 SSH server, instead of using the default system TCP timeout.
274 This timeout is applied both to establishing the connection and
275 to performing the initial SSH protocol handshake and key ex‐
276 change.
277 ControlMaster
279 Enables the sharing of multiple sessions over a single network
280 connection. When set to yes, ssh(1) will listen for connections
281 on a control socket specified using the ControlPath argument.
282 Additional sessions can connect to this socket using the same
283 ControlPath with ControlMaster set to no (the default). These
284 sessions will try to reuse the master instance's network connec‐
285 tion rather than initiating new ones, but will fall back to con‐
286 necting normally if the control socket does not exist, or is not
287 listening.
288 Setting this to ask will cause ssh(1) to listen for control con‐
290 nections, but require confirmation using ssh-askpass(1). If the
291 ControlPath cannot be opened, ssh(1) will continue without con‐
292 necting to a master instance.
293 X11 and ssh-agent(1) forwarding is supported over these multi‐
295 plexed connections, however the display and agent forwarded will
296 be the one belonging to the master connection i.e. it is not pos‐
297 sible to forward multiple displays or agents.
298 Two additional options allow for opportunistic multiplexing: try
300 to use a master connection but fall back to creating a new one if
301 one does not already exist. These options are: auto and autoask.
302 The latter requires confirmation like the ask option.
303 ControlPath
305 Specify the path to the control socket used for connection shar‐
306 ing as described in the ControlMaster section above or the string
307 none to disable connection sharing. Arguments to ControlPath may
308 use the tilde syntax to refer to a user's home directory, the to‐
309 kens described in the TOKENS section and environment variables as
310 described in the ENVIRONMENT VARIABLES section. It is recom‐
311 mended that any ControlPath used for opportunistic connection
312 sharing include at least %h, %p, and %r (or alternatively %C) and
313 be placed in a directory that is not writable by other users.
314 This ensures that shared connections are uniquely identified.
315 ControlPersist
317 When used in conjunction with ControlMaster, specifies that the
318 master connection should remain open in the background (waiting
319 for future client connections) after the initial client connec‐
320 tion has been closed. If set to no (the default), then the mas‐
321 ter connection will not be placed into the background, and will
322 close as soon as the initial client connection is closed. If set
323 to yes or 0, then the master connection will remain in the back‐
324 ground indefinitely (until killed or closed via a mechanism such
325 as the "ssh -O exit"). If set to a time in seconds, or a time in
326 any of the formats documented in sshd_config(5), then the back‐
327 grounded master connection will automatically terminate after it
328 has remained idle (with no client connections) for the specified
329 time.
330 DynamicForward
332 Specifies that a TCP port on the local machine be forwarded over
333 the secure channel, and the application protocol is then used to
334 determine where to connect to from the remote machine.
335 The argument must be [bind_address:]port. IPv6 addresses can be
337 specified by enclosing addresses in square brackets. By default,
338 the local port is bound in accordance with the GatewayPorts set‐
339 ting. However, an explicit bind_address may be used to bind the
340 connection to a specific address. The bind_address of localhost
341 indicates that the listening port be bound for local use only,
342 while an empty address or ‘*’ indicates that the port should be
343 available from all interfaces.
344 Currently the SOCKS4 and SOCKS5 protocols are supported, and
346 ssh(1) will act as a SOCKS server. Multiple forwardings may be
347 specified, and additional forwardings can be given on the command
348 line. Only the superuser can forward privileged ports.
349 EnableEscapeCommandline
351 Enables the command line option in the EscapeChar menu for inter‐
352 active sessions (default ‘~C’). By default, the command line is
353 disabled.
354 EnableSSHKeysign
356 Setting this option to yes in the global client configuration
357 file /etc/ssh/ssh_config enables the use of the helper program
358 ssh-keysign(8) during HostbasedAuthentication. The argument must
359 be yes or no (the default). This option should be placed in the
360 non-hostspecific section. See ssh-keysign(8) for more informa‐
361 tion.
362 EscapeChar
364 Sets the escape character (default: ‘~’). The escape character
365 can also be set on the command line. The argument should be a
366 single character, ‘^’ followed by a letter, or none to disable
367 the escape character entirely (making the connection transparent
368 for binary data).
369 ExitOnForwardFailure
371 Specifies whether ssh(1) should terminate the connection if it
372 cannot set up all requested dynamic, tunnel, local, and remote
373 port forwardings, (e.g. if either end is unable to bind and lis‐
374 ten on a specified port). Note that ExitOnForwardFailure does
375 not apply to connections made over port forwardings and will not,
376 for example, cause ssh(1) to exit if TCP connections to the ulti‐
377 mate forwarding destination fail. The argument must be yes or no
378 (the default).
379 FingerprintHash
381 Specifies the hash algorithm used when displaying key finger‐
382 prints. Valid options are: md5 and sha256 (the default).
383 ForkAfterAuthentication
385 Requests ssh to go to background just before command execution.
386 This is useful if ssh is going to ask for passwords or
387 passphrases, but the user wants it in the background. This im‐
388 plies the StdinNull configuration option being set to “yes”. The
389 recommended way to start X11 programs at a remote site is with
390 something like ssh -f host xterm, which is the same as ssh host
391 xterm if the ForkAfterAuthentication configuration option is set
392 to “yes”.
393 If the ExitOnForwardFailure configuration option is set to “yes”,
395 then a client started with the ForkAfterAuthentication configura‐
396 tion option being set to “yes” will wait for all remote port for‐
397 wards to be successfully established before placing itself in the
398 background. The argument to this keyword must be yes (same as
399 the -f option) or no (the default).
400 ForwardAgent
402 Specifies whether the connection to the authentication agent (if
403 any) will be forwarded to the remote machine. The argument may
404 be yes, no (the default), an explicit path to an agent socket or
405 the name of an environment variable (beginning with ‘$’) in which
406 to find the path.
407 Agent forwarding should be enabled with caution. Users with the
409 ability to bypass file permissions on the remote host (for the
410 agent's Unix-domain socket) can access the local agent through
411 the forwarded connection. An attacker cannot obtain key material
412 from the agent, however they can perform operations on the keys
413 that enable them to authenticate using the identities loaded into
414 the agent.
415 ForwardX11
417 Specifies whether X11 connections will be automatically redi‐
418 rected over the secure channel and DISPLAY set. The argument
419 must be yes or no (the default).
420 X11 forwarding should be enabled with caution. Users with the
422 ability to bypass file permissions on the remote host (for the
423 user's X11 authorization database) can access the local X11 dis‐
424 play through the forwarded connection. An attacker may then be
425 able to perform activities such as keystroke monitoring if the
426 ForwardX11Trusted option is also enabled.
427 ForwardX11Timeout
429 Specify a timeout for untrusted X11 forwarding using the format
430 described in the TIME FORMATS section of sshd_config(5). X11
431 connections received by ssh(1) after this time will be refused.
432 Setting ForwardX11Timeout to zero will disable the timeout and
433 permit X11 forwarding for the life of the connection. The de‐
434 fault is to disable untrusted X11 forwarding after twenty minutes
435 has elapsed.
436 ForwardX11Trusted
438 If this option is set to yes, remote X11 clients will have full
439 access to the original X11 display.
440 If this option is set to no (the default), remote X11 clients
442 will be considered untrusted and prevented from stealing or tam‐
443 pering with data belonging to trusted X11 clients. Furthermore,
444 the xauth(1) token used for the session will be set to expire af‐
445 ter 20 minutes. Remote clients will be refused access after this
446 time.
447 See the X11 SECURITY extension specification for full details on
449 the restrictions imposed on untrusted clients.
450 GatewayPorts
452 Specifies whether remote hosts are allowed to connect to local
453 forwarded ports. By default, ssh(1) binds local port forwardings
454 to the loopback address. This prevents other remote hosts from
455 connecting to forwarded ports. GatewayPorts can be used to spec‐
456 ify that ssh should bind local port forwardings to the wildcard
457 address, thus allowing remote hosts to connect to forwarded
458 ports. The argument must be yes or no (the default).
459 GlobalKnownHostsFile
461 Specifies one or more files to use for the global host key data‐
462 base, separated by whitespace. The default is
463 /etc/ssh/ssh_known_hosts, /etc/ssh/ssh_known_hosts2.
464 GSSAPIAuthentication
466 Specifies whether user authentication based on GSSAPI is allowed.
467 The default is no.
468 GSSAPIClientIdentity
470 If set, specifies the GSSAPI client identity that ssh should use
471 when connecting to the server. The default is unset, which means
472 that the default identity will be used.
473 GSSAPIDelegateCredentials
475 Forward (delegate) credentials to the server. The default is no.
476 GSSAPIKeyExchange
478 Specifies whether key exchange based on GSSAPI may be used. When
479 using GSSAPI key exchange the server need not have a host key.
480 The default is “no”.
481 GSSAPIRenewalForcesRekey
483 If set to “yes” then renewal of the client's GSSAPI credentials
484 will force the rekeying of the ssh connection. With a compatible
485 server, this will delegate the renewed credentials to a session
486 on the server.
487 Checks are made to ensure that credentials are only propagated
489 when the new credentials match the old ones on the originating
490 client and where the receiving server still has the old set in
491 its cache.
492 The default is “no”.
494 For this to work GSSAPIKeyExchange needs to be enabled in the
496 server and also used by the client.
497 GSSAPIServerIdentity
499 If set, specifies the GSSAPI server identity that ssh should ex‐
500 pect when connecting to the server. The default is unset, which
501 means that the expected GSSAPI server identity will be determined
502 from the target hostname.
503 GSSAPITrustDns
505 Set to “yes” to indicate that the DNS is trusted to securely
506 canonicalize the name of the host being connected to. If “no”,
507 the hostname entered on the command line will be passed untouched
508 to the GSSAPI library. The default is “no”.
509 GSSAPIKexAlgorithms
511 The default is handled system-wide by crypto-policies(7). Infor‐
512 mation about defaults, how to modify the defaults and how to cus‐
513 tomize existing policies with sub-policies are present in manual
514 page update-crypto-policies(8).
515 The list of key exchange algorithms that are offered for GSSAPI
517 key exchange. Possible values are
518 gss-gex-sha1-,
520 gss-group1-sha1-,
521 gss-group14-sha1-,
522 gss-group14-sha256-,
523 gss-group16-sha512-,
524 gss-nistp256-sha256-,
525 gss-curve25519-sha256-
526 This option only applies to connections using GSSAPI.
528 HashKnownHosts
530 Indicates that ssh(1) should hash host names and addresses when
531 they are added to ~/.ssh/known_hosts. These hashed names may be
532 used normally by ssh(1) and sshd(8), but they do not visually re‐
533 veal identifying information if the file's contents are dis‐
534 closed. The default is no. Note that existing names and ad‐
535 dresses in known hosts files will not be converted automatically,
536 but may be manually hashed using ssh-keygen(1).
537 HostbasedAcceptedAlgorithms
539 The default is handled system-wide by crypto-policies(7). Infor‐
540 mation about defaults, how to modify the defaults and how to cus‐
541 tomize existing policies with sub-policies are present in manual
542 page update-crypto-policies(8).
543 Specifies the signature algorithms that will be used for host‐
545 based authentication as a comma-separated list of patterns. Al‐
546 ternately if the specified list begins with a ‘+’ character, then
547 the specified signature algorithms will be appended to the built-
548 in openssh default set instead of replacing them. If the speci‐
549 fied list begins with a ‘-’ character, then the specified signa‐
550 ture algorithms (including wildcards) will be removed from the
551 built-in openssh default set instead of replacing them. If the
552 specified list begins with a ‘^’ character, then the specified
553 signature algorithms will be placed at the head of the built-in
554 openssh default set.
555 The -Q option of ssh(1) may be used to list supported signature
557 algorithms. This was formerly named HostbasedKeyTypes.
558 HostbasedAuthentication
560 Specifies whether to try rhosts based authentication with public
561 key authentication. The argument must be yes or no (the de‐
562 fault).
563 HostKeyAlgorithms
565 Specifies the host key signature algorithms that the client wants
566 to use in order of preference. Alternately if the specified list
567 begins with a ‘+’ character, then the specified signature algo‐
568 rithms will be appended to the default set instead of replacing
569 them. If the specified list begins with a ‘-’ character, then
570 the specified signature algorithms (including wildcards) will be
571 removed from the default set instead of replacing them. If the
572 specified list begins with a ‘^’ character, then the specified
573 signature algorithms will be placed at the head of the default
574 set. The default for this option is:
575 ssh-ed25519-cert-v01@openssh.com,
577 ecdsa-sha2-nistp256-cert-v01@openssh.com,
578 ecdsa-sha2-nistp384-cert-v01@openssh.com,
579 ecdsa-sha2-nistp521-cert-v01@openssh.com,
580 sk-ssh-ed25519-cert-v01@openssh.com,
581 sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
582 rsa-sha2-512-cert-v01@openssh.com,
583 rsa-sha2-256-cert-v01@openssh.com,
584 ssh-ed25519,
585 ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
586 sk-ecdsa-sha2-nistp256@openssh.com,
587 sk-ssh-ed25519@openssh.com,
588 rsa-sha2-512,rsa-sha2-256
589 If hostkeys are known for the destination host then this default
591 is modified to prefer their algorithms.
592 The list of available signature algorithms may also be obtained
594 using "ssh -Q HostKeyAlgorithms".
595 The proposed HostKeyAlgorithms during KEX are limited to the set
597 of algorithms that is defined in PubkeyAcceptedAlgorithms and
598 therefore they are indirectly affected by system-wide
599 crypto_policies(7). crypto_policies(7) can not handle the list
600 of host key algorithms directly as doing so would break the order
601 given by the known_hosts file.
602 HostKeyAlias
604 Specifies an alias that should be used instead of the real host
605 name when looking up or saving the host key in the host key data‐
606 base files and when validating host certificates. This option is
607 useful for tunneling SSH connections or for multiple servers run‐
608 ning on a single host.
609 Hostname
611 Specifies the real host name to log into. This can be used to
612 specify nicknames or abbreviations for hosts. Arguments to
613 Hostname accept the tokens described in the TOKENS section. Nu‐
614 meric IP addresses are also permitted (both on the command line
615 and in Hostname specifications). The default is the name given
616 on the command line.
617 IdentitiesOnly
619 Specifies that ssh(1) should only use the configured authentica‐
620 tion identity and certificate files (either the default files, or
621 those explicitly configured in the ssh_config files or passed on
622 the ssh(1) command-line), even if ssh-agent(1) or a
623 PKCS11Provider or SecurityKeyProvider offers more identities.
624 The argument to this keyword must be yes or no (the default).
625 This option is intended for situations where ssh-agent offers
626 many different identities.
627 IdentityAgent
629 Specifies the UNIX-domain socket used to communicate with the au‐
630 thentication agent.
631 This option overrides the SSH_AUTH_SOCK environment variable and
633 can be used to select a specific agent. Setting the socket name
634 to none disables the use of an authentication agent. If the
635 string "SSH_AUTH_SOCK" is specified, the location of the socket
636 will be read from the SSH_AUTH_SOCK environment variable. Other‐
637 wise if the specified value begins with a ‘$’ character, then it
638 will be treated as an environment variable containing the loca‐
639 tion of the socket.
640 Arguments to IdentityAgent may use the tilde syntax to refer to a
642 user's home directory, the tokens described in the TOKENS section
643 and environment variables as described in the ENVIRONMENT
644 VARIABLES section.
645 IdentityFile
647 Specifies a file from which the user's DSA, ECDSA, authenticator-
648 hosted ECDSA, Ed25519, authenticator-hosted Ed25519 or RSA au‐
649 thentication identity is read. You can also specify a public key
650 file to use the corresponding private key that is loaded in
651 ssh-agent(1) when the private key file is not present locally.
652 The default is ~/.ssh/id_rsa, ~/.ssh/id_ecdsa,
653 ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk and
654 ~/.ssh/id_dsa. Additionally, any identities represented by the
655 authentication agent will be used for authentication unless
656 IdentitiesOnly is set. If no certificates have been explicitly
657 specified by CertificateFile, ssh(1) will try to load certificate
658 information from the filename obtained by appending -cert.pub to
659 the path of a specified IdentityFile.
660 Arguments to IdentityFile may use the tilde syntax to refer to a
662 user's home directory or the tokens described in the TOKENS sec‐
663 tion.
664 It is possible to have multiple identity files specified in con‐
666 figuration files; all these identities will be tried in sequence.
667 Multiple IdentityFile directives will add to the list of identi‐
668 ties tried (this behaviour differs from that of other configura‐
669 tion directives).
670 IdentityFile may be used in conjunction with IdentitiesOnly to
672 select which identities in an agent are offered during authenti‐
673 cation. IdentityFile may also be used in conjunction with
674 CertificateFile in order to provide any certificate also needed
675 for authentication with the identity.
676 The authentication identity can be also specified in a form of
678 PKCS#11 URI starting with a string pkcs11:. There is supported a
679 subset of the PKCS#11 URI as defined in RFC 7512 (implemented
680 path arguments id, manufacturer, object, token and query argu‐
681 ments module-path and pin-value ). The URI can not be in quotes.
682 IgnoreUnknown
684 Specifies a pattern-list of unknown options to be ignored if they
685 are encountered in configuration parsing. This may be used to
686 suppress errors if ssh_config contains options that are unrecog‐
687 nised by ssh(1). It is recommended that IgnoreUnknown be listed
688 early in the configuration file as it will not be applied to un‐
689 known options that appear before it.
690 Include
692 Include the specified configuration file(s). Multiple pathnames
693 may be specified and each pathname may contain glob(7) wildcards
694 and, for user configurations, shell-like ‘~’ references to user
695 home directories. Wildcards will be expanded and processed in
696 lexical order. Files without absolute paths are assumed to be in
697 ~/.ssh if included in a user configuration file or /etc/ssh if
698 included from the system configuration file. Include directive
699 may appear inside a Match or Host block to perform conditional
700 inclusion.
701 IPQoS Specifies the IPv4 type-of-service or DSCP class for connections.
703 Accepted values are af11, af12, af13, af21, af22, af23, af31,
704 af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5, cs6,
705 cs7, ef, le, lowdelay, throughput, reliability, a numeric value,
706 or none to use the operating system default. This option may
707 take one or two arguments, separated by whitespace. If one argu‐
708 ment is specified, it is used as the packet class uncondition‐
709 ally. If two values are specified, the first is automatically
710 selected for interactive sessions and the second for non-interac‐
711 tive sessions. The default is af21 (Low-Latency Data) for inter‐
712 active sessions and cs1 (Lower Effort) for non-interactive ses‐
713 sions.
714 KbdInteractiveAuthentication
716 Specifies whether to use keyboard-interactive authentication.
717 The argument to this keyword must be yes (the default) or no.
718 ChallengeResponseAuthentication is a deprecated alias for this.
719 KbdInteractiveDevices
721 Specifies the list of methods to use in keyboard-interactive au‐
722 thentication. Multiple method names must be comma-separated.
723 The default is to use the server specified list. The methods
724 available vary depending on what the server supports. For an
725 OpenSSH server, it may be zero or more of: bsdauth and pam.
726 KexAlgorithms
728 The default is handled system-wide by crypto-policies(7). Infor‐
729 mation about defaults, how to modify the defaults and how to cus‐
730 tomize existing policies with sub-policies are present in manual
731 page update-crypto-policies(8).
732 Specifies the available KEX (Key Exchange) algorithms. Multiple
734 algorithms must be comma-separated. If the specified list begins
735 with a ‘+’ character, then the specified methods will be appended
736 to the built-in openssh default set instead of replacing them.
737 If the specified list begins with a ‘-’ character, then the spec‐
738 ified algorithms (including wildcards) will be removed from the
739 built-in openssh default set instead of replacing them. If the
740 specified list begins with a ‘^’ character, then the specified
741 algorithms will be placed at the head of the built-in openssh de‐
742 fault set.
743 The list of available key exchange algorithms may also be ob‐
745 tained using "ssh -Q kex".
746 KnownHostsCommand
748 Specifies a command to use to obtain a list of host keys, in ad‐
749 dition to those listed in UserKnownHostsFile and
750 GlobalKnownHostsFile. This command is executed after the files
751 have been read. It may write host key lines to standard output
752 in identical format to the usual files (described in the
753 VERIFYING HOST KEYS section in ssh(1)). Arguments to
754 KnownHostsCommand accept the tokens described in the TOKENS sec‐
755 tion. The command may be invoked multiple times per connection:
756 once when preparing the preference list of host key algorithms to
757 use, again to obtain the host key for the requested host name
758 and, if CheckHostIP is enabled, one more time to obtain the host
759 key matching the server's address. If the command exits abnor‐
760 mally or returns a non-zero exit status then the connection is
761 terminated.
762 LocalCommand
764 Specifies a command to execute on the local machine after suc‐
765 cessfully connecting to the server. The command string extends
766 to the end of the line, and is executed with the user's shell.
767 Arguments to LocalCommand accept the tokens described in the
768 TOKENS section.
769 The command is run synchronously and does not have access to the
771 session of the ssh(1) that spawned it. It should not be used for
772 interactive commands.
773 This directive is ignored unless PermitLocalCommand has been en‐
775 abled.
776 LocalForward
778 Specifies that a TCP port on the local machine be forwarded over
779 the secure channel to the specified host and port from the remote
780 machine. The first argument specifies the listener and may be
781 [bind_address:]port or a Unix domain socket path. The second ar‐
782 gument is the destination and may be host:hostport or a Unix do‐
783 main socket path if the remote host supports it.
784 IPv6 addresses can be specified by enclosing addresses in square
786 brackets. Multiple forwardings may be specified, and additional
787 forwardings can be given on the command line. Only the superuser
788 can forward privileged ports. By default, the local port is
789 bound in accordance with the GatewayPorts setting. However, an
790 explicit bind_address may be used to bind the connection to a
791 specific address. The bind_address of localhost indicates that
792 the listening port be bound for local use only, while an empty
793 address or ‘*’ indicates that the port should be available from
794 all interfaces. Unix domain socket paths may use the tokens de‐
795 scribed in the TOKENS section and environment variables as de‐
796 scribed in the ENVIRONMENT VARIABLES section.
797 LogLevel
799 Gives the verbosity level that is used when logging messages from
800 ssh(1). The possible values are: QUIET, FATAL, ERROR, INFO, VER‐
801 BOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO.
802 DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify
803 higher levels of verbose output.
804 LogVerbose
806 Specify one or more overrides to LogLevel. An override consists
807 of a pattern lists that matches the source file, function and
808 line number to force detailed logging for. For example, an over‐
809 ride pattern of:
810 kex.c:*:1000,*:kex_exchange_identification():*,packet.c:*
812 would enable detailed logging for line 1000 of kex.c, everything
814 in the kex_exchange_identification() function, and all code in
815 the packet.c file. This option is intended for debugging and no
816 overrides are enabled by default.
817 MACs The default is handled system-wide by crypto-policies(7). Infor‐
819 mation about defaults, how to modify the defaults and how to cus‐
820 tomize existing policies with sub-policies are present in manual
821 page update-crypto-policies(8).
822 Specifies the MAC (message authentication code) algorithms in or‐
824 der of preference. The MAC algorithm is used for data integrity
825 protection. Multiple algorithms must be comma-separated. If the
826 specified list begins with a ‘+’ character, then the specified
827 algorithms will be appended to the built-in openssh default set
828 instead of replacing them. If the specified list begins with a
829 ‘-’ character, then the specified algorithms (including wild‐
830 cards) will be removed from the built-in openssh default set in‐
831 stead of replacing them. If the specified list begins with a ‘^’
832 character, then the specified algorithms will be placed at the
833 head of the built-in openssh default set.
834 The algorithms that contain "-etm" calculate the MAC after en‐
836 cryption (encrypt-then-mac). These are considered safer and
837 their use recommended.
838 The list of available MAC algorithms may also be obtained using
840 "ssh -Q mac".
841 NoHostAuthenticationForLocalhost
843 Disable host authentication for localhost (loopback addresses).
844 The argument to this keyword must be yes or no (the default).
845 NumberOfPasswordPrompts
847 Specifies the number of password prompts before giving up. The
848 argument to this keyword must be an integer. The default is 3.
849 PasswordAuthentication
851 Specifies whether to use password authentication. The argument
852 to this keyword must be yes (the default) or no.
853 PermitLocalCommand
855 Allow local command execution via the LocalCommand option or us‐
856 ing the !command escape sequence in ssh(1). The argument must be
857 yes or no (the default).
858 PermitRemoteOpen
860 Specifies the destinations to which remote TCP port forwarding is
861 permitted when RemoteForward is used as a SOCKS proxy. The for‐
862 warding specification must be one of the following forms:
863 PermitRemoteOpen host:port
865 PermitRemoteOpen IPv4_addr:port
866 PermitRemoteOpen [IPv6_addr]:port
867 Multiple forwards may be specified by separating them with white‐
869 space. An argument of any can be used to remove all restrictions
870 and permit any forwarding requests. An argument of none can be
871 used to prohibit all forwarding requests. The wildcard ‘*’ can
872 be used for host or port to allow all hosts or ports respec‐
873 tively. Otherwise, no pattern matching or address lookups are
874 performed on supplied names.
875 PKCS11Provider
877 Specifies which PKCS#11 provider to use or none to indicate that
878 no provider should be used (the default). The argument to this
879 keyword is a path to the PKCS#11 shared library ssh(1) should use
880 to communicate with a PKCS#11 token providing keys for user au‐
881 thentication.
882 Port Specifies the port number to connect on the remote host. The de‐
884 fault is 22.
885 PreferredAuthentications
887 Specifies the order in which the client should try authentication
888 methods. This allows a client to prefer one method (e.g.
889 keyboard-interactive) over another method (e.g. password). The
890 default is:
891 gssapi-with-mic,hostbased,publickey,
893 keyboard-interactive,password
894 ProxyCommand
896 Specifies the command to use to connect to the server. The com‐
897 mand string extends to the end of the line, and is executed using
898 the user's shell ‘exec’ directive to avoid a lingering shell
899 process.
900 Arguments to ProxyCommand accept the tokens described in the
902 TOKENS section. The command can be basically anything, and
903 should read from its standard input and write to its standard
904 output. It should eventually connect an sshd(8) server running
905 on some machine, or execute sshd -i somewhere. Host key manage‐
906 ment will be done using the Hostname of the host being connected
907 (defaulting to the name typed by the user). Setting the command
908 to none disables this option entirely. Note that CheckHostIP is
909 not available for connects with a proxy command.
910 This directive is useful in conjunction with nc(1) and its proxy
912 support. For example, the following directive would connect via
913 an HTTP proxy at 192.0.2.0:
914 ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p
916 ProxyJump
918 Specifies one or more jump proxies as either [user@]host[:port]
919 or an ssh URI. Multiple proxies may be separated by comma char‐
920 acters and will be visited sequentially. Setting this option
921 will cause ssh(1) to connect to the target host by first making a
922 ssh(1) connection to the specified ProxyJump host and then estab‐
923 lishing a TCP forwarding to the ultimate target from there. Set‐
924 ting the host to none disables this option entirely.
925 Note that this option will compete with the ProxyCommand option -
927 whichever is specified first will prevent later instances of the
928 other from taking effect.
929 Note also that the configuration for the destination host (either
931 supplied via the command-line or the configuration file) is not
932 generally applied to jump hosts. ~/.ssh/config should be used if
933 specific configuration is required for jump hosts.
934 ProxyUseFdpass
936 Specifies that ProxyCommand will pass a connected file descriptor
937 back to ssh(1) instead of continuing to execute and pass data.
938 The default is no.
939 PubkeyAcceptedAlgorithms
941 The default is handled system-wide by crypto-policies(7). Infor‐
942 mation about defaults, how to modify the defaults and how to cus‐
943 tomize existing policies with sub-policies are present in manual
944 page update-crypto-policies(8).
945 Specifies the signature algorithms that will be used for public
947 key authentication as a comma-separated list of patterns. If the
948 specified list begins with a ‘+’ character, then the algorithms
949 after it will be appended to the built-in openssh default instead
950 of replacing it. If the specified list begins with a ‘-’ charac‐
951 ter, then the specified algorithms (including wildcards) will be
952 removed from the built-in openssh default set instead of replac‐
953 ing them. If the specified list begins with a ‘^’ character,
954 then the specified algorithms will be placed at the head of the
955 built-in openssh default set.
956 The list of available signature algorithms may also be obtained
958 using "ssh -Q PubkeyAcceptedAlgorithms".
959 This option affects also HostKeyAlgorithms
961 PubkeyAuthentication
963 Specifies whether to try public key authentication. The argument
964 to this keyword must be yes (the default), no, unbound or
965 host-bound. The final two options enable public key authentica‐
966 tion while respectively disabling or enabling the OpenSSH host-
967 bound authentication protocol extension required for restricted
968 ssh-agent(1) forwarding.
969 RekeyLimit
971 Specifies the maximum amount of data that may be transmitted or
972 received before the session key is renegotiated, optionally fol‐
973 lowed by a maximum amount of time that may pass before the ses‐
974 sion key is renegotiated. The first argument is specified in
975 bytes and may have a suffix of ‘K’, ‘M’, or ‘G’ to indicate Kilo‐
976 bytes, Megabytes, or Gigabytes, respectively. The default is be‐
977 tween ‘1G’ and ‘4G’, depending on the cipher. The optional sec‐
978 ond value is specified in seconds and may use any of the units
979 documented in the TIME FORMATS section of sshd_config(5). The
980 default value for RekeyLimit is default none, which means that
981 rekeying is performed after the cipher's default amount of data
982 has been sent or received and no time based rekeying is done.
983 RemoteCommand
985 Specifies a command to execute on the remote machine after suc‐
986 cessfully connecting to the server. The command string extends
987 to the end of the line, and is executed with the user's shell.
988 Arguments to RemoteCommand accept the tokens described in the
989 TOKENS section.
990 RemoteForward
992 Specifies that a TCP port on the remote machine be forwarded over
993 the secure channel. The remote port may either be forwarded to a
994 specified host and port from the local machine, or may act as a
995 SOCKS 4/5 proxy that allows a remote client to connect to arbi‐
996 trary destinations from the local machine. The first argument is
997 the listening specification and may be [bind_address:]port or, if
998 the remote host supports it, a Unix domain socket path. If for‐
999 warding to a specific destination then the second argument must
1000 be host:hostport or a Unix domain socket path, otherwise if no
1001 destination argument is specified then the remote forwarding will
1002 be established as a SOCKS proxy. When acting as a SOCKS proxy,
1003 the destination of the connection can be restricted by
1004 PermitRemoteOpen.
1005 IPv6 addresses can be specified by enclosing addresses in square
1007 brackets. Multiple forwardings may be specified, and additional
1008 forwardings can be given on the command line. Privileged ports
1009 can be forwarded only when logging in as root on the remote ma‐
1010 chine. Unix domain socket paths may use the tokens described in
1011 the TOKENS section and environment variables as described in the
1012 ENVIRONMENT VARIABLES section.
1013 If the port argument is 0, the listen port will be dynamically
1015 allocated on the server and reported to the client at run time.
1016 If the bind_address is not specified, the default is to only bind
1018 to loopback addresses. If the bind_address is ‘*’ or an empty
1019 string, then the forwarding is requested to listen on all inter‐
1020 faces. Specifying a remote bind_address will only succeed if the
1021 server's GatewayPorts option is enabled (see sshd_config(5)).
1022 RequestTTY
1024 Specifies whether to request a pseudo-tty for the session. The
1025 argument may be one of: no (never request a TTY), yes (always re‐
1026 quest a TTY when standard input is a TTY), force (always request
1027 a TTY) or auto (request a TTY when opening a login session).
1028 This option mirrors the -t and -T flags for ssh(1).
1029 RequiredRSASize
1031 Specifies the minimum RSA key size (in bits) that ssh(1) will ac‐
1032 cept. User authentication keys smaller than this limit will be
1033 ignored. Servers that present host keys smaller than this limit
1034 will cause the connection to be terminated. The default is 1024
1035 bits. Note that this limit may only be raised from the default.
1036 RevokedHostKeys
1038 Specifies revoked host public keys. Keys listed in this file
1039 will be refused for host authentication. Note that if this file
1040 does not exist or is not readable, then host authentication will
1041 be refused for all hosts. Keys may be specified as a text file,
1042 listing one public key per line, or as an OpenSSH Key Revocation
1043 List (KRL) as generated by ssh-keygen(1). For more information
1044 on KRLs, see the KEY REVOCATION LISTS section in ssh-keygen(1).
1045 SecurityKeyProvider
1047 Specifies a path to a library that will be used when loading any
1048 FIDO authenticator-hosted keys, overriding the default of using
1049 the built-in USB HID support.
1050 If the specified value begins with a ‘$’ character, then it will
1052 be treated as an environment variable containing the path to the
1053 library.
1054 SendEnv
1056 Specifies what variables from the local environ(7) should be sent
1057 to the server. The server must also support it, and the server
1058 must be configured to accept these environment variables. Note
1059 that the TERM environment variable is always sent whenever a
1060 pseudo-terminal is requested as it is required by the protocol.
1061 Refer to AcceptEnv in sshd_config(5) for how to configure the
1062 server. Variables are specified by name, which may contain wild‐
1063 card characters. Multiple environment variables may be separated
1064 by whitespace or spread across multiple SendEnv directives.
1065 See PATTERNS for more information on patterns.
1067 It is possible to clear previously set SendEnv variable names by
1069 prefixing patterns with -. The default is not to send any envi‐
1070 ronment variables.
1071 ServerAliveCountMax
1073 Sets the number of server alive messages (see below) which may be
1074 sent without ssh(1) receiving any messages back from the server.
1075 If this threshold is reached while server alive messages are be‐
1076 ing sent, ssh will disconnect from the server, terminating the
1077 session. It is important to note that the use of server alive
1078 messages is very different from TCPKeepAlive (below). The server
1079 alive messages are sent through the encrypted channel and there‐
1080 fore will not be spoofable. The TCP keepalive option enabled by
1081 TCPKeepAlive is spoofable. The server alive mechanism is valu‐
1082 able when the client or server depend on knowing when a connec‐
1083 tion has become unresponsive.
1084 The default value is 3. If, for example, ServerAliveInterval
1086 (see below) is set to 15 and ServerAliveCountMax is left at the
1087 default, if the server becomes unresponsive, ssh will disconnect
1088 after approximately 45 seconds.
1089 ServerAliveInterval
1091 Sets a timeout interval in seconds after which if no data has
1092 been received from the server, ssh(1) will send a message through
1093 the encrypted channel to request a response from the server. The
1094 default is 0, indicating that these messages will not be sent to
1095 the server.
1096 SessionType
1098 May be used to either request invocation of a subsystem on the
1099 remote system, or to prevent the execution of a remote command at
1100 all. The latter is useful for just forwarding ports. The argu‐
1101 ment to this keyword must be none (same as the -N option),
1102 subsystem (same as the -s option) or default (shell or command
1103 execution).
1104 SetEnv Directly specify one or more environment variables and their con‐
1106 tents to be sent to the server. Similarly to SendEnv, with the
1107 exception of the TERM variable, the server must be prepared to
1108 accept the environment variable.
1109 StdinNull
1111 Redirects stdin from /dev/null (actually, prevents reading from
1112 stdin). Either this or the equivalent -n option must be used
1113 when ssh is run in the background. The argument to this keyword
1114 must be yes (same as the -n option) or no (the default).
1115 StreamLocalBindMask
1117 Sets the octal file creation mode mask (umask) used when creating
1118 a Unix-domain socket file for local or remote port forwarding.
1119 This option is only used for port forwarding to a Unix-domain
1120 socket file.
1121 The default value is 0177, which creates a Unix-domain socket
1123 file that is readable and writable only by the owner. Note that
1124 not all operating systems honor the file mode on Unix-domain
1125 socket files.
1126 StreamLocalBindUnlink
1128 Specifies whether to remove an existing Unix-domain socket file
1129 for local or remote port forwarding before creating a new one.
1130 If the socket file already exists and StreamLocalBindUnlink is
1131 not enabled, ssh will be unable to forward the port to the Unix-
1132 domain socket file. This option is only used for port forwarding
1133 to a Unix-domain socket file.
1134 The argument must be yes or no (the default).
1136 StrictHostKeyChecking
1138 If this flag is set to yes, ssh(1) will never automatically add
1139 host keys to the ~/.ssh/known_hosts file, and refuses to connect
1140 to hosts whose host key has changed. This provides maximum pro‐
1141 tection against man-in-the-middle (MITM) attacks, though it can
1142 be annoying when the /etc/ssh/ssh_known_hosts file is poorly
1143 maintained or when connections to new hosts are frequently made.
1144 This option forces the user to manually add all new hosts.
1145 If this flag is set to accept-new then ssh will automatically add
1147 new host keys to the user's known_hosts file, but will not permit
1148 connections to hosts with changed host keys. If this flag is set
1149 to no or off, ssh will automatically add new host keys to the
1150 user known hosts files and allow connections to hosts with
1151 changed hostkeys to proceed, subject to some restrictions. If
1152 this flag is set to ask (the default), new host keys will be
1153 added to the user known host files only after the user has con‐
1154 firmed that is what they really want to do, and ssh will refuse
1155 to connect to hosts whose host key has changed. The host keys of
1156 known hosts will be verified automatically in all cases.
1157 SyslogFacility
1159 Gives the facility code that is used when logging messages from
1160 ssh(1). The possible values are: DAEMON, USER, AUTH, LOCAL0, LO‐
1161 CAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The de‐
1162 fault is USER.
1163 TCPKeepAlive
1165 Specifies whether the system should send TCP keepalive messages
1166 to the other side. If they are sent, death of the connection or
1167 crash of one of the machines will be properly noticed. However,
1168 this means that connections will die if the route is down tempo‐
1169 rarily, and some people find it annoying.
1170 The default is yes (to send TCP keepalive messages), and the
1172 client will notice if the network goes down or the remote host
1173 dies. This is important in scripts, and many users want it too.
1174 To disable TCP keepalive messages, the value should be set to no.
1176 See also ServerAliveInterval for protocol-level keepalives.
1177 Tunnel Request tun(4) device forwarding between the client and the
1179 server. The argument must be yes, point-to-point (layer 3),
1180 ethernet (layer 2), or no (the default). Specifying yes requests
1181 the default tunnel mode, which is point-to-point.
1182 TunnelDevice
1184 Specifies the tun(4) devices to open on the client (local_tun)
1185 and the server (remote_tun).
1186 The argument must be local_tun[:remote_tun]. The devices may be
1188 specified by numerical ID or the keyword any, which uses the next
1189 available tunnel device. If remote_tun is not specified, it de‐
1190 faults to any. The default is any:any.
1191 UpdateHostKeys
1193 Specifies whether ssh(1) should accept notifications of addi‐
1194 tional hostkeys from the server sent after authentication has
1195 completed and add them to UserKnownHostsFile. The argument must
1196 be yes, no or ask. This option allows learning alternate
1197 hostkeys for a server and supports graceful key rotation by al‐
1198 lowing a server to send replacement public keys before old ones
1199 are removed.
1200 Additional hostkeys are only accepted if the key used to authen‐
1202 ticate the host was already trusted or explicitly accepted by the
1203 user, the host was authenticated via UserKnownHostsFile (i.e. not
1204 GlobalKnownHostsFile) and the host was authenticated using a
1205 plain key and not a certificate.
1206 UpdateHostKeys is enabled by default if the user has not overrid‐
1208 den the default UserKnownHostsFile setting and has not enabled
1209 VerifyHostKeyDNS, otherwise UpdateHostKeys will be set to no.
1210 If UpdateHostKeys is set to ask, then the user is asked to con‐
1212 firm the modifications to the known_hosts file. Confirmation is
1213 currently incompatible with ControlPersist, and will be disabled
1214 if it is enabled.
1215 Presently, only sshd(8) from OpenSSH 6.8 and greater support the
1217 "hostkeys@openssh.com" protocol extension used to inform the
1218 client of all the server's hostkeys.
1219 User Specifies the user to log in as. This can be useful when a dif‐
1221 ferent user name is used on different machines. This saves the
1222 trouble of having to remember to give the user name on the com‐
1223 mand line.
1224 UserKnownHostsFile
1226 Specifies one or more files to use for the user host key data‐
1227 base, separated by whitespace. Each filename may use tilde nota‐
1228 tion to refer to the user's home directory, the tokens described
1229 in the TOKENS section and environment variables as described in
1230 the ENVIRONMENT VARIABLES section. A value of none causes ssh(1)
1231 to ignore any user-specific known hosts files. The default is
1232 ~/.ssh/known_hosts, ~/.ssh/known_hosts2.
1233 VerifyHostKeyDNS
1235 Specifies whether to verify the remote key using DNS and SSHFP
1236 resource records. If this option is set to yes, the client will
1237 implicitly trust keys that match a secure fingerprint from DNS.
1238 Insecure fingerprints will be handled as if this option was set
1239 to ask. If this option is set to ask, information on fingerprint
1240 match will be displayed, but the user will still need to confirm
1241 new host keys according to the StrictHostKeyChecking option. The
1242 default is no.
1243 See also VERIFYING HOST KEYS in ssh(1).
1245 VisualHostKey
1247 If this flag is set to yes, an ASCII art representation of the
1248 remote host key fingerprint is printed in addition to the finger‐
1249 print string at login and for unknown host keys. If this flag is
1250 set to no (the default), no fingerprint strings are printed at
1251 login and only the fingerprint string will be printed for unknown
1252 host keys.
1253 XAuthLocation
1255 Specifies the full pathname of the xauth(1) program. The default
1256 is /usr/bin/xauth.
1257
1259 A pattern consists of zero or more non-whitespace characters, ‘*’ (a
1260 wildcard that matches zero or more characters), or ‘?’ (a wildcard that
1261 matches exactly one character). For example, to specify a set of decla‐
1262 rations for any host in the ".co.uk" set of domains, the following pat‐
1263 tern could be used:
1264 Host *.co.uk
1266 The following pattern would match any host in the 192.168.0.[0-9] network
1268 range:
1269 Host 192.168.0.?
1271 A pattern-list is a comma-separated list of patterns. Patterns within
1273 pattern-lists may be negated by preceding them with an exclamation mark
1274 (‘!’). For example, to allow a key to be used from anywhere within an
1275 organization except from the "dialup" pool, the following entry (in au‐
1276 thorized_keys) could be used:
1277 from="!*.dialup.example.com,*.example.com"
1279 Note that a negated match will never produce a positive result by itself.
1281 For example, attempting to match "host3" against the following pattern-
1282 list will fail:
1283 from="!host1,!host2"
1285 The solution here is to include a term that will yield a positive match,
1287 such as a wildcard:
1288 from="!host1,!host2,*"
1290
1292 Arguments to some keywords can make use of tokens, which are expanded at
1293 runtime:
1294 %% A literal ‘%’.
1296 %C Hash of %l%h%p%r.
1297 %d Local user's home directory.
1298 %f The fingerprint of the server's host key.
1299 %H The known_hosts hostname or address that is being searched
1300 for.
1301 %h The remote hostname.
1302 %I A string describing the reason for a KnownHostsCommand execu‐
1303 tion: either ADDRESS when looking up a host by address (only
1304 when CheckHostIP is enabled), HOSTNAME when searching by
1305 hostname, or ORDER when preparing the host key algorithm
1306 preference list to use for the destination host.
1307 %i The local user ID.
1308 %K The base64 encoded host key.
1309 %k The host key alias if specified, otherwise the original re‐
1310 mote hostname given on the command line.
1311 %L The local hostname.
1312 %l The local hostname, including the domain name.
1313 %n The original remote hostname, as given on the command line.
1314 %p The remote port.
1315 %r The remote username.
1316 %T The local tun(4) or tap(4) network interface assigned if tun‐
1317 nel forwarding was requested, or "NONE" otherwise.
1318 %t The type of the server host key, e.g. ssh-ed25519.
1319 %u The local username.
1320 CertificateFile, ControlPath, IdentityAgent, IdentityFile,
1322 KnownHostsCommand, LocalForward, Match exec, RemoteCommand,
1323 RemoteForward, and UserKnownHostsFile accept the tokens %%, %C, %d, %h,
1324 %i, %k, %L, %l, %n, %p, %r, and %u.
1325 KnownHostsCommand additionally accepts the tokens %f, %H, %I, %K and %t.
1327 Hostname accepts the tokens %% and %h.
1329 LocalCommand accepts all tokens.
1331 ProxyCommand and ProxyJump accept the tokens %%, %h, %n, %p, and %r.
1333
1335 Arguments to some keywords can be expanded at runtime from environment
1336 variables on the client by enclosing them in ${}, for example
1337 ${HOME}/.ssh would refer to the user's .ssh directory. If a specified
1338 environment variable does not exist then an error will be returned and
1339 the setting for that keyword will be ignored.
1340 The keywords CertificateFile, ControlPath, IdentityAgent, IdentityFile,
1342 KnownHostsCommand, and UserKnownHostsFile support environment variables.
1343 The keywords LocalForward and RemoteForward support environment variables
1344 only for Unix domain socket paths.
1345
1347 ~/.ssh/config
1348 This is the per-user configuration file. The format of this file
1349 is described above. This file is used by the SSH client. Be‐
1350 cause of the potential for abuse, this file must have strict per‐
1351 missions: read/write for the user, and not writable by others.
1352 /etc/ssh/ssh_config
1354 Systemwide configuration file. This file provides defaults for
1355 those values that are not specified in the user's configuration
1356 file, and for those users who do not have a configuration file.
1357 This file must be world-readable.
1358
1360 ssh(1), crypto-policies(7), update-crypto-policies(8)
1361
1363 OpenSSH is a derivative of the original and free ssh 1.2.12 release by
1364 Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
1365 de Raadt and Dug Song removed many bugs, re-added newer features and cre‐
1366 ated OpenSSH. Markus Friedl contributed the support for SSH protocol
1367 versions 1.5 and 2.0.
1368BSD March 10, 2023 BSD