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