1SSH_CONFIG(5) BSD File Formats Manual SSH_CONFIG(5)
2
4 ssh_config — OpenSSH SSH client configuration files
5
7 ~/.ssh/config
8 /etc/ssh/ssh_config
9
11 ssh(1) obtains configuration data from the following sources in the fol‐
12 lowing order:
13 1. command-line options
15 2. user's configuration file (~/.ssh/config)
16 3. system-wide configuration file (/etc/ssh/ssh_config)
17 For each parameter, the first obtained value will be used. The configu‐
19 ration files contain sections separated by “Host” specifications, and
20 that section is only applied for hosts that match one of the patterns
21 given in the specification. The matched host name is the one given on
22 the command line.
23 Since the first obtained value for each parameter is used, more host-spe‐
25 cific declarations should be given near the beginning of the file, and
26 general defaults at the end.
27 The configuration file has the following format:
29 Empty lines and lines starting with ‘#’ are comments. Otherwise a line
31 is of the format “keyword arguments”. Configuration options may be sepa‐
32 rated by whitespace or optional whitespace and exactly one ‘=’; the lat‐
33 ter format is useful to avoid the need to quote whitespace when specify‐
34 ing configuration options using the ssh, scp, and sftp -o option. Argu‐
35 ments may optionally be enclosed in double quotes (") in order to repre‐
36 sent arguments containing spaces.
37 The possible keywords and their meanings are as follows (note that key‐
39 words are case-insensitive and arguments are case-sensitive):
40 Host Restricts the following declarations (up to the next Host key‐
42 word) to be only for those hosts that match one of the patterns
43 given after the keyword. If more than one pattern is provided,
44 they should be separated by whitespace. A single ‘*’ as a pat‐
45 tern can be used to provide global defaults for all hosts. The
46 host is the hostname argument given on the command line (i.e. the
47 name is not converted to a canonicalized host name before match‐
48 ing).
49 See PATTERNS for more information on patterns.
51 AddressFamily
53 Specifies which address family to use when connecting. Valid
54 arguments are “any”, “inet” (use IPv4 only), or “inet6” (use IPv6
55 only).
56 BatchMode
58 If set to “yes”, passphrase/password querying will be disabled.
59 This option is useful in scripts and other batch jobs where no
60 user is present to supply the password. The argument must be
61 “yes” or “no”. The default is “no”.
62 BindAddress
64 Use the specified address on the local machine as the source
65 address of the connection. Only useful on systems with more than
66 one address. Note that this option does not work if
67 UsePrivilegedPort is set to “yes”.
68 ChallengeResponseAuthentication
70 Specifies whether to use challenge-response authentication. The
71 argument to this keyword must be “yes” or “no”. The default is
72 “yes”.
73 CheckHostIP
75 If this flag is set to “yes”, ssh(1) will additionally check the
76 host IP address in the known_hosts file. This allows ssh to
77 detect if a host key changed due to DNS spoofing. If the option
78 is set to “no”, the check will not be executed. The default is
79 “yes”.
80 Cipher Specifies the cipher to use for encrypting the session in proto‐
82 col version 1. Currently, “blowfish”, “3des”, and “des” are sup‐
83 ported. des is only supported in the ssh(1) client for interop‐
84 erability with legacy protocol 1 implementations that do not sup‐
85 port the 3des cipher. Its use is strongly discouraged due to
86 cryptographic weaknesses. The default is “3des”.
87 Ciphers
89 Specifies the ciphers allowed for protocol version 2 in order of
90 preference. Multiple ciphers must be comma-separated. The sup‐
91 ported ciphers are “3des-cbc”, “aes128-cbc”, “aes192-cbc”,
92 “aes256-cbc”, “aes128-ctr”, “aes192-ctr”, “aes256-ctr”,
93 “arcfour128”, “arcfour256”, “arcfour”, “blowfish-cbc”, and
94 “cast128-cbc”. The default is:
95 aes128-ctr,aes192-ctr,aes256-ctr,
97 aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
98 aes256-cbc
99 ClearAllForwardings
101 Specifies that all local, remote, and dynamic port forwardings
102 specified in the configuration files or on the command line be
103 cleared. This option is primarily useful when used from the
104 ssh(1) command line to clear port forwardings set in configura‐
105 tion files, and is automatically set by scp(1) and sftp(1). The
106 argument must be “yes” or “no”. The default is “no”.
107 Compression
109 Specifies whether to use compression. The argument must be “yes”
110 or “no”. The default is “no”.
111 CompressionLevel
113 Specifies the compression level to use if compression is enabled.
114 The argument must be an integer from 1 (fast) to 9 (slow, best).
115 The default level is 6, which is good for most applications. The
116 meaning of the values is the same as in gzip(1). Note that this
117 option applies to protocol version 1 only.
118 ConnectionAttempts
120 Specifies the number of tries (one per second) to make before
121 exiting. The argument must be an integer. This may be useful in
122 scripts if the connection sometimes fails. The default is 1.
123 ConnectTimeout
125 Specifies the timeout (in seconds) used when connecting to the
126 SSH server, instead of using the default system TCP timeout.
127 This value is used only when the target is down or really
128 unreachable, not when it refuses the connection.
129 ControlMaster
131 Enables the sharing of multiple sessions over a single network
132 connection. When set to “yes”, ssh(1) will listen for connec‐
133 tions on a control socket specified using the ControlPath argu‐
134 ment. Additional sessions can connect to this socket using the
135 same ControlPath with ControlMaster set to “no” (the default).
136 These sessions will try to reuse the master instance's network
137 connection rather than initiating new ones, but will fall back to
138 connecting normally if the control socket does not exist, or is
139 not listening.
140 Setting this to “ask” will cause ssh to listen for control con‐
142 nections, but require confirmation using the SSH_ASKPASS program
143 before they are accepted (see ssh-add(1) for details). If the
144 ControlPath cannot be opened, ssh will continue without connect‐
145 ing to a master instance.
146 X11 and ssh-agent(1) forwarding is supported over these multi‐
148 plexed connections, however the display and agent forwarded will
149 be the one belonging to the master connection i.e. it is not pos‐
150 sible to forward multiple displays or agents.
151 Two additional options allow for opportunistic multiplexing: try
153 to use a master connection but fall back to creating a new one if
154 one does not already exist. These options are: “auto” and
155 “autoask”. The latter requires confirmation like the “ask”
156 option.
157 ControlPath
159 Specify the path to the control socket used for connection shar‐
160 ing as described in the ControlMaster section above or the string
161 “none” to disable connection sharing. In the path, ‘%l’ will be
162 substituted by the local host name, ‘%h’ will be substituted by
163 the target host name, ‘%p’ the port, and ‘%r’ by the remote login
164 username. It is recommended that any ControlPath used for oppor‐
165 tunistic connection sharing include at least %h, %p, and %r.
166 This ensures that shared connections are uniquely identified.
167 ControlPersist
169 When used in conjunction with ControlMaster, specifies that the
170 master connection should remain open in the background (waiting
171 for future client connections) after the initial client connec‐
172 tion has been closed. If set to “no”, then the master connection
173 will not be placed into the background, and will close as soon as
174 the initial client connection is closed. If set to “yes”, then
175 the master connection will remain in the background indefinitely
176 (until killed or closed via a mechanism such as the ssh(1) “-O
177 exit” option). If set to a time in seconds, or a time in any of
178 the formats documented in sshd_config(5), then the backgrounded
179 master connection will automatically terminate after it has
180 remained idle (with no client connections) for the specified
181 time.
182 DynamicForward
184 Specifies that a TCP port on the local machine be forwarded over
185 the secure channel, and the application protocol is then used to
186 determine where to connect to from the remote machine.
187 The argument must be [bind_address:]port. IPv6 addresses can be
189 specified by enclosing addresses in square brackets or by using
190 an alternative syntax: [bind_address/]port. By default, the
191 local port is bound in accordance with the GatewayPorts setting.
192 However, an explicit bind_address may be used to bind the connec‐
193 tion to a specific address. The bind_address of “localhost”
194 indicates that the listening port be bound for local use only,
195 while an empty address or ‘*’ indicates that the port should be
196 available from all interfaces.
197 Currently the SOCKS4 and SOCKS5 protocols are supported, and
199 ssh(1) will act as a SOCKS server. Multiple forwardings may be
200 specified, and additional forwardings can be given on the command
201 line. Only the superuser can forward privileged ports.
202 EnableSSHKeysign
204 Setting this option to “yes” in the global client configuration
205 file /etc/ssh/ssh_config enables the use of the helper program
206 ssh-keysign(8) during HostbasedAuthentication. The argument must
207 be “yes” or “no”. The default is “no”. This option should be
208 placed in the non-hostspecific section. See ssh-keysign(8) for
209 more information.
210 EscapeChar
212 Sets the escape character (default: ‘~’). The escape character
213 can also be set on the command line. The argument should be a
214 single character, ‘^’ followed by a letter, or “none” to disable
215 the escape character entirely (making the connection transparent
216 for binary data).
217 ExitOnForwardFailure
219 Specifies whether ssh(1) should terminate the connection if it
220 cannot set up all requested dynamic, tunnel, local, and remote
221 port forwardings. The argument must be “yes” or “no”. The
222 default is “no”.
223 ForwardAgent
225 Specifies whether the connection to the authentication agent (if
226 any) will be forwarded to the remote machine. The argument must
227 be “yes” or “no”. The default is “no”.
228 Agent forwarding should be enabled with caution. Users with the
230 ability to bypass file permissions on the remote host (for the
231 agent's Unix-domain socket) can access the local agent through
232 the forwarded connection. An attacker cannot obtain key material
233 from the agent, however they can perform operations on the keys
234 that enable them to authenticate using the identities loaded into
235 the agent.
236 ForwardX11
238 Specifies whether X11 connections will be automatically redi‐
239 rected over the secure channel and DISPLAY set. The argument
240 must be “yes” or “no”. The default is “no”.
241 X11 forwarding should be enabled with caution. Users with the
243 ability to bypass file permissions on the remote host (for the
244 user's X11 authorization database) can access the local X11 dis‐
245 play through the forwarded connection. An attacker may then be
246 able to perform activities such as keystroke monitoring if the
247 ForwardX11Trusted option is also enabled.
248 ForwardX11Trusted
250 If this option is set to “yes”, remote X11 clients will have full
251 access to the original X11 display.
252 If this option is set to “no”, remote X11 clients will be consid‐
254 ered untrusted and prevented from stealing or tampering with data
255 belonging to trusted X11 clients. Furthermore, the xauth(1)
256 token used for the session will be set to expire after 20 min‐
257 utes. Remote clients will be refused access after this time.
258 The default is “no”.
260 See the X11 SECURITY extension specification for full details on
262 the restrictions imposed on untrusted clients.
263 GatewayPorts
265 Specifies whether remote hosts are allowed to connect to local
266 forwarded ports. By default, ssh(1) binds local port forwardings
267 to the loopback address. This prevents other remote hosts from
268 connecting to forwarded ports. GatewayPorts can be used to spec‐
269 ify that ssh should bind local port forwardings to the wildcard
270 address, thus allowing remote hosts to connect to forwarded
271 ports. The argument must be “yes” or “no”. The default is “no”.
272 GlobalKnownHostsFile
274 Specifies a file to use for the global host key database instead
275 of /etc/ssh/ssh_known_hosts.
276 GSSAPIAuthentication
278 Specifies whether user authentication based on GSSAPI is allowed.
279 The default is “no”. Note that this option applies to protocol
280 version 2 only.
281 GSSAPIKeyExchange
283 Specifies whether key exchange based on GSSAPI may be used. When
284 using GSSAPI key exchange the server need not have a host key.
285 The default is “no”. Note that this option applies to protocol
286 version 2 only.
287 GSSAPIClientIdentity
289 If set, specifies the GSSAPI client identity that ssh should use
290 when connecting to the server. The default is unset, which means
291 that the default identity will be used.
292 GSSAPIDelegateCredentials
294 Forward (delegate) credentials to the server. The default is
295 “no”. Note that this option applies to protocol version 2 con‐
296 nections using GSSAPI.
297 GSSAPIRenewalForcesRekey
299 If set to “yes” then renewal of the client's GSSAPI credentials
300 will force the rekeying of the ssh connection. With a compatible
301 server, this can delegate the renewed credentials to a session on
302 the server. The default is “no”.
303 GSSAPITrustDns
305 Set to “yes to indicate that the DNS is trusted to securely
306 canonicalize” the name of the host being connected to. If “no,
307 the hostname entered on the” command line will be passed
308 untouched to the GSSAPI library. The default is “no”. This
309 option only applies to protocol version 2 connections using GSS‐
310 API.
311 GSSAPIKexAlgorithms
313 The list of key exchange algorithms that are accepted by GSSAPI
314 key exchange. Possible values are
315 gss-group1-sha1-,
317 gss-group14-sha1-,
318 gss-gex-sha1-
319 The default is
321 “gss-group1-sha1-,gss-group14-sha1-,gss-gex-sha1-”. This option
322 only applies to protocol version 2 connections using GSSAPI.
323 HashKnownHosts
325 Indicates that ssh(1) should hash host names and addresses when
326 they are added to ~/.ssh/known_hosts. These hashed names may be
327 used normally by ssh(1) and sshd(8), but they do not reveal iden‐
328 tifying information should the file's contents be disclosed. The
329 default is “no”. Note that existing names and addresses in known
330 hosts files will not be converted automatically, but may be manu‐
331 ally hashed using ssh-keygen(1).
332 HostbasedAuthentication
334 Specifies whether to try rhosts based authentication with public
335 key authentication. The argument must be “yes” or “no”. The
336 default is “no”. This option applies to protocol version 2 only
337 and is similar to RhostsRSAAuthentication.
338 HostKeyAlgorithms
340 Specifies the protocol version 2 host key algorithms that the
341 client wants to use in order of preference. The default for this
342 option is:
343 ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,
345 ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,
346 ssh-rsa,ssh-dss
347 HostKeyAlias
349 Specifies an alias that should be used instead of the real host
350 name when looking up or saving the host key in the host key data‐
351 base files. This option is useful for tunneling SSH connections
352 or for multiple servers running on a single host.
353 HostName
355 Specifies the real host name to log into. This can be used to
356 specify nicknames or abbreviations for hosts. The default is the
357 name given on the command line. Numeric IP addresses are also
358 permitted (both on the command line and in HostName specifica‐
359 tions).
360 IdentitiesOnly
362 Specifies that ssh(1) should only use the authentication identity
363 files configured in the ssh_config files, even if ssh-agent(1)
364 offers more identities. The argument to this keyword must be
365 “yes” or “no”. This option is intended for situations where ssh-
366 agent offers many different identities. The default is “no”.
367 IdentityFile
369 Specifies a file from which the user's DSA, ECDSA or DSA authen‐
370 tication identity is read. The default is ~/.ssh/identity for
371 protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and
372 ~/.ssh/id_rsa for protocol version 2. Additionally, any identi‐
373 ties represented by the authentication agent will be used for
374 authentication. ssh(1) will try to load certificate information
375 from the filename obtained by appending -cert.pub to the path of
376 a specified IdentityFile.
377 The file name may use the tilde syntax to refer to a user's home
379 directory or one of the following escape characters: ‘%d’ (local
380 user's home directory), ‘%u’ (local user name), ‘%l’ (local host
381 name), ‘%h’ (remote host name) or ‘%r’ (remote user name).
382 It is possible to have multiple identity files specified in con‐
384 figuration files; all these identities will be tried in sequence.
385 KbdInteractiveAuthentication
387 Specifies whether to use keyboard-interactive authentication.
388 The argument to this keyword must be “yes” or “no”. The default
389 is “yes”.
390 KbdInteractiveDevices
392 Specifies the list of methods to use in keyboard-interactive
393 authentication. Multiple method names must be comma-separated.
394 The default is to use the server specified list. The methods
395 available vary depending on what the server supports. For an
396 OpenSSH server, it may be zero or more of: “bsdauth”, “pam”, and
397 “skey”.
398 KexAlgorithms
400 Specifies the available KEX (Key Exchange) algorithms. Multiple
401 algorithms must be comma-separated. The default is
402 “diffie-hellman-group-exchange-sha256”,
403 “diffie-hellman-group-exchange-sha1”,
404 “diffie-hellman-group14-sha1”, “diffie-hellman-group1-sha1”.
405 LocalCommand
407 Specifies a command to execute on the local machine after suc‐
408 cessfully connecting to the server. The command string extends
409 to the end of the line, and is executed with the user's shell.
410 The following escape character substitutions will be performed:
411 ‘%d’ (local user's home directory), ‘%h’ (remote host name), ‘%l’
412 (local host name), ‘%n’ (host name as provided on the command
413 line), ‘%p’ (remote port), ‘%r’ (remote user name) or ‘%u’ (local
414 user name). This directive is ignored unless PermitLocalCommand
415 has been enabled.
416 LocalForward
418 Specifies that a TCP port on the local machine be forwarded over
419 the secure channel to the specified host and port from the remote
420 machine. The first argument must be [bind_address:]port and the
421 second argument must be host:hostport. IPv6 addresses can be
422 specified by enclosing addresses in square brackets or by using
423 an alternative syntax: [bind_address/]port and host/hostport.
424 Multiple forwardings may be specified, and additional forwardings
425 can be given on the command line. Only the superuser can forward
426 privileged ports. By default, the local port is bound in accor‐
427 dance with the GatewayPorts setting. However, an explicit
428 bind_address may be used to bind the connection to a specific
429 address. The bind_address of “localhost” indicates that the lis‐
430 tening port be bound for local use only, while an empty address
431 or ‘*’ indicates that the port should be available from all
432 interfaces.
433 LogLevel
435 Gives the verbosity level that is used when logging messages from
436 ssh(1). The possible values are: QUIET, FATAL, ERROR, INFO, VER‐
437 BOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO.
438 DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify
439 higher levels of verbose output.
440 MACs Specifies the MAC (message authentication code) algorithms in
442 order of preference. The MAC algorithm is used in protocol ver‐
443 sion 2 for data integrity protection. Multiple algorithms must
444 be comma-separated. The default is:
445 hmac-sha1,umac-64@openssh.com,
447 hmac-ripemd160,hmac-sha1-96,
448 hmac-sha2-256,hmac-sha2-512
449 NoHostAuthenticationForLocalhost
451 This option can be used if the home directory is shared across
452 machines. In this case localhost will refer to a different
453 machine on each of the machines and the user will get many warn‐
454 ings about changed host keys. However, this option disables host
455 authentication for localhost. The argument to this keyword must
456 be “yes” or “no”. The default is to check the host key for
457 localhost.
458 NumberOfPasswordPrompts
460 Specifies the number of password prompts before giving up. The
461 argument to this keyword must be an integer. The default is 3.
462 PasswordAuthentication
464 Specifies whether to use password authentication. The argument
465 to this keyword must be “yes” or “no”. The default is “yes”.
466 PermitLocalCommand
468 Allow local command execution via the LocalCommand option or
469 using the !command escape sequence in ssh(1). The argument must
470 be “yes” or “no”. The default is “no”.
471 PKCS11Provider
473 Specifies which PKCS#11 provider to use. The argument to this
474 keyword is the PKCS#11 shared libary ssh(1) should use to commu‐
475 nicate with a PKCS#11 token used for storing the user's private
476 RSA key. By default, no device is specified and PKCS#11 support
477 is not activated.
478 Port Specifies the port number to connect on the remote host. The
480 default is 22.
481 PreferredAuthentications
483 Specifies the order in which the client should try protocol 2
484 authentication methods. This allows a client to prefer one
485 method (e.g. keyboard-interactive) over another method (e.g.
486 password) The default for this option is: “gssapi-with-mic,
487 hostbased, publickey, keyboard-interactive, password”.
488 Protocol
490 Specifies the protocol versions ssh(1) should support in order of
491 preference. The possible values are ‘1’ and ‘2’. Multiple ver‐
492 sions must be comma-separated. The default is “2,1”. This means
493 that ssh tries version 2 and falls back to version 1 if version 2
494 is not available.
495 ProxyCommand
497 Specifies the command to use to connect to the server. The com‐
498 mand string extends to the end of the line, and is executed with
499 the user's shell. In the command string, ‘%h’ will be substi‐
500 tuted by the host name to connect and ‘%p’ by the port. The com‐
501 mand can be basically anything, and should read from its standard
502 input and write to its standard output. It should eventually
503 connect an sshd(8) server running on some machine, or execute
504 sshd -i somewhere. Host key management will be done using the
505 HostName of the host being connected (defaulting to the name
506 typed by the user). Setting the command to “none” disables this
507 option entirely. Note that CheckHostIP is not available for con‐
508 nects with a proxy command.
509 This directive is useful in conjunction with nc(1) and its proxy
511 support. For example, the following directive would connect via
512 an HTTP proxy at 192.0.2.0:
513 ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p
515 PubkeyAuthentication
517 Specifies whether to try public key authentication. The argument
518 to this keyword must be “yes” or “no”. The default is “yes”.
519 This option applies to protocol version 2 only.
520 RekeyLimit
522 Specifies the maximum amount of data that may be transmitted
523 before the session key is renegotiated. The argument is the num‐
524 ber of bytes, with an optional suffix of ‘K’, ‘M’, or ‘G’ to
525 indicate Kilobytes, Megabytes, or Gigabytes, respectively. The
526 default is between ‘1G’ and ‘4G’, depending on the cipher. This
527 option applies to protocol version 2 only.
528 RemoteForward
530 Specifies that a TCP port on the remote machine be forwarded over
531 the secure channel to the specified host and port from the local
532 machine. The first argument must be [bind_address:]port and the
533 second argument must be host:hostport. IPv6 addresses can be
534 specified by enclosing addresses in square brackets or by using
535 an alternative syntax: [bind_address/]port and host/hostport.
536 Multiple forwardings may be specified, and additional forwardings
537 can be given on the command line. Privileged ports can be for‐
538 warded only when logging in as root on the remote machine.
539 If the port argument is ‘0’, the listen port will be dynamically
541 allocated on the server and reported to the client at run time.
542 If the bind_address is not specified, the default is to only bind
544 to loopback addresses. If the bind_address is ‘*’ or an empty
545 string, then the forwarding is requested to listen on all inter‐
546 faces. Specifying a remote bind_address will only succeed if the
547 server's GatewayPorts option is enabled (see sshd_config(5)).
548 RhostsRSAAuthentication
550 Specifies whether to try rhosts based authentication with RSA
551 host authentication. The argument must be “yes” or “no”. The
552 default is “no”. This option applies to protocol version 1 only
553 and requires ssh(1) to be setuid root.
554 RSAAuthentication
556 Specifies whether to try RSA authentication. The argument to
557 this keyword must be “yes” or “no”. RSA authentication will only
558 be attempted if the identity file exists, or an authentication
559 agent is running. The default is “yes”. Note that this option
560 applies to protocol version 1 only.
561 SendEnv
563 Specifies what variables from the local environ(7) should be sent
564 to the server. Note that environment passing is only supported
565 for protocol 2. The server must also support it, and the server
566 must be configured to accept these environment variables. Note
567 that the TERM environment variable is always sent whenever a
568 pseudo-terminal is requested as it is required by the protocol.
569 Refer to AcceptEnv in sshd_config(5) for how to configure the
570 server. Variables are specified by name, which may contain wild‐
571 card characters. Multiple environment variables may be separated
572 by whitespace or spread across multiple SendEnv directives. The
573 default is not to send any environment variables.
574 See PATTERNS for more information on patterns.
576 ServerAliveCountMax
578 Sets the number of server alive messages (see below) which may be
579 sent without ssh(1) receiving any messages back from the server.
580 If this threshold is reached while server alive messages are
581 being sent, ssh will disconnect from the server, terminating the
582 session. It is important to note that the use of server alive
583 messages is very different from TCPKeepAlive (below). The server
584 alive messages are sent through the encrypted channel and there‐
585 fore will not be spoofable. The TCP keepalive option enabled by
586 TCPKeepAlive is spoofable. The server alive mechanism is valu‐
587 able when the client or server depend on knowing when a connec‐
588 tion has become inactive.
589 The default value is 3. If, for example, ServerAliveInterval
591 (see below) is set to 15 and ServerAliveCountMax is left at the
592 default, if the server becomes unresponsive, ssh will disconnect
593 after approximately 45 seconds. This option applies to protocol
594 version 2 only.
595 ServerAliveInterval
597 Sets a timeout interval in seconds after which if no data has
598 been received from the server, ssh(1) will send a message through
599 the encrypted channel to request a response from the server. The
600 default is 0, indicating that these messages will not be sent to
601 the server. This option applies to protocol version 2 only.
602 StrictHostKeyChecking
604 If this flag is set to “yes”, ssh(1) will never automatically add
605 host keys to the ~/.ssh/known_hosts file, and refuses to connect
606 to hosts whose host key has changed. This provides maximum pro‐
607 tection against trojan horse attacks, though it can be annoying
608 when the /etc/ssh/ssh_known_hosts file is poorly maintained or
609 when connections to new hosts are frequently made. This option
610 forces the user to manually add all new hosts. If this flag is
611 set to “no”, ssh will automatically add new host keys to the user
612 known hosts files. If this flag is set to “ask”, new host keys
613 will be added to the user known host files only after the user
614 has confirmed that is what they really want to do, and ssh will
615 refuse to connect to hosts whose host key has changed. The host
616 keys of known hosts will be verified automatically in all cases.
617 The argument must be “yes”, “no”, or “ask”. The default is
618 “ask”.
619 TCPKeepAlive
621 Specifies whether the system should send TCP keepalive messages
622 to the other side. If they are sent, death of the connection or
623 crash of one of the machines will be properly noticed. However,
624 this means that connections will die if the route is down tempo‐
625 rarily, and some people find it annoying.
626 The default is “yes” (to send TCP keepalive messages), and the
628 client will notice if the network goes down or the remote host
629 dies. This is important in scripts, and many users want it too.
630 To disable TCP keepalive messages, the value should be set to
632 “no”.
633 Tunnel Request tun(4) device forwarding between the client and the
635 server. The argument must be “yes”, “point-to-point” (layer 3),
636 “ethernet” (layer 2), or “no”. Specifying “yes” requests the
637 default tunnel mode, which is “point-to-point”. The default is
638 “no”.
639 TunnelDevice
641 Specifies the tun(4) devices to open on the client (local_tun)
642 and the server (remote_tun).
643 The argument must be local_tun[:remote_tun]. The devices may be
645 specified by numerical ID or the keyword “any”, which uses the
646 next available tunnel device. If remote_tun is not specified, it
647 defaults to “any”. The default is “any:any”.
648 UsePrivilegedPort
650 Specifies whether to use a privileged port for outgoing connec‐
651 tions. The argument must be “yes” or “no”. The default is “no”.
652 If set to “yes”, ssh(1) must be setuid root. Note that this
653 option must be set to “yes” for RhostsRSAAuthentication with
654 older servers.
655 User Specifies the user to log in as. This can be useful when a dif‐
657 ferent user name is used on different machines. This saves the
658 trouble of having to remember to give the user name on the com‐
659 mand line.
660 UserKnownHostsFile
662 Specifies a file to use for the user host key database instead of
663 ~/.ssh/known_hosts.
664 VerifyHostKeyDNS
666 Specifies whether to verify the remote key using DNS and SSHFP
667 resource records. If this option is set to “yes”, the client
668 will implicitly trust keys that match a secure fingerprint from
669 DNS. Insecure fingerprints will be handled as if this option was
670 set to “ask”. If this option is set to “ask”, information on
671 fingerprint match will be displayed, but the user will still need
672 to confirm new host keys according to the StrictHostKeyChecking
673 option. The argument must be “yes”, “no”, or “ask”. The default
674 is “no”. Note that this option applies to protocol version 2
675 only.
676 See also VERIFYING HOST KEYS in ssh(1).
678 VisualHostKey
680 If this flag is set to “yes”, an ASCII art representation of the
681 remote host key fingerprint is printed in addition to the hex
682 fingerprint string at login and for unknown host keys. If this
683 flag is set to “no”, no fingerprint strings are printed at login
684 and only the hex fingerprint string will be printed for unknown
685 host keys. The default is “no”.
686 XAuthLocation
688 Specifies the full pathname of the xauth(1) program. The default
689 is /usr/bin/xauth.
690
692 A pattern consists of zero or more non-whitespace characters, ‘*’ (a
693 wildcard that matches zero or more characters), or ‘?’ (a wildcard that
694 matches exactly one character). For example, to specify a set of decla‐
695 rations for any host in the “.co.uk” set of domains, the following pat‐
696 tern could be used:
697 Host *.co.uk
699 The following pattern would match any host in the 192.168.0.[0-9] network
701 range:
702 Host 192.168.0.?
704 A pattern-list is a comma-separated list of patterns. Patterns within
706 pattern-lists may be negated by preceding them with an exclamation mark
707 (‘!’). For example, to allow a key to be used from anywhere within an
708 organisation except from the “dialup” pool, the following entry (in
709 authorized_keys) could be used:
710 from="!*.dialup.example.com,*.example.com"
712
714 ~/.ssh/config
715 This is the per-user configuration file. The format of this file
716 is described above. This file is used by the SSH client.
717 Because of the potential for abuse, this file must have strict
718 permissions: read/write for the user, and not accessible by oth‐
719 ers.
720 /etc/ssh/ssh_config
722 Systemwide configuration file. This file provides defaults for
723 those values that are not specified in the user's configuration
724 file, and for those users who do not have a configuration file.
725 This file must be world-readable.
726
728 ssh(1)
729
731 OpenSSH is a derivative of the original and free ssh 1.2.12 release by
732 Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
733 de Raadt and Dug Song removed many bugs, re-added newer features and cre‐
734 ated OpenSSH. Markus Friedl contributed the support for SSH protocol
735 versions 1.5 and 2.0.
736BSD June 21, 2019 BSD