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 For each parameter, the first obtained value will be used. The configu‐
17 ration files contain sections separated by Host specifications, and that
18 section is only applied for hosts that match one of the patterns given in
19 the specification. The matched host name is usually the one given on the
20 command line (see the CanonicalizeHostname option for exceptions).
21 Since the first obtained value for each parameter is used, more host-spe‐
23 cific declarations should be given near the beginning of the file, and
24 general defaults at the end.
25 The file contains keyword-argument pairs, one per line. Lines starting
27 with ‘#’ and empty lines are interpreted as comments. Arguments may
28 optionally be enclosed in double quotes (") in order to represent argu‐
29 ments containing spaces. Configuration options may be separated by
30 whitespace or optional whitespace and exactly one ‘=’; the latter format
31 is useful to avoid the need to quote whitespace when specifying configu‐
32 ration options using the ssh, scp, and sftp -o option.
33 The possible keywords and their meanings are as follows (note that key‐
35 words are case-insensitive and arguments are case-sensitive):
36 Host Restricts the following declarations (up to the next Host or
38 Match keyword) to be only for those hosts that match one of the
39 patterns given after the keyword. If more than one pattern is
40 provided, they should be separated by whitespace. A single ‘*’
41 as a pattern can be used to provide global defaults for all
42 hosts. The host is usually the hostname argument given on the
43 command line (see the CanonicalizeHostname keyword for excep‐
44 tions).
45 A pattern entry may be negated by prefixing it with an exclama‐
47 tion mark (‘!’). If a negated entry is matched, then the Host
48 entry is ignored, regardless of whether any other patterns on the
49 line match. Negated matches are therefore useful to provide
50 exceptions for wildcard matches.
51 See PATTERNS for more information on patterns.
53 Match Restricts the following declarations (up to the next Host or
55 Match keyword) to be used only when the conditions following the
56 Match keyword are satisfied. Match conditions are specified
57 using one or more criteria or the single token all which always
58 matches. The available criteria keywords are: canonical, final,
59 exec, host, originalhost, user, and localuser. The all criteria
60 must appear alone or immediately after canonical or final. Other
61 criteria may be combined arbitrarily. All criteria but all,
62 canonical, and final require an argument. Criteria may be
63 negated by prepending an exclamation mark (‘!’).
64 The canonical keyword matches only when the configuration file is
66 being re-parsed after hostname canonicalization (see the
67 CanonicalizeHostname option). This may be useful to specify con‐
68 ditions that work with canonical host names only.
69 The final keyword requests that the configuration be re-parsed
71 (regardless of whether CanonicalizeHostname is enabled), and
72 matches only during this final pass. If CanonicalizeHostname is
73 enabled, then canonical and final match during the same pass.
74 The exec keyword executes the specified command under the user's
76 shell. If the command returns a zero exit status then the condi‐
77 tion is considered true. Commands containing whitespace charac‐
78 ters must be quoted. Arguments to exec accept the tokens
79 described in the TOKENS section.
80 The other keywords' criteria must be single entries or comma-sep‐
82 arated lists and may use the wildcard and negation operators
83 described in the PATTERNS section. The criteria for the host
84 keyword are matched against the target hostname, after any sub‐
85 stitution by the Hostname or CanonicalizeHostname options. The
86 originalhost keyword matches against the hostname as it was spec‐
87 ified on the command-line. The user keyword matches against the
88 target username on the remote host. The localuser keyword
89 matches against the name of the local user running ssh(1) (this
90 keyword may be useful in system-wide ssh_config files).
91 AddKeysToAgent
93 Specifies whether keys should be automatically added to a running
94 ssh-agent(1). If this option is set to yes and a key is loaded
95 from a file, the key and its passphrase are added to the agent
96 with the default lifetime, as if by ssh-add(1). If this option
97 is set to ask, ssh(1) will require confirmation using the
98 SSH_ASKPASS program before adding a key (see ssh-add(1) for
99 details). If this option is set to confirm, each use of the key
100 must be confirmed, as if the -c option was specified to
101 ssh-add(1). If this option is set to no, no keys are added to
102 the agent. The argument must be yes, confirm, ask, or no (the
103 default).
104 AddressFamily
106 Specifies which address family to use when connecting. Valid
107 arguments are any (the default), inet (use IPv4 only), or inet6
108 (use IPv6 only).
109 BatchMode
111 If set to yes, user interaction such as password prompts and host
112 key confirmation requests will be disabled. This option is use‐
113 ful in scripts and other batch jobs where no user is present to
114 interact with ssh(1). The argument must be yes or no (the
115 default).
116 BindAddress
118 Use the specified address on the local machine as the source
119 address of the connection. Only useful on systems with more than
120 one address.
121 BindInterface
123 Use the address of the specified interface on the local machine
124 as the source address of the connection.
125 CanonicalDomains
127 When CanonicalizeHostname is enabled, this option specifies the
128 list of domain suffixes in which to search for the specified des‐
129 tination host.
130 CanonicalizeFallbackLocal
132 Specifies whether to fail with an error when hostname canonical‐
133 ization fails. The default, yes, will attempt to look up the
134 unqualified hostname using the system resolver's search rules. A
135 value of no will cause ssh(1) to fail instantly if
136 CanonicalizeHostname is enabled and the target hostname cannot be
137 found in any of the domains specified by CanonicalDomains.
138 CanonicalizeHostname
140 Controls whether explicit hostname canonicalization is performed.
141 The default, no, is not to perform any name rewriting and let the
142 system resolver handle all hostname lookups. If set to yes then,
143 for connections that do not use a ProxyCommand or ProxyJump,
144 ssh(1) will attempt to canonicalize the hostname specified on the
145 command line using the CanonicalDomains suffixes and
146 CanonicalizePermittedCNAMEs rules. If CanonicalizeHostname is
147 set to always, then canonicalization is applied to proxied con‐
148 nections too.
149 If this option is enabled, then the configuration files are pro‐
151 cessed again using the new target name to pick up any new config‐
152 uration in matching Host and Match stanzas.
153 CanonicalizeMaxDots
155 Specifies the maximum number of dot characters in a hostname
156 before canonicalization is disabled. The default, 1, allows a
157 single dot (i.e. hostname.subdomain).
158 CanonicalizePermittedCNAMEs
160 Specifies rules to determine whether CNAMEs should be followed
161 when canonicalizing hostnames. The rules consist of one or more
162 arguments of source_domain_list:target_domain_list, where
163 source_domain_list is a pattern-list of domains that may follow
164 CNAMEs in canonicalization, and target_domain_list is a pattern-
165 list of domains that they may resolve to.
166 For example, "*.a.example.com:*.b.example.com,*.c.example.com"
168 will allow hostnames matching "*.a.example.com" to be canonical‐
169 ized to names in the "*.b.example.com" or "*.c.example.com"
170 domains.
171 CASignatureAlgorithms
173 The default is handled system-wide by crypto-policies(7). To see
174 the defaults and how to modify this default, see manual page
175 update-crypto-policies(8).
176 Specifies which algorithms are allowed for signing of certifi‐
178 cates by certificate authorities (CAs). ssh(1) will not accept
179 host certificates signed using algorithms other than those speci‐
180 fied.
181 CertificateFile
183 Specifies a file from which the user's certificate is read. A
184 corresponding private key must be provided separately in order to
185 use this certificate either from an IdentityFile directive or -i
186 flag to ssh(1), via ssh-agent(1), or via a PKCS11Provider or
187 SecurityKeyProvider.
188 Arguments to CertificateFile may use the tilde syntax to refer to
190 a user's home directory or the tokens described in the TOKENS
191 section.
192 It is possible to have multiple certificate files specified in
194 configuration files; these certificates will be tried in
195 sequence. Multiple CertificateFile directives will add to the
196 list of certificates used for authentication.
197 ChallengeResponseAuthentication
199 Specifies whether to use challenge-response authentication. The
200 argument to this keyword must be yes (the default) or no.
201 CheckHostIP
203 If set to yes (the default), ssh(1) will additionally check the
204 host IP address in the known_hosts file. This allows it to
205 detect if a host key changed due to DNS spoofing and will add
206 addresses of destination hosts to ~/.ssh/known_hosts in the
207 process, regardless of the setting of StrictHostKeyChecking. If
208 the option is set to no, the check will not be executed.
209 Ciphers
211 The default is handled system-wide by crypto-policies(7). To see
212 the defaults and how to modify this default, see manual page
213 update-crypto-policies(8).
214 Specifies the ciphers allowed and their order of preference.
216 Multiple ciphers must be comma-separated. If the specified list
217 begins with a ‘+’ character, then the specified ciphers will be
218 appended to the built-in default set instead of replacing them.
219 If the specified list begins with a ‘-’ character, then the spec‐
220 ified ciphers (including wildcards) will be removed from the
221 built-in default set instead of replacing them. If the specified
222 list begins with a ‘^’ character, then the specified ciphers will
223 be placed at the head of the built-in default set.
224 The supported ciphers are:
226 3des-cbc
228 aes128-cbc
229 aes192-cbc
230 aes256-cbc
231 aes128-ctr
232 aes192-ctr
233 aes256-ctr
234 aes128-gcm@openssh.com
235 aes256-gcm@openssh.com
236 chacha20-poly1305@openssh.com
237 The list of available ciphers may also be obtained using "ssh -Q
239 cipher".
240 ClearAllForwardings
242 Specifies that all local, remote, and dynamic port forwardings
243 specified in the configuration files or on the command line be
244 cleared. This option is primarily useful when used from the
245 ssh(1) command line to clear port forwardings set in configura‐
246 tion files, and is automatically set by scp(1) and sftp(1). The
247 argument must be yes or no (the default).
248 Compression
250 Specifies whether to use compression. The argument must be yes
251 or no (the default).
252 ConnectionAttempts
254 Specifies the number of tries (one per second) to make before
255 exiting. The argument must be an integer. This may be useful in
256 scripts if the connection sometimes fails. The default is 1.
257 ConnectTimeout
259 Specifies the timeout (in seconds) used when connecting to the
260 SSH server, instead of using the default system TCP timeout.
261 This timeout is applied both to establishing the connection and
262 to performing the initial SSH protocol handshake and key
263 exchange.
264 ControlMaster
266 Enables the sharing of multiple sessions over a single network
267 connection. When set to yes, ssh(1) will listen for connections
268 on a control socket specified using the ControlPath argument.
269 Additional sessions can connect to this socket using the same
270 ControlPath with ControlMaster set to no (the default). These
271 sessions will try to reuse the master instance's network connec‐
272 tion rather than initiating new ones, but will fall back to con‐
273 necting normally if the control socket does not exist, or is not
274 listening.
275 Setting this to ask will cause ssh(1) to listen for control con‐
277 nections, but require confirmation using ssh-askpass(1). If the
278 ControlPath cannot be opened, ssh(1) will continue without con‐
279 necting to a master instance.
280 X11 and ssh-agent(1) forwarding is supported over these multi‐
282 plexed connections, however the display and agent forwarded will
283 be the one belonging to the master connection i.e. it is not pos‐
284 sible to forward multiple displays or agents.
285 Two additional options allow for opportunistic multiplexing: try
287 to use a master connection but fall back to creating a new one if
288 one does not already exist. These options are: auto and autoask.
289 The latter requires confirmation like the ask option.
290 ControlPath
292 Specify the path to the control socket used for connection shar‐
293 ing as described in the ControlMaster section above or the string
294 none to disable connection sharing. Arguments to ControlPath may
295 use the tilde syntax to refer to a user's home directory or the
296 tokens described in the TOKENS section. It is recommended that
297 any ControlPath used for opportunistic connection sharing include
298 at least %h, %p, and %r (or alternatively %C) and be placed in a
299 directory that is not writable by other users. This ensures that
300 shared connections are uniquely identified.
301 ControlPersist
303 When used in conjunction with ControlMaster, specifies that the
304 master connection should remain open in the background (waiting
305 for future client connections) after the initial client connec‐
306 tion has been closed. If set to no (the default), then the mas‐
307 ter connection will not be placed into the background, and will
308 close as soon as the initial client connection is closed. If set
309 to yes or 0, then the master connection will remain in the back‐
310 ground indefinitely (until killed or closed via a mechanism such
311 as the "ssh -O exit"). If set to a time in seconds, or a time in
312 any of the formats documented in sshd_config(5), then the back‐
313 grounded master connection will automatically terminate after it
314 has remained idle (with no client connections) for the specified
315 time.
316 DynamicForward
318 Specifies that a TCP port on the local machine be forwarded over
319 the secure channel, and the application protocol is then used to
320 determine where to connect to from the remote machine.
321 The argument must be [bind_address:]port. IPv6 addresses can be
323 specified by enclosing addresses in square brackets. By default,
324 the local port is bound in accordance with the GatewayPorts set‐
325 ting. However, an explicit bind_address may be used to bind the
326 connection to a specific address. The bind_address of localhost
327 indicates that the listening port be bound for local use only,
328 while an empty address or ‘*’ indicates that the port should be
329 available from all interfaces.
330 Currently the SOCKS4 and SOCKS5 protocols are supported, and
332 ssh(1) will act as a SOCKS server. Multiple forwardings may be
333 specified, and additional forwardings can be given on the command
334 line. Only the superuser can forward privileged ports.
335 EnableSSHKeysign
337 Setting this option to yes in the global client configuration
338 file /etc/gsissh/ssh_config enables the use of the helper program
339 ssh-keysign(8) during HostbasedAuthentication. The argument must
340 be yes or no (the default). This option should be placed in the
341 non-hostspecific section. See ssh-keysign(8) for more informa‐
342 tion.
343 EscapeChar
345 Sets the escape character (default: ‘~’). The escape character
346 can also be set on the command line. The argument should be a
347 single character, ‘^’ followed by a letter, or none to disable
348 the escape character entirely (making the connection transparent
349 for binary data).
350 ExitOnForwardFailure
352 Specifies whether ssh(1) should terminate the connection if it
353 cannot set up all requested dynamic, tunnel, local, and remote
354 port forwardings, (e.g. if either end is unable to bind and lis‐
355 ten on a specified port). Note that ExitOnForwardFailure does
356 not apply to connections made over port forwardings and will not,
357 for example, cause ssh(1) to exit if TCP connections to the ulti‐
358 mate forwarding destination fail. The argument must be yes or no
359 (the default).
360 FingerprintHash
362 Specifies the hash algorithm used when displaying key finger‐
363 prints. Valid options are: md5 and sha256 (the default).
364 ForwardAgent
366 Specifies whether the connection to the authentication agent (if
367 any) will be forwarded to the remote machine. The argument may
368 be yes, no (the default), an explicit path to an agent socket or
369 the name of an environment variable (beginning with ‘$’) in which
370 to find the path.
371 Agent forwarding should be enabled with caution. Users with the
373 ability to bypass file permissions on the remote host (for the
374 agent's Unix-domain socket) can access the local agent through
375 the forwarded connection. An attacker cannot obtain key material
376 from the agent, however they can perform operations on the keys
377 that enable them to authenticate using the identities loaded into
378 the agent.
379 ForwardX11
381 Specifies whether X11 connections will be automatically redi‐
382 rected over the secure channel and DISPLAY set. The argument
383 must be yes or no (the default).
384 X11 forwarding should be enabled with caution. Users with the
386 ability to bypass file permissions on the remote host (for the
387 user's X11 authorization database) can access the local X11 dis‐
388 play through the forwarded connection. An attacker may then be
389 able to perform activities such as keystroke monitoring if the
390 ForwardX11Trusted option is also enabled.
391 ForwardX11Timeout
393 Specify a timeout for untrusted X11 forwarding using the format
394 described in the TIME FORMATS section of sshd_config(5). X11
395 connections received by ssh(1) after this time will be refused.
396 Setting ForwardX11Timeout to zero will disable the timeout and
397 permit X11 forwarding for the life of the connection. The
398 default is to disable untrusted X11 forwarding after twenty min‐
399 utes has elapsed.
400 ForwardX11Trusted
402 If this option is set to yes, remote X11 clients will have full
403 access to the original X11 display.
404 If this option is set to no (the default), remote X11 clients
406 will be considered untrusted and prevented from stealing or tam‐
407 pering with data belonging to trusted X11 clients. Furthermore,
408 the xauth(1) token used for the session will be set to expire
409 after 20 minutes. Remote clients will be refused access after
410 this time.
411 See the X11 SECURITY extension specification for full details on
413 the restrictions imposed on untrusted clients.
414 GatewayPorts
416 Specifies whether remote hosts are allowed to connect to local
417 forwarded ports. By default, ssh(1) binds local port forwardings
418 to the loopback address. This prevents other remote hosts from
419 connecting to forwarded ports. GatewayPorts can be used to spec‐
420 ify that ssh should bind local port forwardings to the wildcard
421 address, thus allowing remote hosts to connect to forwarded
422 ports. The argument must be yes or no (the default).
423 GlobalKnownHostsFile
425 Specifies one or more files to use for the global host key data‐
426 base, separated by whitespace. The default is
427 /etc/gsissh/ssh_known_hosts, /etc/gsissh/ssh_known_hosts2.
428 GSSAPIAuthentication
430 Specifies whether user authentication based on GSSAPI is allowed.
431 The default is yes.
432 GSSAPIClientIdentity
434 If set, specifies the GSSAPI client identity that ssh should use
435 when connecting to the server. The default is unset, which means
436 that the default identity will be used.
437 GSSAPIDelegateCredentials
439 Forward (delegate) credentials to the server. The default is
440 yes.
441 GSSAPIKeyExchange
443 Specifies whether key exchange based on GSSAPI may be used. When
444 using GSSAPI key exchange the server need not have a host key.
445 The default is “yes”.
446 GSSAPIRenewalForcesRekey
448 If set to “yes” then renewal of the client's GSSAPI credentials
449 will force the rekeying of the ssh connection. With a compatible
450 server, this will delegate the renewed credentials to a session
451 on the server.
452 Checks are made to ensure that credentials are only propagated
454 when the new credentials match the old ones on the originating
455 client and where the receiving server still has the old set in
456 its cache.
457 The default is “no”.
459 For this to work GSSAPIKeyExchange needs to be enabled in the
461 server and also used by the client.
462 GSSAPIServerIdentity
464 If set, specifies the GSSAPI server identity that ssh should
465 expect when connecting to the server. The default is unset, which
466 means that the expected GSSAPI server identity will be determined
467 from the target hostname.
468 GSSAPITrustDns
470 Set to “yes” to indicate that the DNS is trusted to securely
471 canonicalize the name of the host being connected to. If “no”,
472 the hostname entered on the command line will be passed untouched
473 to the GSSAPI library. The default is “no”.
474 GSSAPIKexAlgorithms
476 The default is handled system-wide by crypto-policies(7). To see
477 the defaults and how to modify this default, see manual page
478 update-crypto-policies(8).
479 The list of key exchange algorithms that are offered for GSSAPI
481 key exchange. Possible values are
482 gss-gex-sha1-,
484 gss-group1-sha1-,
485 gss-group14-sha1-,
486 gss-group14-sha256-,
487 gss-group16-sha512-,
488 gss-nistp256-sha256-,
489 gss-curve25519-sha256-
490 This option only applies to connections using GSSAPI.
492 HashKnownHosts
494 Indicates that ssh(1) should hash host names and addresses when
495 they are added to ~/.ssh/known_hosts. These hashed names may be
496 used normally by ssh(1) and sshd(8), but they do not visually
497 reveal identifying information if the file's contents are dis‐
498 closed. The default is no. Note that existing names and
499 addresses in known hosts files will not be converted automati‐
500 cally, but may be manually hashed using ssh-keygen(1).
501 HostbasedAuthentication
503 Specifies whether to try rhosts based authentication with public
504 key authentication. The argument must be yes or no (the
505 default).
506 HostbasedKeyTypes
508 Specifies the key types that will be used for hostbased authenti‐
509 cation as a comma-separated list of patterns. Alternately if the
510 specified list begins with a ‘+’ character, then the specified
511 key types will be appended to the default set instead of replac‐
512 ing them. If the specified list begins with a ‘-’ character,
513 then the specified key types (including wildcards) will be
514 removed from the default set instead of replacing them. If the
515 specified list begins with a ‘^’ character, then the specified
516 key types will be placed at the head of the default set. The
517 default for this option is:
518 ecdsa-sha2-nistp256-cert-v01@openssh.com,
520 ecdsa-sha2-nistp384-cert-v01@openssh.com,
521 ecdsa-sha2-nistp521-cert-v01@openssh.com,
522 sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
523 ssh-ed25519-cert-v01@openssh.com,
524 sk-ssh-ed25519-cert-v01@openssh.com,
525 rsa-sha2-512-cert-v01@openssh.com,
526 rsa-sha2-256-cert-v01@openssh.com,
527 ssh-rsa-cert-v01@openssh.com,
528 ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
529 sk-ecdsa-sha2-nistp256@openssh.com,
530 ssh-ed25519,sk-ssh-ed25519@openssh.com,
531 rsa-sha2-512,rsa-sha2-256,ssh-rsa
532 The -Q option of ssh(1) may be used to list supported key types.
534 HostKeyAlgorithms
536 Specifies the host key algorithms that the client wants to use in
537 order of preference. Alternately if the specified list begins
538 with a ‘+’ character, then the specified key types will be
539 appended to the default set instead of replacing them. If the
540 specified list begins with a ‘-’ character, then the specified
541 key types (including wildcards) will be removed from the default
542 set instead of replacing them. If the specified list begins with
543 a ‘^’ character, then the specified key types will be placed at
544 the head of the default set. The default for this option is:
545 ecdsa-sha2-nistp256-cert-v01@openssh.com,
547 ecdsa-sha2-nistp384-cert-v01@openssh.com,
548 ecdsa-sha2-nistp521-cert-v01@openssh.com,
549 sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,
550 ssh-ed25519-cert-v01@openssh.com,
551 sk-ssh-ed25519-cert-v01@openssh.com,
552 rsa-sha2-512-cert-v01@openssh.com,
553 rsa-sha2-256-cert-v01@openssh.com,
554 ssh-rsa-cert-v01@openssh.com,
555 ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
556 sk-ecdsa-sha2-nistp256@openssh.com,
557 ssh-ed25519,sk-ssh-ed25519@openssh.com,
558 rsa-sha2-512,rsa-sha2-256,ssh-rsa
559 If hostkeys are known for the destination host then this default
561 is modified to prefer their algorithms.
562 The list of available key types may also be obtained using "ssh
564 -Q HostKeyAlgorithms".
565 HostKeyAlias
567 Specifies an alias that should be used instead of the real host
568 name when looking up or saving the host key in the host key data‐
569 base files and when validating host certificates. This option is
570 useful for tunneling SSH connections or for multiple servers run‐
571 ning on a single host.
572 Hostname
574 Specifies the real host name to log into. This can be used to
575 specify nicknames or abbreviations for hosts. Arguments to
576 Hostname accept the tokens described in the TOKENS section.
577 Numeric IP addresses are also permitted (both on the command line
578 and in Hostname specifications). The default is the name given
579 on the command line.
580 IdentitiesOnly
582 Specifies that ssh(1) should only use the configured authentica‐
583 tion identity and certificate files (either the default files, or
584 those explicitly configured in the ssh_config files or passed on
585 the ssh(1) command-line), even if ssh-agent(1) or a
586 PKCS11Provider or SecurityKeyProvider offers more identities.
587 The argument to this keyword must be yes or no (the default).
588 This option is intended for situations where ssh-agent offers
589 many different identities.
590 IdentityAgent
592 Specifies the UNIX-domain socket used to communicate with the
593 authentication agent.
594 This option overrides the SSH_AUTH_SOCK environment variable and
596 can be used to select a specific agent. Setting the socket name
597 to none disables the use of an authentication agent. If the
598 string "SSH_AUTH_SOCK" is specified, the location of the socket
599 will be read from the SSH_AUTH_SOCK environment variable. Other‐
600 wise if the specified value begins with a ‘$’ character, then it
601 will be treated as an environment variable containing the loca‐
602 tion of the socket.
603 Arguments to IdentityAgent may use the tilde syntax to refer to a
605 user's home directory or the tokens described in the TOKENS sec‐
606 tion.
607 IdentityFile
609 Specifies a file from which the user's DSA, ECDSA, authenticator-
610 hosted ECDSA, Ed25519, authenticator-hosted Ed25519 or RSA
611 authentication identity is read. The default is ~/.ssh/id_dsa,
612 ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519,
613 ~/.ssh/id_ed25519_sk and ~/.ssh/id_rsa. Additionally, any iden‐
614 tities represented by the authentication agent will be used for
615 authentication unless IdentitiesOnly is set. If no certificates
616 have been explicitly specified by CertificateFile, ssh(1) will
617 try to load certificate information from the filename obtained by
618 appending -cert.pub to the path of a specified IdentityFile.
619 Arguments to IdentityFile may use the tilde syntax to refer to a
621 user's home directory or the tokens described in the TOKENS sec‐
622 tion.
623 It is possible to have multiple identity files specified in con‐
625 figuration files; all these identities will be tried in sequence.
626 Multiple IdentityFile directives will add to the list of identi‐
627 ties tried (this behaviour differs from that of other configura‐
628 tion directives).
629 IdentityFile may be used in conjunction with IdentitiesOnly to
631 select which identities in an agent are offered during authenti‐
632 cation. IdentityFile may also be used in conjunction with
633 CertificateFile in order to provide any certificate also needed
634 for authentication with the identity.
635 The authentication identity can be also specified in a form of
637 PKCS#11 URI starting with a string pkcs11:. There is supported a
638 subset of the PKCS#11 URI as defined in RFC 7512 (implemented
639 path arguments id, manufacturer, object, token and query argu‐
640 ments module-path and pin-value ). The URI can not be in quotes.
641 IgnoreUnknown
643 Specifies a pattern-list of unknown options to be ignored if they
644 are encountered in configuration parsing. This may be used to
645 suppress errors if ssh_config contains options that are unrecog‐
646 nised by ssh(1). It is recommended that IgnoreUnknown be listed
647 early in the configuration file as it will not be applied to
648 unknown options that appear before it.
649 Include
651 Include the specified configuration file(s). Multiple pathnames
652 may be specified and each pathname may contain glob(7) wildcards
653 and, for user configurations, shell-like ‘~’ references to user
654 home directories. Files without absolute paths are assumed to be
655 in ~/.ssh if included in a user configuration file or /etc/ssh if
656 included from the system configuration file. Include directive
657 may appear inside a Match or Host block to perform conditional
658 inclusion.
659 IPQoS Specifies the IPv4 type-of-service or DSCP class for connections.
661 Accepted values are af11, af12, af13, af21, af22, af23, af31,
662 af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5, cs6,
663 cs7, ef, le, lowdelay, throughput, reliability, a numeric value,
664 or none to use the operating system default. This option may
665 take one or two arguments, separated by whitespace. If one argu‐
666 ment is specified, it is used as the packet class uncondition‐
667 ally. If two values are specified, the first is automatically
668 selected for interactive sessions and the second for non-interac‐
669 tive sessions. The default is af21 (Low-Latency Data) for inter‐
670 active sessions and cs1 (Lower Effort) for non-interactive ses‐
671 sions.
672 KbdInteractiveAuthentication
674 Specifies whether to use keyboard-interactive authentication.
675 The argument to this keyword must be yes (the default) or no.
676 KbdInteractiveDevices
678 Specifies the list of methods to use in keyboard-interactive
679 authentication. Multiple method names must be comma-separated.
680 The default is to use the server specified list. The methods
681 available vary depending on what the server supports. For an
682 OpenSSH server, it may be zero or more of: bsdauth and pam.
683 KexAlgorithms
685 The default is handled system-wide by crypto-policies(7). To see
686 the defaults and how to modify this default, see manual page
687 update-crypto-policies(8).
688 Specifies the available KEX (Key Exchange) algorithms. Multiple
690 algorithms must be comma-separated. If the specified list begins
691 with a ‘+’ character, then the specified methods will be appended
692 to the built-in default set instead of replacing them. If the
693 specified list begins with a ‘-’ character, then the specified
694 methods (including wildcards) will be removed from the built-in
695 default set instead of replacing them. If the specified list
696 begins with a ‘^’ character, then the specified methods will be
697 placed at the head of the built-in default set.
698 The list of available key exchange algorithms may also be
700 obtained using "ssh -Q kex".
701 LocalCommand
703 Specifies a command to execute on the local machine after suc‐
704 cessfully connecting to the server. The command string extends
705 to the end of the line, and is executed with the user's shell.
706 Arguments to LocalCommand accept the tokens described in the
707 TOKENS section.
708 The command is run synchronously and does not have access to the
710 session of the ssh(1) that spawned it. It should not be used for
711 interactive commands.
712 This directive is ignored unless PermitLocalCommand has been
714 enabled.
715 LocalForward
717 Specifies that a TCP port on the local machine be forwarded over
718 the secure channel to the specified host and port from the remote
719 machine. The first argument must be [bind_address:]port and the
720 second argument must be host:hostport. IPv6 addresses can be
721 specified by enclosing addresses in square brackets. Multiple
722 forwardings may be specified, and additional forwardings can be
723 given on the command line. Only the superuser can forward privi‐
724 leged ports. By default, the local port is bound in accordance
725 with the GatewayPorts setting. However, an explicit bind_address
726 may be used to bind the connection to a specific address. The
727 bind_address of localhost indicates that the listening port be
728 bound for local use only, while an empty address or ‘*’ indicates
729 that the port should be available from all interfaces.
730 LogLevel
732 Gives the verbosity level that is used when logging messages from
733 ssh(1). The possible values are: QUIET, FATAL, ERROR, INFO, VER‐
734 BOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO.
735 DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify
736 higher levels of verbose output.
737 MACs The default is handled system-wide by crypto-policies(7). To see
739 the defaults and how to modify this default, see manual page
740 update-crypto-policies(8).
741 Specifies the MAC (message authentication code) algorithms in
743 order of preference. The MAC algorithm is used for data
744 integrity protection. Multiple algorithms must be comma-sepa‐
745 rated. If the specified list begins with a ‘+’ character, then
746 the specified algorithms will be appended to the built-in default
747 set instead of replacing them. If the specified list begins with
748 a ‘-’ character, then the specified algorithms (including wild‐
749 cards) will be removed from the built-in default set instead of
750 replacing them. If the specified list begins with a ‘^’ charac‐
751 ter, then the specified algorithms will be placed at the head of
752 the built-in default set.
753 The algorithms that contain "-etm" calculate the MAC after
755 encryption (encrypt-then-mac). These are considered safer and
756 their use recommended.
757 The list of available MAC algorithms may also be obtained using
759 "ssh -Q mac".
760 NoHostAuthenticationForLocalhost
762 Disable host authentication for localhost (loopback addresses).
763 The argument to this keyword must be yes or no (the default).
764 NumberOfPasswordPrompts
766 Specifies the number of password prompts before giving up. The
767 argument to this keyword must be an integer. The default is 3.
768 PasswordAuthentication
770 Specifies whether to use password authentication. The argument
771 to this keyword must be yes (the default) or no.
772 PermitLocalCommand
774 Allow local command execution via the LocalCommand option or
775 using the !command escape sequence in ssh(1). The argument must
776 be yes or no (the default).
777 PKCS11Provider
779 Specifies which PKCS#11 provider to use or none to indicate that
780 no provider should be used (the default). The argument to this
781 keyword is a path to the PKCS#11 shared library ssh(1) should use
782 to communicate with a PKCS#11 token providing keys for user
783 authentication.
784 Port Specifies the port number to connect on the remote host. The
786 default is 22.
787 PreferredAuthentications
789 Specifies the order in which the client should try authentication
790 methods. This allows a client to prefer one method (e.g.
791 keyboard-interactive) over another method (e.g. password). The
792 default is:
793 gssapi-keyex,gssapi-with-mic,hostbased,publickey,
795 keyboard-interactive,password
796 ProxyCommand
798 Specifies the command to use to connect to the server. The com‐
799 mand string extends to the end of the line, and is executed using
800 the user's shell ‘exec’ directive to avoid a lingering shell
801 process.
802 Arguments to ProxyCommand accept the tokens described in the
804 TOKENS section. The command can be basically anything, and
805 should read from its standard input and write to its standard
806 output. It should eventually connect an sshd(8) server running
807 on some machine, or execute sshd -i somewhere. Host key manage‐
808 ment will be done using the Hostname of the host being connected
809 (defaulting to the name typed by the user). Setting the command
810 to none disables this option entirely. Note that CheckHostIP is
811 not available for connects with a proxy command.
812 This directive is useful in conjunction with nc(1) and its proxy
814 support. For example, the following directive would connect via
815 an HTTP proxy at 192.0.2.0:
816 ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p
818 ProxyJump
820 Specifies one or more jump proxies as either [user@]host[:port]
821 or an ssh URI. Multiple proxies may be separated by comma char‐
822 acters and will be visited sequentially. Setting this option
823 will cause ssh(1) to connect to the target host by first making a
824 ssh(1) connection to the specified ProxyJump host and then estab‐
825 lishing a TCP forwarding to the ultimate target from there.
826 Note that this option will compete with the ProxyCommand option -
828 whichever is specified first will prevent later instances of the
829 other from taking effect.
830 Note also that the configuration for the destination host (either
832 supplied via the command-line or the configuration file) is not
833 generally applied to jump hosts. ~/.ssh/config should be used if
834 specific configuration is required for jump hosts.
835 ProxyUseFdpass
837 Specifies that ProxyCommand will pass a connected file descriptor
838 back to ssh(1) instead of continuing to execute and pass data.
839 The default is no.
840 PubkeyAcceptedKeyTypes
842 The default is handled system-wide by crypto-policies(7). To see
843 the defaults and how to modify this default, see manual page
844 update-crypto-policies(8).
845 Specifies the key types that will be used for public key authen‐
847 tication as a comma-separated list of patterns. If the specified
848 list begins with a ‘+’ character, then the key types after it
849 will be appended to the built-in default instead of replacing it.
850 If the specified list begins with a ‘-’ character, then the spec‐
851 ified key types (including wildcards) will be removed from the
852 built-in default set instead of replacing them. If the specified
853 list begins with a ‘^’ character, then the specified key types
854 will be placed at the head of the built-in default set.
855 The list of available key types may also be obtained using "ssh
857 -Q PubkeyAcceptedKeyTypes".
858 PubkeyAuthentication
860 Specifies whether to try public key authentication. The argument
861 to this keyword must be yes (the default) or no.
862 RekeyLimit
864 Specifies the maximum amount of data that may be transmitted
865 before the session key is renegotiated, optionally followed a
866 maximum amount of time that may pass before the session key is
867 renegotiated. The first argument is specified in bytes and may
868 have a suffix of ‘K’, ‘M’, or ‘G’ to indicate Kilobytes,
869 Megabytes, or Gigabytes, respectively. The default is between
870 ‘1G’ and ‘4G’, depending on the cipher. The optional second
871 value is specified in seconds and may use any of the units docu‐
872 mented in the TIME FORMATS section of sshd_config(5). The
873 default value for RekeyLimit is default none, which means that
874 rekeying is performed after the cipher's default amount of data
875 has been sent or received and no time based rekeying is done.
876 RemoteCommand
878 Specifies a command to execute on the remote machine after suc‐
879 cessfully connecting to the server. The command string extends
880 to the end of the line, and is executed with the user's shell.
881 Arguments to RemoteCommand accept the tokens described in the
882 TOKENS section.
883 RemoteForward
885 Specifies that a TCP port on the remote machine be forwarded over
886 the secure channel. The remote port may either be forwarded to a
887 specified host and port from the local machine, or may act as a
888 SOCKS 4/5 proxy that allows a remote client to connect to arbi‐
889 trary destinations from the local machine. The first argument
890 must be [bind_address:]port If forwarding to a specific destina‐
891 tion then the second argument must be host:hostport, otherwise if
892 no destination argument is specified then the remote forwarding
893 will be established as a SOCKS proxy.
894 IPv6 addresses can be specified by enclosing addresses in square
896 brackets. Multiple forwardings may be specified, and additional
897 forwardings can be given on the command line. Privileged ports
898 can be forwarded only when logging in as root on the remote
899 machine.
900 If the port argument is 0, the listen port will be dynamically
902 allocated on the server and reported to the client at run time.
903 If the bind_address is not specified, the default is to only bind
905 to loopback addresses. If the bind_address is ‘*’ or an empty
906 string, then the forwarding is requested to listen on all inter‐
907 faces. Specifying a remote bind_address will only succeed if the
908 server's GatewayPorts option is enabled (see sshd_config(5)).
909 RequestTTY
911 Specifies whether to request a pseudo-tty for the session. The
912 argument may be one of: no (never request a TTY), yes (always
913 request a TTY when standard input is a TTY), force (always
914 request a TTY) or auto (request a TTY when opening a login ses‐
915 sion). This option mirrors the -t and -T flags for ssh(1).
916 RevokedHostKeys
918 Specifies revoked host public keys. Keys listed in this file
919 will be refused for host authentication. Note that if this file
920 does not exist or is not readable, then host authentication will
921 be refused for all hosts. Keys may be specified as a text file,
922 listing one public key per line, or as an OpenSSH Key Revocation
923 List (KRL) as generated by ssh-keygen(1). For more information
924 on KRLs, see the KEY REVOCATION LISTS section in ssh-keygen(1).
925 SecurityKeyProvider
927 Specifies a path to a library that will be used when loading any
928 FIDO authenticator-hosted keys, overriding the default of using
929 the built-in USB HID support.
930 If the specified value begins with a ‘$’ character, then it will
932 be treated as an environment variable containing the path to the
933 library.
934 SendEnv
936 Specifies what variables from the local environ(7) should be sent
937 to the server. The server must also support it, and the server
938 must be configured to accept these environment variables. Note
939 that the TERM environment variable is always sent whenever a
940 pseudo-terminal is requested as it is required by the protocol.
941 Refer to AcceptEnv in sshd_config(5) for how to configure the
942 server. Variables are specified by name, which may contain wild‐
943 card characters. Multiple environment variables may be separated
944 by whitespace or spread across multiple SendEnv directives.
945 See PATTERNS for more information on patterns.
947 It is possible to clear previously set SendEnv variable names by
949 prefixing patterns with -. The default is not to send any envi‐
950 ronment variables.
951 ServerAliveCountMax
953 Sets the number of server alive messages (see below) which may be
954 sent without ssh(1) receiving any messages back from the server.
955 If this threshold is reached while server alive messages are
956 being sent, ssh will disconnect from the server, terminating the
957 session. It is important to note that the use of server alive
958 messages is very different from TCPKeepAlive (below). The server
959 alive messages are sent through the encrypted channel and there‐
960 fore will not be spoofable. The TCP keepalive option enabled by
961 TCPKeepAlive is spoofable. The server alive mechanism is valu‐
962 able when the client or server depend on knowing when a connec‐
963 tion has become unresponsive.
964 The default value is 3. If, for example, ServerAliveInterval
966 (see below) is set to 15 and ServerAliveCountMax is left at the
967 default, if the server becomes unresponsive, ssh will disconnect
968 after approximately 45 seconds.
969 ServerAliveInterval
971 Sets a timeout interval in seconds after which if no data has
972 been received from the server, ssh(1) will send a message through
973 the encrypted channel to request a response from the server. The
974 default is 0, indicating that these messages will not be sent to
975 the server.
976 SetEnv Directly specify one or more environment variables and their con‐
978 tents to be sent to the server. Similarly to SendEnv, the server
979 must be prepared to accept the environment variable.
980 StreamLocalBindMask
982 Sets the octal file creation mode mask (umask) used when creating
983 a Unix-domain socket file for local or remote port forwarding.
984 This option is only used for port forwarding to a Unix-domain
985 socket file.
986 The default value is 0177, which creates a Unix-domain socket
988 file that is readable and writable only by the owner. Note that
989 not all operating systems honor the file mode on Unix-domain
990 socket files.
991 StreamLocalBindUnlink
993 Specifies whether to remove an existing Unix-domain socket file
994 for local or remote port forwarding before creating a new one.
995 If the socket file already exists and StreamLocalBindUnlink is
996 not enabled, ssh will be unable to forward the port to the Unix-
997 domain socket file. This option is only used for port forwarding
998 to a Unix-domain socket file.
999 The argument must be yes or no (the default).
1001 StrictHostKeyChecking
1003 If this flag is set to yes, ssh(1) will never automatically add
1004 host keys to the ~/.ssh/known_hosts file, and refuses to connect
1005 to hosts whose host key has changed. This provides maximum pro‐
1006 tection against man-in-the-middle (MITM) attacks, though it can
1007 be annoying when the /etc/gsissh/ssh_known_hosts file is poorly
1008 maintained or when connections to new hosts are frequently made.
1009 This option forces the user to manually add all new hosts.
1010 If this flag is set to “accept-new” then ssh will automatically
1012 add new host keys to the user known hosts files, but will not
1013 permit connections to hosts with changed host keys. If this flag
1014 is set to “no” or “off”, ssh will automatically add new host keys
1015 to the user known hosts files and allow connections to hosts with
1016 changed hostkeys to proceed, subject to some restrictions. If
1017 this flag is set to ask (the default), new host keys will be
1018 added to the user known host files only after the user has con‐
1019 firmed that is what they really want to do, and ssh will refuse
1020 to connect to hosts whose host key has changed. The host keys of
1021 known hosts will be verified automatically in all cases.
1022 SyslogFacility
1024 Gives the facility code that is used when logging messages from
1025 ssh(1). The possible values are: DAEMON, USER, AUTH, LOCAL0,
1026 LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The
1027 default is USER.
1028 TCPKeepAlive
1030 Specifies whether the system should send TCP keepalive messages
1031 to the other side. If they are sent, death of the connection or
1032 crash of one of the machines will be properly noticed. However,
1033 this means that connections will die if the route is down tempo‐
1034 rarily, and some people find it annoying.
1035 The default is yes (to send TCP keepalive messages), and the
1037 client will notice if the network goes down or the remote host
1038 dies. This is important in scripts, and many users want it too.
1039 To disable TCP keepalive messages, the value should be set to no.
1041 See also ServerAliveInterval for protocol-level keepalives.
1042 Tunnel Request tun(4) device forwarding between the client and the
1044 server. The argument must be yes, point-to-point (layer 3),
1045 ethernet (layer 2), or no (the default). Specifying yes requests
1046 the default tunnel mode, which is point-to-point.
1047 TunnelDevice
1049 Specifies the tun(4) devices to open on the client (local_tun)
1050 and the server (remote_tun).
1051 The argument must be local_tun[:remote_tun]. The devices may be
1053 specified by numerical ID or the keyword any, which uses the next
1054 available tunnel device. If remote_tun is not specified, it
1055 defaults to any. The default is any:any.
1056 UpdateHostKeys
1058 Specifies whether ssh(1) should accept notifications of addi‐
1059 tional hostkeys from the server sent after authentication has
1060 completed and add them to UserKnownHostsFile. The argument must
1061 be yes, no or ask. This option allows learning alternate
1062 hostkeys for a server and supports graceful key rotation by
1063 allowing a server to send replacement public keys before old ones
1064 are removed. Additional hostkeys are only accepted if the key
1065 used to authenticate the host was already trusted or explicitly
1066 accepted by the user.
1067 UpdateHostKeys is enabled by default if the user has not overrid‐
1069 den the default UserKnownHostsFile setting, otherwise
1070 UpdateHostKeys will be set to ask.
1071 If UpdateHostKeys is set to ask, then the user is asked to con‐
1073 firm the modifications to the known_hosts file. Confirmation is
1074 currently incompatible with ControlPersist, and will be disabled
1075 if it is enabled.
1076 Presently, only sshd(8) from OpenSSH 6.8 and greater support the
1078 "hostkeys@openssh.com" protocol extension used to inform the
1079 client of all the server's hostkeys.
1080 User Specifies the user to log in as. This can be useful when a dif‐
1082 ferent user name is used on different machines. This saves the
1083 trouble of having to remember to give the user name on the com‐
1084 mand line.
1085 UserKnownHostsFile
1087 Specifies one or more files to use for the user host key data‐
1088 base, separated by whitespace. The default is
1089 ~/.ssh/known_hosts, ~/.ssh/known_hosts2.
1090 VerifyHostKeyDNS
1092 Specifies whether to verify the remote key using DNS and SSHFP
1093 resource records. If this option is set to yes, the client will
1094 implicitly trust keys that match a secure fingerprint from DNS.
1095 Insecure fingerprints will be handled as if this option was set
1096 to ask. If this option is set to ask, information on fingerprint
1097 match will be displayed, but the user will still need to confirm
1098 new host keys according to the StrictHostKeyChecking option. The
1099 default is no.
1100 See also VERIFYING HOST KEYS in ssh(1).
1102 VisualHostKey
1104 If this flag is set to yes, an ASCII art representation of the
1105 remote host key fingerprint is printed in addition to the finger‐
1106 print string at login and for unknown host keys. If this flag is
1107 set to no (the default), no fingerprint strings are printed at
1108 login and only the fingerprint string will be printed for unknown
1109 host keys.
1110 XAuthLocation
1112 Specifies the full pathname of the xauth(1) program. The default
1113 is /usr/bin/xauth.
1114
1116 A pattern consists of zero or more non-whitespace characters, ‘*’ (a
1117 wildcard that matches zero or more characters), or ‘?’ (a wildcard that
1118 matches exactly one character). For example, to specify a set of decla‐
1119 rations for any host in the ".co.uk" set of domains, the following pat‐
1120 tern could be used:
1121 Host *.co.uk
1123 The following pattern would match any host in the 192.168.0.[0-9] network
1125 range:
1126 Host 192.168.0.?
1128 A pattern-list is a comma-separated list of patterns. Patterns within
1130 pattern-lists may be negated by preceding them with an exclamation mark
1131 (‘!’). For example, to allow a key to be used from anywhere within an
1132 organization except from the "dialup" pool, the following entry (in
1133 authorized_keys) could be used:
1134 from="!*.dialup.example.com,*.example.com"
1136 Note that a negated match will never produce a positive result by itself.
1138 For example, attempting to match "host3" against the following pattern-
1139 list will fail:
1140 from="!host1,!host2"
1142 The solution here is to include a term that will yield a positive match,
1144 such as a wildcard:
1145 from="!host1,!host2,*"
1147
1149 Arguments to some keywords can make use of tokens, which are expanded at
1150 runtime:
1151 %% A literal ‘%’.
1153 %C Hash of %l%h%p%r.
1154 %d Local user's home directory.
1155 %h The remote hostname.
1156 %i The local user ID.
1157 %L The local hostname.
1158 %l The local hostname, including the domain name.
1159 %n The original remote hostname, as given on the command line.
1160 %p The remote port.
1161 %r The remote username.
1162 %T The local tun(4) or tap(4) network interface assigned if tun‐
1163 nel forwarding was requested, or "NONE" otherwise.
1164 %u The local username.
1165 Match exec accepts the tokens %%, %h, %i, %L, %l, %n, %p, %r, and %u.
1167 CertificateFile accepts the tokens %%, %d, %h, %i, %l, %r, and %u.
1169 ControlPath accepts the tokens %%, %C, %h, %i, %L, %l, %n, %p, %r, and
1171 %u.
1172 Hostname accepts the tokens %% and %h.
1174 IdentityAgent and IdentityFile accept the tokens %%, %d, %h, %i, %l, %r,
1176 and %u.
1177 LocalCommand accepts the tokens %%, %C, %d, %h, %i, %l, %n, %p, %r, %T,
1179 and %u.
1180 ProxyCommand accepts the tokens %%, %h, %n, %p, and %r.
1182 RemoteCommand accepts the tokens %%, %C, %d, %h, %i, %l, %n, %p, %r, and
1184 %u.
1185
1187 ~/.ssh/config
1188 This is the per-user configuration file. The format of this file
1189 is described above. This file is used by the SSH client.
1190 Because of the potential for abuse, this file must have strict
1191 permissions: read/write for the user, and not writable by others.
1192 /etc/gsissh/ssh_config
1194 Systemwide configuration file. This file provides defaults for
1195 those values that are not specified in the user's configuration
1196 file, and for those users who do not have a configuration file.
1197 This file must be world-readable.
1198
1200 ssh(1)
1201
1203 OpenSSH is a derivative of the original and free ssh 1.2.12 release by
1204 Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
1205 de Raadt and Dug Song removed many bugs, re-added newer features and cre‐
1206 ated OpenSSH. Markus Friedl contributed the support for SSH protocol
1207 versions 1.5 and 2.0.
1208BSD May 10, 2020 BSD