diff options
Diffstat (limited to 'ssh.0')
-rw-r--r-- | ssh.0 | 980 |
1 files changed, 980 insertions, 0 deletions
@@ -0,0 +1,980 @@ | |||
1 | SSH(1) General Commands Manual SSH(1) | ||
2 | |||
3 | NAME | ||
4 | ssh M-bM-^@M-^S OpenSSH SSH client (remote login program) | ||
5 | |||
6 | SYNOPSIS | ||
7 | ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] | ||
8 | [-c cipher_spec] [-D [bind_address:]port] [-E log_file] | ||
9 | [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] | ||
10 | [-J destination] [-L address] [-l login_name] [-m mac_spec] | ||
11 | [-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address] | ||
12 | [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destination | ||
13 | [command] | ||
14 | |||
15 | DESCRIPTION | ||
16 | ssh (SSH client) is a program for logging into a remote machine and for | ||
17 | executing commands on a remote machine. It is intended to provide secure | ||
18 | encrypted communications between two untrusted hosts over an insecure | ||
19 | network. X11 connections, arbitrary TCP ports and UNIX-domain sockets | ||
20 | can also be forwarded over the secure channel. | ||
21 | |||
22 | ssh connects and logs into the specified destination, which may be | ||
23 | specified as either [user@]hostname or a URI of the form | ||
24 | ssh://[user@]hostname[:port]. The user must prove his/her identity to | ||
25 | the remote machine using one of several methods (see below). | ||
26 | |||
27 | If a command is specified, it is executed on the remote host instead of a | ||
28 | login shell. | ||
29 | |||
30 | The options are as follows: | ||
31 | |||
32 | -4 Forces ssh to use IPv4 addresses only. | ||
33 | |||
34 | -6 Forces ssh to use IPv6 addresses only. | ||
35 | |||
36 | -A Enables forwarding of the authentication agent connection. This | ||
37 | can also be specified on a per-host basis in a configuration | ||
38 | file. | ||
39 | |||
40 | Agent forwarding should be enabled with caution. Users with the | ||
41 | ability to bypass file permissions on the remote host (for the | ||
42 | agent's UNIX-domain socket) can access the local agent through | ||
43 | the forwarded connection. An attacker cannot obtain key material | ||
44 | from the agent, however they can perform operations on the keys | ||
45 | that enable them to authenticate using the identities loaded into | ||
46 | the agent. | ||
47 | |||
48 | -a Disables forwarding of the authentication agent connection. | ||
49 | |||
50 | -B bind_interface | ||
51 | Bind to the address of bind_interface before attempting to | ||
52 | connect to the destination host. This is only useful on systems | ||
53 | with more than one address. | ||
54 | |||
55 | -b bind_address | ||
56 | Use bind_address on the local machine as the source address of | ||
57 | the connection. Only useful on systems with more than one | ||
58 | address. | ||
59 | |||
60 | -C Requests compression of all data (including stdin, stdout, | ||
61 | stderr, and data for forwarded X11, TCP and UNIX-domain | ||
62 | connections). The compression algorithm is the same used by | ||
63 | gzip(1). Compression is desirable on modem lines and other slow | ||
64 | connections, but will only slow down things on fast networks. | ||
65 | The default value can be set on a host-by-host basis in the | ||
66 | configuration files; see the Compression option. | ||
67 | |||
68 | -c cipher_spec | ||
69 | Selects the cipher specification for encrypting the session. | ||
70 | cipher_spec is a comma-separated list of ciphers listed in order | ||
71 | of preference. See the Ciphers keyword in ssh_config(5) for more | ||
72 | information. | ||
73 | |||
74 | -D [bind_address:]port | ||
75 | Specifies a local M-bM-^@M-^\dynamicM-bM-^@M-^] application-level port forwarding. | ||
76 | This works by allocating a socket to listen to port on the local | ||
77 | side, optionally bound to the specified bind_address. Whenever a | ||
78 | connection is made to this port, the connection is forwarded over | ||
79 | the secure channel, and the application protocol is then used to | ||
80 | determine where to connect to from the remote machine. Currently | ||
81 | the SOCKS4 and SOCKS5 protocols are supported, and ssh will act | ||
82 | as a SOCKS server. Only root can forward privileged ports. | ||
83 | Dynamic port forwardings can also be specified in the | ||
84 | configuration file. | ||
85 | |||
86 | IPv6 addresses can be specified by enclosing the address in | ||
87 | square brackets. Only the superuser can forward privileged | ||
88 | ports. By default, the local port is bound in accordance with | ||
89 | the GatewayPorts setting. However, an explicit bind_address may | ||
90 | be used to bind the connection to a specific address. The | ||
91 | bind_address of M-bM-^@M-^\localhostM-bM-^@M-^] indicates that the listening port be | ||
92 | bound for local use only, while an empty address or M-bM-^@M-^X*M-bM-^@M-^Y indicates | ||
93 | that the port should be available from all interfaces. | ||
94 | |||
95 | -E log_file | ||
96 | Append debug logs to log_file instead of standard error. | ||
97 | |||
98 | -e escape_char | ||
99 | Sets the escape character for sessions with a pty (default: M-bM-^@M-^X~M-bM-^@M-^Y). | ||
100 | The escape character is only recognized at the beginning of a | ||
101 | line. The escape character followed by a dot (M-bM-^@M-^X.M-bM-^@M-^Y) closes the | ||
102 | connection; followed by control-Z suspends the connection; and | ||
103 | followed by itself sends the escape character once. Setting the | ||
104 | character to M-bM-^@M-^\noneM-bM-^@M-^] disables any escapes and makes the session | ||
105 | fully transparent. | ||
106 | |||
107 | -F configfile | ||
108 | Specifies an alternative per-user configuration file. If a | ||
109 | configuration file is given on the command line, the system-wide | ||
110 | configuration file (/etc/ssh/ssh_config) will be ignored. The | ||
111 | default for the per-user configuration file is ~/.ssh/config. | ||
112 | |||
113 | -f Requests ssh to go to background just before command execution. | ||
114 | This is useful if ssh is going to ask for passwords or | ||
115 | passphrases, but the user wants it in the background. This | ||
116 | implies -n. The recommended way to start X11 programs at a | ||
117 | remote site is with something like ssh -f host xterm. | ||
118 | |||
119 | If the ExitOnForwardFailure configuration option is set to M-bM-^@M-^\yesM-bM-^@M-^], | ||
120 | then a client started with -f will wait for all remote port | ||
121 | forwards to be successfully established before placing itself in | ||
122 | the background. | ||
123 | |||
124 | -G Causes ssh to print its configuration after evaluating Host and | ||
125 | Match blocks and exit. | ||
126 | |||
127 | -g Allows remote hosts to connect to local forwarded ports. If used | ||
128 | on a multiplexed connection, then this option must be specified | ||
129 | on the master process. | ||
130 | |||
131 | -I pkcs11 | ||
132 | Specify the PKCS#11 shared library ssh should use to communicate | ||
133 | with a PKCS#11 token providing keys for user authentication. | ||
134 | |||
135 | -i identity_file | ||
136 | Selects a file from which the identity (private key) for public | ||
137 | key authentication is read. The default is ~/.ssh/id_dsa, | ||
138 | ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa. Identity | ||
139 | files may also be specified on a per-host basis in the | ||
140 | configuration file. It is possible to have multiple -i options | ||
141 | (and multiple identities specified in configuration files). If | ||
142 | no certificates have been explicitly specified by the | ||
143 | CertificateFile directive, ssh will also try to load certificate | ||
144 | information from the filename obtained by appending -cert.pub to | ||
145 | identity filenames. | ||
146 | |||
147 | -J destination | ||
148 | Connect to the target host by first making a ssh connection to | ||
149 | the jump host described by destination and then establishing a | ||
150 | TCP forwarding to the ultimate destination from there. Multiple | ||
151 | jump hops may be specified separated by comma characters. This | ||
152 | is a shortcut to specify a ProxyJump configuration directive. | ||
153 | Note that configuration directives supplied on the command-line | ||
154 | generally apply to the destination host and not any specified | ||
155 | jump hosts. Use ~/.ssh/config to specify configuration for jump | ||
156 | hosts. | ||
157 | |||
158 | -K Enables GSSAPI-based authentication and forwarding (delegation) | ||
159 | of GSSAPI credentials to the server. | ||
160 | |||
161 | -k Disables forwarding (delegation) of GSSAPI credentials to the | ||
162 | server. | ||
163 | |||
164 | -L [bind_address:]port:host:hostport | ||
165 | -L [bind_address:]port:remote_socket | ||
166 | -L local_socket:host:hostport | ||
167 | -L local_socket:remote_socket | ||
168 | Specifies that connections to the given TCP port or Unix socket | ||
169 | on the local (client) host are to be forwarded to the given host | ||
170 | and port, or Unix socket, on the remote side. This works by | ||
171 | allocating a socket to listen to either a TCP port on the local | ||
172 | side, optionally bound to the specified bind_address, or to a | ||
173 | Unix socket. Whenever a connection is made to the local port or | ||
174 | socket, the connection is forwarded over the secure channel, and | ||
175 | a connection is made to either host port hostport, or the Unix | ||
176 | socket remote_socket, from the remote machine. | ||
177 | |||
178 | Port forwardings can also be specified in the configuration file. | ||
179 | Only the superuser can forward privileged ports. IPv6 addresses | ||
180 | can be specified by enclosing the address in square brackets. | ||
181 | |||
182 | By default, the local port is bound in accordance with the | ||
183 | GatewayPorts setting. However, an explicit bind_address may be | ||
184 | used to bind the connection to a specific address. The | ||
185 | bind_address of M-bM-^@M-^\localhostM-bM-^@M-^] indicates that the listening port be | ||
186 | bound for local use only, while an empty address or M-bM-^@M-^X*M-bM-^@M-^Y indicates | ||
187 | that the port should be available from all interfaces. | ||
188 | |||
189 | -l login_name | ||
190 | Specifies the user to log in as on the remote machine. This also | ||
191 | may be specified on a per-host basis in the configuration file. | ||
192 | |||
193 | -M Places the ssh client into M-bM-^@M-^\masterM-bM-^@M-^] mode for connection sharing. | ||
194 | Multiple -M options places ssh into M-bM-^@M-^\masterM-bM-^@M-^] mode but with | ||
195 | confirmation required using ssh-askpass(1) before each operation | ||
196 | that changes the multiplexing state (e.g. opening a new session). | ||
197 | Refer to the description of ControlMaster in ssh_config(5) for | ||
198 | details. | ||
199 | |||
200 | -m mac_spec | ||
201 | A comma-separated list of MAC (message authentication code) | ||
202 | algorithms, specified in order of preference. See the MACs | ||
203 | keyword for more information. | ||
204 | |||
205 | -N Do not execute a remote command. This is useful for just | ||
206 | forwarding ports. | ||
207 | |||
208 | -n Redirects stdin from /dev/null (actually, prevents reading from | ||
209 | stdin). This must be used when ssh is run in the background. A | ||
210 | common trick is to use this to run X11 programs on a remote | ||
211 | machine. For example, ssh -n shadows.cs.hut.fi emacs & will | ||
212 | start an emacs on shadows.cs.hut.fi, and the X11 connection will | ||
213 | be automatically forwarded over an encrypted channel. The ssh | ||
214 | program will be put in the background. (This does not work if | ||
215 | ssh needs to ask for a password or passphrase; see also the -f | ||
216 | option.) | ||
217 | |||
218 | -O ctl_cmd | ||
219 | Control an active connection multiplexing master process. When | ||
220 | the -O option is specified, the ctl_cmd argument is interpreted | ||
221 | and passed to the master process. Valid commands are: M-bM-^@M-^\checkM-bM-^@M-^] | ||
222 | (check that the master process is running), M-bM-^@M-^\forwardM-bM-^@M-^] (request | ||
223 | forwardings without command execution), M-bM-^@M-^\cancelM-bM-^@M-^] (cancel | ||
224 | forwardings), M-bM-^@M-^\exitM-bM-^@M-^] (request the master to exit), and M-bM-^@M-^\stopM-bM-^@M-^] | ||
225 | (request the master to stop accepting further multiplexing | ||
226 | requests). | ||
227 | |||
228 | -o option | ||
229 | Can be used to give options in the format used in the | ||
230 | configuration file. This is useful for specifying options for | ||
231 | which there is no separate command-line flag. For full details | ||
232 | of the options listed below, and their possible values, see | ||
233 | ssh_config(5). | ||
234 | |||
235 | AddKeysToAgent | ||
236 | AddressFamily | ||
237 | BatchMode | ||
238 | BindAddress | ||
239 | CanonicalDomains | ||
240 | CanonicalizeFallbackLocal | ||
241 | CanonicalizeHostname | ||
242 | CanonicalizeMaxDots | ||
243 | CanonicalizePermittedCNAMEs | ||
244 | CASignatureAlgorithms | ||
245 | CertificateFile | ||
246 | ChallengeResponseAuthentication | ||
247 | CheckHostIP | ||
248 | Ciphers | ||
249 | ClearAllForwardings | ||
250 | Compression | ||
251 | ConnectionAttempts | ||
252 | ConnectTimeout | ||
253 | ControlMaster | ||
254 | ControlPath | ||
255 | ControlPersist | ||
256 | DynamicForward | ||
257 | EscapeChar | ||
258 | ExitOnForwardFailure | ||
259 | FingerprintHash | ||
260 | ForwardAgent | ||
261 | ForwardX11 | ||
262 | ForwardX11Timeout | ||
263 | ForwardX11Trusted | ||
264 | GatewayPorts | ||
265 | GlobalKnownHostsFile | ||
266 | GSSAPIAuthentication | ||
267 | GSSAPIDelegateCredentials | ||
268 | HashKnownHosts | ||
269 | Host | ||
270 | HostbasedAuthentication | ||
271 | HostbasedKeyTypes | ||
272 | HostKeyAlgorithms | ||
273 | HostKeyAlias | ||
274 | Hostname | ||
275 | IdentitiesOnly | ||
276 | IdentityAgent | ||
277 | IdentityFile | ||
278 | IPQoS | ||
279 | KbdInteractiveAuthentication | ||
280 | KbdInteractiveDevices | ||
281 | KexAlgorithms | ||
282 | LocalCommand | ||
283 | LocalForward | ||
284 | LogLevel | ||
285 | MACs | ||
286 | Match | ||
287 | NoHostAuthenticationForLocalhost | ||
288 | NumberOfPasswordPrompts | ||
289 | PasswordAuthentication | ||
290 | PermitLocalCommand | ||
291 | PKCS11Provider | ||
292 | Port | ||
293 | PreferredAuthentications | ||
294 | ProxyCommand | ||
295 | ProxyJump | ||
296 | ProxyUseFdpass | ||
297 | PubkeyAcceptedKeyTypes | ||
298 | PubkeyAuthentication | ||
299 | RekeyLimit | ||
300 | RemoteCommand | ||
301 | RemoteForward | ||
302 | RequestTTY | ||
303 | SendEnv | ||
304 | ServerAliveInterval | ||
305 | ServerAliveCountMax | ||
306 | SetEnv | ||
307 | StreamLocalBindMask | ||
308 | StreamLocalBindUnlink | ||
309 | StrictHostKeyChecking | ||
310 | TCPKeepAlive | ||
311 | Tunnel | ||
312 | TunnelDevice | ||
313 | UpdateHostKeys | ||
314 | User | ||
315 | UserKnownHostsFile | ||
316 | VerifyHostKeyDNS | ||
317 | VisualHostKey | ||
318 | XAuthLocation | ||
319 | |||
320 | -p port | ||
321 | Port to connect to on the remote host. This can be specified on | ||
322 | a per-host basis in the configuration file. | ||
323 | |||
324 | -Q query_option | ||
325 | Queries ssh for the algorithms supported for the specified | ||
326 | version 2. The available features are: cipher (supported | ||
327 | symmetric ciphers), cipher-auth (supported symmetric ciphers that | ||
328 | support authenticated encryption), help (supported query terms | ||
329 | for use with the -Q flag), mac (supported message integrity | ||
330 | codes), kex (key exchange algorithms), key (key types), key-cert | ||
331 | (certificate key types), key-plain (non-certificate key types), | ||
332 | protocol-version (supported SSH protocol versions), and sig | ||
333 | (supported signature algorithms). | ||
334 | |||
335 | -q Quiet mode. Causes most warning and diagnostic messages to be | ||
336 | suppressed. | ||
337 | |||
338 | -R [bind_address:]port:host:hostport | ||
339 | -R [bind_address:]port:local_socket | ||
340 | -R remote_socket:host:hostport | ||
341 | -R remote_socket:local_socket | ||
342 | -R [bind_address:]port | ||
343 | Specifies that connections to the given TCP port or Unix socket | ||
344 | on the remote (server) host are to be forwarded to the local | ||
345 | side. | ||
346 | |||
347 | This works by allocating a socket to listen to either a TCP port | ||
348 | or to a Unix socket on the remote side. Whenever a connection is | ||
349 | made to this port or Unix socket, the connection is forwarded | ||
350 | over the secure channel, and a connection is made from the local | ||
351 | machine to either an explicit destination specified by host port | ||
352 | hostport, or local_socket, or, if no explicit destination was | ||
353 | specified, ssh will act as a SOCKS 4/5 proxy and forward | ||
354 | connections to the destinations requested by the remote SOCKS | ||
355 | client. | ||
356 | |||
357 | Port forwardings can also be specified in the configuration file. | ||
358 | Privileged ports can be forwarded only when logging in as root on | ||
359 | the remote machine. IPv6 addresses can be specified by enclosing | ||
360 | the address in square brackets. | ||
361 | |||
362 | By default, TCP listening sockets on the server will be bound to | ||
363 | the loopback interface only. This may be overridden by | ||
364 | specifying a bind_address. An empty bind_address, or the address | ||
365 | M-bM-^@M-^X*M-bM-^@M-^Y, indicates that the remote socket should listen on all | ||
366 | interfaces. Specifying a remote bind_address will only succeed | ||
367 | if the server's GatewayPorts option is enabled (see | ||
368 | sshd_config(5)). | ||
369 | |||
370 | If the port argument is M-bM-^@M-^X0M-bM-^@M-^Y, the listen port will be dynamically | ||
371 | allocated on the server and reported to the client at run time. | ||
372 | When used together with -O forward the allocated port will be | ||
373 | printed to the standard output. | ||
374 | |||
375 | -S ctl_path | ||
376 | Specifies the location of a control socket for connection | ||
377 | sharing, or the string M-bM-^@M-^\noneM-bM-^@M-^] to disable connection sharing. | ||
378 | Refer to the description of ControlPath and ControlMaster in | ||
379 | ssh_config(5) for details. | ||
380 | |||
381 | -s May be used to request invocation of a subsystem on the remote | ||
382 | system. Subsystems facilitate the use of SSH as a secure | ||
383 | transport for other applications (e.g. sftp(1)). The subsystem | ||
384 | is specified as the remote command. | ||
385 | |||
386 | -T Disable pseudo-terminal allocation. | ||
387 | |||
388 | -t Force pseudo-terminal allocation. This can be used to execute | ||
389 | arbitrary screen-based programs on a remote machine, which can be | ||
390 | very useful, e.g. when implementing menu services. Multiple -t | ||
391 | options force tty allocation, even if ssh has no local tty. | ||
392 | |||
393 | -V Display the version number and exit. | ||
394 | |||
395 | -v Verbose mode. Causes ssh to print debugging messages about its | ||
396 | progress. This is helpful in debugging connection, | ||
397 | authentication, and configuration problems. Multiple -v options | ||
398 | increase the verbosity. The maximum is 3. | ||
399 | |||
400 | -W host:port | ||
401 | Requests that standard input and output on the client be | ||
402 | forwarded to host on port over the secure channel. Implies -N, | ||
403 | -T, ExitOnForwardFailure and ClearAllForwardings, though these | ||
404 | can be overridden in the configuration file or using -o command | ||
405 | line options. | ||
406 | |||
407 | -w local_tun[:remote_tun] | ||
408 | Requests tunnel device forwarding with the specified tun(4) | ||
409 | devices between the client (local_tun) and the server | ||
410 | (remote_tun). | ||
411 | |||
412 | The devices may be specified by numerical ID or the keyword | ||
413 | M-bM-^@M-^\anyM-bM-^@M-^], which uses the next available tunnel device. If | ||
414 | remote_tun is not specified, it defaults to M-bM-^@M-^\anyM-bM-^@M-^]. See also the | ||
415 | Tunnel and TunnelDevice directives in ssh_config(5). | ||
416 | |||
417 | If the Tunnel directive is unset, it will be set to the default | ||
418 | tunnel mode, which is M-bM-^@M-^\point-to-pointM-bM-^@M-^]. If a different Tunnel | ||
419 | forwarding mode it desired, then it should be specified before | ||
420 | -w. | ||
421 | |||
422 | -X Enables X11 forwarding. This can also be specified on a per-host | ||
423 | basis in a configuration file. | ||
424 | |||
425 | X11 forwarding should be enabled with caution. Users with the | ||
426 | ability to bypass file permissions on the remote host (for the | ||
427 | user's X authorization database) can access the local X11 display | ||
428 | through the forwarded connection. An attacker may then be able | ||
429 | to perform activities such as keystroke monitoring. | ||
430 | |||
431 | For this reason, X11 forwarding is subjected to X11 SECURITY | ||
432 | extension restrictions by default. Please refer to the ssh -Y | ||
433 | option and the ForwardX11Trusted directive in ssh_config(5) for | ||
434 | more information. | ||
435 | |||
436 | -x Disables X11 forwarding. | ||
437 | |||
438 | -Y Enables trusted X11 forwarding. Trusted X11 forwardings are not | ||
439 | subjected to the X11 SECURITY extension controls. | ||
440 | |||
441 | -y Send log information using the syslog(3) system module. By | ||
442 | default this information is sent to stderr. | ||
443 | |||
444 | ssh may additionally obtain configuration data from a per-user | ||
445 | configuration file and a system-wide configuration file. The file format | ||
446 | and configuration options are described in ssh_config(5). | ||
447 | |||
448 | AUTHENTICATION | ||
449 | The OpenSSH SSH client supports SSH protocol 2. | ||
450 | |||
451 | The methods available for authentication are: GSSAPI-based | ||
452 | authentication, host-based authentication, public key authentication, | ||
453 | challenge-response authentication, and password authentication. | ||
454 | Authentication methods are tried in the order specified above, though | ||
455 | PreferredAuthentications can be used to change the default order. | ||
456 | |||
457 | Host-based authentication works as follows: If the machine the user logs | ||
458 | in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote | ||
459 | machine, and the user names are the same on both sides, or if the files | ||
460 | ~/.rhosts or ~/.shosts exist in the user's home directory on the remote | ||
461 | machine and contain a line containing the name of the client machine and | ||
462 | the name of the user on that machine, the user is considered for login. | ||
463 | Additionally, the server must be able to verify the client's host key | ||
464 | (see the description of /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts, | ||
465 | below) for login to be permitted. This authentication method closes | ||
466 | security holes due to IP spoofing, DNS spoofing, and routing spoofing. | ||
467 | [Note to the administrator: /etc/hosts.equiv, ~/.rhosts, and the | ||
468 | rlogin/rsh protocol in general, are inherently insecure and should be | ||
469 | disabled if security is desired.] | ||
470 | |||
471 | Public key authentication works as follows: The scheme is based on | ||
472 | public-key cryptography, using cryptosystems where encryption and | ||
473 | decryption are done using separate keys, and it is unfeasible to derive | ||
474 | the decryption key from the encryption key. The idea is that each user | ||
475 | creates a public/private key pair for authentication purposes. The | ||
476 | server knows the public key, and only the user knows the private key. | ||
477 | ssh implements public key authentication protocol automatically, using | ||
478 | one of the DSA, ECDSA, Ed25519 or RSA algorithms. The HISTORY section of | ||
479 | ssl(8) contains a brief discussion of the DSA and RSA algorithms. | ||
480 | |||
481 | The file ~/.ssh/authorized_keys lists the public keys that are permitted | ||
482 | for logging in. When the user logs in, the ssh program tells the server | ||
483 | which key pair it would like to use for authentication. The client | ||
484 | proves that it has access to the private key and the server checks that | ||
485 | the corresponding public key is authorized to accept the account. | ||
486 | |||
487 | The server may inform the client of errors that prevented public key | ||
488 | authentication from succeeding after authentication completes using a | ||
489 | different method. These may be viewed by increasing the LogLevel to | ||
490 | DEBUG or higher (e.g. by using the -v flag). | ||
491 | |||
492 | The user creates his/her key pair by running ssh-keygen(1). This stores | ||
493 | the private key in ~/.ssh/id_dsa (DSA), ~/.ssh/id_ecdsa (ECDSA), | ||
494 | ~/.ssh/id_ed25519 (Ed25519), or ~/.ssh/id_rsa (RSA) and stores the public | ||
495 | key in ~/.ssh/id_dsa.pub (DSA), ~/.ssh/id_ecdsa.pub (ECDSA), | ||
496 | ~/.ssh/id_ed25519.pub (Ed25519), or ~/.ssh/id_rsa.pub (RSA) in the user's | ||
497 | home directory. The user should then copy the public key to | ||
498 | ~/.ssh/authorized_keys in his/her home directory on the remote machine. | ||
499 | The authorized_keys file corresponds to the conventional ~/.rhosts file, | ||
500 | and has one key per line, though the lines can be very long. After this, | ||
501 | the user can log in without giving the password. | ||
502 | |||
503 | A variation on public key authentication is available in the form of | ||
504 | certificate authentication: instead of a set of public/private keys, | ||
505 | signed certificates are used. This has the advantage that a single | ||
506 | trusted certification authority can be used in place of many | ||
507 | public/private keys. See the CERTIFICATES section of ssh-keygen(1) for | ||
508 | more information. | ||
509 | |||
510 | The most convenient way to use public key or certificate authentication | ||
511 | may be with an authentication agent. See ssh-agent(1) and (optionally) | ||
512 | the AddKeysToAgent directive in ssh_config(5) for more information. | ||
513 | |||
514 | Challenge-response authentication works as follows: The server sends an | ||
515 | arbitrary "challenge" text, and prompts for a response. Examples of | ||
516 | challenge-response authentication include BSD Authentication (see | ||
517 | login.conf(5)) and PAM (some non-OpenBSD systems). | ||
518 | |||
519 | Finally, if other authentication methods fail, ssh prompts the user for a | ||
520 | password. The password is sent to the remote host for checking; however, | ||
521 | since all communications are encrypted, the password cannot be seen by | ||
522 | someone listening on the network. | ||
523 | |||
524 | ssh automatically maintains and checks a database containing | ||
525 | identification for all hosts it has ever been used with. Host keys are | ||
526 | stored in ~/.ssh/known_hosts in the user's home directory. Additionally, | ||
527 | the file /etc/ssh/ssh_known_hosts is automatically checked for known | ||
528 | hosts. Any new hosts are automatically added to the user's file. If a | ||
529 | host's identification ever changes, ssh warns about this and disables | ||
530 | password authentication to prevent server spoofing or man-in-the-middle | ||
531 | attacks, which could otherwise be used to circumvent the encryption. The | ||
532 | StrictHostKeyChecking option can be used to control logins to machines | ||
533 | whose host key is not known or has changed. | ||
534 | |||
535 | When the user's identity has been accepted by the server, the server | ||
536 | either executes the given command in a non-interactive session or, if no | ||
537 | command has been specified, logs into the machine and gives the user a | ||
538 | normal shell as an interactive session. All communication with the | ||
539 | remote command or shell will be automatically encrypted. | ||
540 | |||
541 | If an interactive session is requested ssh by default will only request a | ||
542 | pseudo-terminal (pty) for interactive sessions when the client has one. | ||
543 | The flags -T and -t can be used to override this behaviour. | ||
544 | |||
545 | If a pseudo-terminal has been allocated the user may use the escape | ||
546 | characters noted below. | ||
547 | |||
548 | If no pseudo-terminal has been allocated, the session is transparent and | ||
549 | can be used to reliably transfer binary data. On most systems, setting | ||
550 | the escape character to M-bM-^@M-^\noneM-bM-^@M-^] will also make the session transparent | ||
551 | even if a tty is used. | ||
552 | |||
553 | The session terminates when the command or shell on the remote machine | ||
554 | exits and all X11 and TCP connections have been closed. | ||
555 | |||
556 | ESCAPE CHARACTERS | ||
557 | When a pseudo-terminal has been requested, ssh supports a number of | ||
558 | functions through the use of an escape character. | ||
559 | |||
560 | A single tilde character can be sent as ~~ or by following the tilde by a | ||
561 | character other than those described below. The escape character must | ||
562 | always follow a newline to be interpreted as special. The escape | ||
563 | character can be changed in configuration files using the EscapeChar | ||
564 | configuration directive or on the command line by the -e option. | ||
565 | |||
566 | The supported escapes (assuming the default M-bM-^@M-^X~M-bM-^@M-^Y) are: | ||
567 | |||
568 | ~. Disconnect. | ||
569 | |||
570 | ~^Z Background ssh. | ||
571 | |||
572 | ~# List forwarded connections. | ||
573 | |||
574 | ~& Background ssh at logout when waiting for forwarded connection / | ||
575 | X11 sessions to terminate. | ||
576 | |||
577 | ~? Display a list of escape characters. | ||
578 | |||
579 | ~B Send a BREAK to the remote system (only useful if the peer | ||
580 | supports it). | ||
581 | |||
582 | ~C Open command line. Currently this allows the addition of port | ||
583 | forwardings using the -L, -R and -D options (see above). It also | ||
584 | allows the cancellation of existing port-forwardings with | ||
585 | -KL[bind_address:]port for local, -KR[bind_address:]port for | ||
586 | remote and -KD[bind_address:]port for dynamic port-forwardings. | ||
587 | !command allows the user to execute a local command if the | ||
588 | PermitLocalCommand option is enabled in ssh_config(5). Basic | ||
589 | help is available, using the -h option. | ||
590 | |||
591 | ~R Request rekeying of the connection (only useful if the peer | ||
592 | supports it). | ||
593 | |||
594 | ~V Decrease the verbosity (LogLevel) when errors are being written | ||
595 | to stderr. | ||
596 | |||
597 | ~v Increase the verbosity (LogLevel) when errors are being written | ||
598 | to stderr. | ||
599 | |||
600 | TCP FORWARDING | ||
601 | Forwarding of arbitrary TCP connections over a secure channel can be | ||
602 | specified either on the command line or in a configuration file. One | ||
603 | possible application of TCP forwarding is a secure connection to a mail | ||
604 | server; another is going through firewalls. | ||
605 | |||
606 | In the example below, we look at encrypting communication for an IRC | ||
607 | client, even though the IRC server it connects to does not directly | ||
608 | support encrypted communication. This works as follows: the user | ||
609 | connects to the remote host using ssh, specifying the ports to be used to | ||
610 | forward the connection. After that it is possible to start the program | ||
611 | locally, and ssh will encrypt and forward the connection to the remote | ||
612 | server. | ||
613 | |||
614 | The following example tunnels an IRC session from the client to an IRC | ||
615 | server at M-bM-^@M-^\server.example.comM-bM-^@M-^], joining channel M-bM-^@M-^\#usersM-bM-^@M-^], nickname | ||
616 | M-bM-^@M-^\pinkyM-bM-^@M-^], using the standard IRC port, 6667: | ||
617 | |||
618 | $ ssh -f -L 6667:localhost:6667 server.example.com sleep 10 | ||
619 | $ irc -c '#users' pinky IRC/127.0.0.1 | ||
620 | |||
621 | The -f option backgrounds ssh and the remote command M-bM-^@M-^\sleep 10M-bM-^@M-^] is | ||
622 | specified to allow an amount of time (10 seconds, in the example) to | ||
623 | start the program which is going to use the tunnel. If no connections | ||
624 | are made within the time specified, ssh will exit. | ||
625 | |||
626 | X11 FORWARDING | ||
627 | If the ForwardX11 variable is set to M-bM-^@M-^\yesM-bM-^@M-^] (or see the description of the | ||
628 | -X, -x, and -Y options above) and the user is using X11 (the DISPLAY | ||
629 | environment variable is set), the connection to the X11 display is | ||
630 | automatically forwarded to the remote side in such a way that any X11 | ||
631 | programs started from the shell (or command) will go through the | ||
632 | encrypted channel, and the connection to the real X server will be made | ||
633 | from the local machine. The user should not manually set DISPLAY. | ||
634 | Forwarding of X11 connections can be configured on the command line or in | ||
635 | configuration files. | ||
636 | |||
637 | The DISPLAY value set by ssh will point to the server machine, but with a | ||
638 | display number greater than zero. This is normal, and happens because | ||
639 | ssh creates a M-bM-^@M-^\proxyM-bM-^@M-^] X server on the server machine for forwarding the | ||
640 | connections over the encrypted channel. | ||
641 | |||
642 | ssh will also automatically set up Xauthority data on the server machine. | ||
643 | For this purpose, it will generate a random authorization cookie, store | ||
644 | it in Xauthority on the server, and verify that any forwarded connections | ||
645 | carry this cookie and replace it by the real cookie when the connection | ||
646 | is opened. The real authentication cookie is never sent to the server | ||
647 | machine (and no cookies are sent in the plain). | ||
648 | |||
649 | If the ForwardAgent variable is set to M-bM-^@M-^\yesM-bM-^@M-^] (or see the description of | ||
650 | the -A and -a options above) and the user is using an authentication | ||
651 | agent, the connection to the agent is automatically forwarded to the | ||
652 | remote side. | ||
653 | |||
654 | VERIFYING HOST KEYS | ||
655 | When connecting to a server for the first time, a fingerprint of the | ||
656 | server's public key is presented to the user (unless the option | ||
657 | StrictHostKeyChecking has been disabled). Fingerprints can be determined | ||
658 | using ssh-keygen(1): | ||
659 | |||
660 | $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key | ||
661 | |||
662 | If the fingerprint is already known, it can be matched and the key can be | ||
663 | accepted or rejected. If only legacy (MD5) fingerprints for the server | ||
664 | are available, the ssh-keygen(1) -E option may be used to downgrade the | ||
665 | fingerprint algorithm to match. | ||
666 | |||
667 | Because of the difficulty of comparing host keys just by looking at | ||
668 | fingerprint strings, there is also support to compare host keys visually, | ||
669 | using random art. By setting the VisualHostKey option to M-bM-^@M-^\yesM-bM-^@M-^], a small | ||
670 | ASCII graphic gets displayed on every login to a server, no matter if the | ||
671 | session itself is interactive or not. By learning the pattern a known | ||
672 | server produces, a user can easily find out that the host key has changed | ||
673 | when a completely different pattern is displayed. Because these patterns | ||
674 | are not unambiguous however, a pattern that looks similar to the pattern | ||
675 | remembered only gives a good probability that the host key is the same, | ||
676 | not guaranteed proof. | ||
677 | |||
678 | To get a listing of the fingerprints along with their random art for all | ||
679 | known hosts, the following command line can be used: | ||
680 | |||
681 | $ ssh-keygen -lv -f ~/.ssh/known_hosts | ||
682 | |||
683 | If the fingerprint is unknown, an alternative method of verification is | ||
684 | available: SSH fingerprints verified by DNS. An additional resource | ||
685 | record (RR), SSHFP, is added to a zonefile and the connecting client is | ||
686 | able to match the fingerprint with that of the key presented. | ||
687 | |||
688 | In this example, we are connecting a client to a server, | ||
689 | M-bM-^@M-^\host.example.comM-bM-^@M-^]. The SSHFP resource records should first be added to | ||
690 | the zonefile for host.example.com: | ||
691 | |||
692 | $ ssh-keygen -r host.example.com. | ||
693 | |||
694 | The output lines will have to be added to the zonefile. To check that | ||
695 | the zone is answering fingerprint queries: | ||
696 | |||
697 | $ dig -t SSHFP host.example.com | ||
698 | |||
699 | Finally the client connects: | ||
700 | |||
701 | $ ssh -o "VerifyHostKeyDNS ask" host.example.com | ||
702 | [...] | ||
703 | Matching host key fingerprint found in DNS. | ||
704 | Are you sure you want to continue connecting (yes/no)? | ||
705 | |||
706 | See the VerifyHostKeyDNS option in ssh_config(5) for more information. | ||
707 | |||
708 | SSH-BASED VIRTUAL PRIVATE NETWORKS | ||
709 | ssh contains support for Virtual Private Network (VPN) tunnelling using | ||
710 | the tun(4) network pseudo-device, allowing two networks to be joined | ||
711 | securely. The sshd_config(5) configuration option PermitTunnel controls | ||
712 | whether the server supports this, and at what level (layer 2 or 3 | ||
713 | traffic). | ||
714 | |||
715 | The following example would connect client network 10.0.50.0/24 with | ||
716 | remote network 10.0.99.0/24 using a point-to-point connection from | ||
717 | 10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway | ||
718 | to the remote network, at 192.168.1.15, allows it. | ||
719 | |||
720 | On the client: | ||
721 | |||
722 | # ssh -f -w 0:1 192.168.1.15 true | ||
723 | # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 | ||
724 | # route add 10.0.99.0/24 10.1.1.2 | ||
725 | |||
726 | On the server: | ||
727 | |||
728 | # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252 | ||
729 | # route add 10.0.50.0/24 10.1.1.1 | ||
730 | |||
731 | Client access may be more finely tuned via the /root/.ssh/authorized_keys | ||
732 | file (see below) and the PermitRootLogin server option. The following | ||
733 | entry would permit connections on tun(4) device 1 from user M-bM-^@M-^\janeM-bM-^@M-^] and on | ||
734 | tun device 2 from user M-bM-^@M-^\johnM-bM-^@M-^], if PermitRootLogin is set to | ||
735 | M-bM-^@M-^\forced-commands-onlyM-bM-^@M-^]: | ||
736 | |||
737 | tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane | ||
738 | tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john | ||
739 | |||
740 | Since an SSH-based setup entails a fair amount of overhead, it may be | ||
741 | more suited to temporary setups, such as for wireless VPNs. More | ||
742 | permanent VPNs are better provided by tools such as ipsecctl(8) and | ||
743 | isakmpd(8). | ||
744 | |||
745 | ENVIRONMENT | ||
746 | ssh will normally set the following environment variables: | ||
747 | |||
748 | DISPLAY The DISPLAY variable indicates the location of the | ||
749 | X11 server. It is automatically set by ssh to | ||
750 | point to a value of the form M-bM-^@M-^\hostname:nM-bM-^@M-^], where | ||
751 | M-bM-^@M-^\hostnameM-bM-^@M-^] indicates the host where the shell runs, | ||
752 | and M-bM-^@M-^XnM-bM-^@M-^Y is an integer M-bM-^IM-% 1. ssh uses this special | ||
753 | value to forward X11 connections over the secure | ||
754 | channel. The user should normally not set DISPLAY | ||
755 | explicitly, as that will render the X11 connection | ||
756 | insecure (and will require the user to manually | ||
757 | copy any required authorization cookies). | ||
758 | |||
759 | HOME Set to the path of the user's home directory. | ||
760 | |||
761 | LOGNAME Synonym for USER; set for compatibility with | ||
762 | systems that use this variable. | ||
763 | |||
764 | MAIL Set to the path of the user's mailbox. | ||
765 | |||
766 | PATH Set to the default PATH, as specified when | ||
767 | compiling ssh. | ||
768 | |||
769 | SSH_ASKPASS If ssh needs a passphrase, it will read the | ||
770 | passphrase from the current terminal if it was run | ||
771 | from a terminal. If ssh does not have a terminal | ||
772 | associated with it but DISPLAY and SSH_ASKPASS are | ||
773 | set, it will execute the program specified by | ||
774 | SSH_ASKPASS and open an X11 window to read the | ||
775 | passphrase. This is particularly useful when | ||
776 | calling ssh from a .xsession or related script. | ||
777 | (Note that on some machines it may be necessary to | ||
778 | redirect the input from /dev/null to make this | ||
779 | work.) | ||
780 | |||
781 | SSH_AUTH_SOCK Identifies the path of a UNIX-domain socket used to | ||
782 | communicate with the agent. | ||
783 | |||
784 | SSH_CONNECTION Identifies the client and server ends of the | ||
785 | connection. The variable contains four space- | ||
786 | separated values: client IP address, client port | ||
787 | number, server IP address, and server port number. | ||
788 | |||
789 | SSH_ORIGINAL_COMMAND This variable contains the original command line if | ||
790 | a forced command is executed. It can be used to | ||
791 | extract the original arguments. | ||
792 | |||
793 | SSH_TTY This is set to the name of the tty (path to the | ||
794 | device) associated with the current shell or | ||
795 | command. If the current session has no tty, this | ||
796 | variable is not set. | ||
797 | |||
798 | SSH_TUNNEL Optionally set by sshd(8) to contain the interface | ||
799 | names assigned if tunnel forwarding was requested | ||
800 | by the client. | ||
801 | |||
802 | SSH_USER_AUTH Optionally set by sshd(8), this variable may | ||
803 | contain a pathname to a file that lists the | ||
804 | authentication methods successfully used when the | ||
805 | session was established, including any public keys | ||
806 | that were used. | ||
807 | |||
808 | TZ This variable is set to indicate the present time | ||
809 | zone if it was set when the daemon was started | ||
810 | (i.e. the daemon passes the value on to new | ||
811 | connections). | ||
812 | |||
813 | USER Set to the name of the user logging in. | ||
814 | |||
815 | Additionally, ssh reads ~/.ssh/environment, and adds lines of the format | ||
816 | M-bM-^@M-^\VARNAME=valueM-bM-^@M-^] to the environment if the file exists and users are | ||
817 | allowed to change their environment. For more information, see the | ||
818 | PermitUserEnvironment option in sshd_config(5). | ||
819 | |||
820 | FILES | ||
821 | ~/.rhosts | ||
822 | This file is used for host-based authentication (see above). On | ||
823 | some machines this file may need to be world-readable if the | ||
824 | user's home directory is on an NFS partition, because sshd(8) | ||
825 | reads it as root. Additionally, this file must be owned by the | ||
826 | user, and must not have write permissions for anyone else. The | ||
827 | recommended permission for most machines is read/write for the | ||
828 | user, and not accessible by others. | ||
829 | |||
830 | ~/.shosts | ||
831 | This file is used in exactly the same way as .rhosts, but allows | ||
832 | host-based authentication without permitting login with | ||
833 | rlogin/rsh. | ||
834 | |||
835 | ~/.ssh/ | ||
836 | This directory is the default location for all user-specific | ||
837 | configuration and authentication information. There is no | ||
838 | general requirement to keep the entire contents of this directory | ||
839 | secret, but the recommended permissions are read/write/execute | ||
840 | for the user, and not accessible by others. | ||
841 | |||
842 | ~/.ssh/authorized_keys | ||
843 | Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used | ||
844 | for logging in as this user. The format of this file is | ||
845 | described in the sshd(8) manual page. This file is not highly | ||
846 | sensitive, but the recommended permissions are read/write for the | ||
847 | user, and not accessible by others. | ||
848 | |||
849 | ~/.ssh/config | ||
850 | This is the per-user configuration file. The file format and | ||
851 | configuration options are described in ssh_config(5). Because of | ||
852 | the potential for abuse, this file must have strict permissions: | ||
853 | read/write for the user, and not writable by others. | ||
854 | |||
855 | ~/.ssh/environment | ||
856 | Contains additional definitions for environment variables; see | ||
857 | ENVIRONMENT, above. | ||
858 | |||
859 | ~/.ssh/id_dsa | ||
860 | ~/.ssh/id_ecdsa | ||
861 | ~/.ssh/id_ed25519 | ||
862 | ~/.ssh/id_rsa | ||
863 | Contains the private key for authentication. These files contain | ||
864 | sensitive data and should be readable by the user but not | ||
865 | accessible by others (read/write/execute). ssh will simply | ||
866 | ignore a private key file if it is accessible by others. It is | ||
867 | possible to specify a passphrase when generating the key which | ||
868 | will be used to encrypt the sensitive part of this file using | ||
869 | AES-128. | ||
870 | |||
871 | ~/.ssh/id_dsa.pub | ||
872 | ~/.ssh/id_ecdsa.pub | ||
873 | ~/.ssh/id_ed25519.pub | ||
874 | ~/.ssh/id_rsa.pub | ||
875 | Contains the public key for authentication. These files are not | ||
876 | sensitive and can (but need not) be readable by anyone. | ||
877 | |||
878 | ~/.ssh/known_hosts | ||
879 | Contains a list of host keys for all hosts the user has logged | ||
880 | into that are not already in the systemwide list of known host | ||
881 | keys. See sshd(8) for further details of the format of this | ||
882 | file. | ||
883 | |||
884 | ~/.ssh/rc | ||
885 | Commands in this file are executed by ssh when the user logs in, | ||
886 | just before the user's shell (or command) is started. See the | ||
887 | sshd(8) manual page for more information. | ||
888 | |||
889 | /etc/hosts.equiv | ||
890 | This file is for host-based authentication (see above). It | ||
891 | should only be writable by root. | ||
892 | |||
893 | /etc/shosts.equiv | ||
894 | This file is used in exactly the same way as hosts.equiv, but | ||
895 | allows host-based authentication without permitting login with | ||
896 | rlogin/rsh. | ||
897 | |||
898 | /etc/ssh/ssh_config | ||
899 | Systemwide configuration file. The file format and configuration | ||
900 | options are described in ssh_config(5). | ||
901 | |||
902 | /etc/ssh/ssh_host_key | ||
903 | /etc/ssh/ssh_host_dsa_key | ||
904 | /etc/ssh/ssh_host_ecdsa_key | ||
905 | /etc/ssh/ssh_host_ed25519_key | ||
906 | /etc/ssh/ssh_host_rsa_key | ||
907 | These files contain the private parts of the host keys and are | ||
908 | used for host-based authentication. | ||
909 | |||
910 | /etc/ssh/ssh_known_hosts | ||
911 | Systemwide list of known host keys. This file should be prepared | ||
912 | by the system administrator to contain the public host keys of | ||
913 | all machines in the organization. It should be world-readable. | ||
914 | See sshd(8) for further details of the format of this file. | ||
915 | |||
916 | /etc/ssh/sshrc | ||
917 | Commands in this file are executed by ssh when the user logs in, | ||
918 | just before the user's shell (or command) is started. See the | ||
919 | sshd(8) manual page for more information. | ||
920 | |||
921 | EXIT STATUS | ||
922 | ssh exits with the exit status of the remote command or with 255 if an | ||
923 | error occurred. | ||
924 | |||
925 | SEE ALSO | ||
926 | scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), | ||
927 | tun(4), ssh_config(5), ssh-keysign(8), sshd(8) | ||
928 | |||
929 | STANDARDS | ||
930 | S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned | ||
931 | Numbers, RFC 4250, January 2006. | ||
932 | |||
933 | T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, | ||
934 | RFC 4251, January 2006. | ||
935 | |||
936 | T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, | ||
937 | RFC 4252, January 2006. | ||
938 | |||
939 | T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer | ||
940 | Protocol, RFC 4253, January 2006. | ||
941 | |||
942 | T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC | ||
943 | 4254, January 2006. | ||
944 | |||
945 | J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell | ||
946 | (SSH) Key Fingerprints, RFC 4255, January 2006. | ||
947 | |||
948 | F. Cusack and M. Forssen, Generic Message Exchange Authentication for the | ||
949 | Secure Shell Protocol (SSH), RFC 4256, January 2006. | ||
950 | |||
951 | J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break | ||
952 | Extension, RFC 4335, January 2006. | ||
953 | |||
954 | M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport | ||
955 | Layer Encryption Modes, RFC 4344, January 2006. | ||
956 | |||
957 | B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport | ||
958 | Layer Protocol, RFC 4345, January 2006. | ||
959 | |||
960 | M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for | ||
961 | the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, March 2006. | ||
962 | |||
963 | J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File | ||
964 | Format, RFC 4716, November 2006. | ||
965 | |||
966 | D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the | ||
967 | Secure Shell Transport Layer, RFC 5656, December 2009. | ||
968 | |||
969 | A. Perrig and D. Song, Hash Visualization: a New Technique to improve | ||
970 | Real-World Security, 1999, International Workshop on Cryptographic | ||
971 | Techniques and E-Commerce (CrypTEC '99). | ||
972 | |||
973 | AUTHORS | ||
974 | OpenSSH is a derivative of the original and free ssh 1.2.12 release by | ||
975 | Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo | ||
976 | de Raadt and Dug Song removed many bugs, re-added newer features and | ||
977 | created OpenSSH. Markus Friedl contributed the support for SSH protocol | ||
978 | versions 1.5 and 2.0. | ||
979 | |||
980 | OpenBSD 6.6 June 12, 2019 OpenBSD 6.6 | ||