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