diff options
author | Colin Watson <cjwatson@debian.org> | 2003-09-17 00:32:19 +0000 |
---|---|---|
committer | Colin Watson <cjwatson@debian.org> | 2003-09-17 00:32:19 +0000 |
commit | 22f9b945efa61bba12a4778b889df07cf851838a (patch) | |
tree | 77a3f749ea589c590db930cff12d804a4d7893b5 /ssh.0 | |
parent | 9d1471514608023cda6456f5a2e875cc5e4b9e77 (diff) | |
parent | 854156dd39acbde9b4a47ec0fc54a042ea7358e0 (diff) |
Import OpenSSH 3.7p1.
Diffstat (limited to 'ssh.0')
-rw-r--r-- | ssh.0 | 613 |
1 files changed, 613 insertions, 0 deletions
@@ -0,0 +1,613 @@ | |||
1 | SSH(1) BSD General Commands Manual SSH(1) | ||
2 | |||
3 | NAME | ||
4 | ssh - OpenSSH SSH client (remote login program) | ||
5 | |||
6 | SYNOPSIS | ||
7 | ssh [-l login_name] hostname | user@hostname [command] | ||
8 | |||
9 | ssh [-afgknqstvxACNTVX1246] [-b bind_address] [-c cipher_spec] | ||
10 | [-e escape_char] [-i identity_file] [-l login_name] [-m mac_spec] | ||
11 | [-o option] [-p port] [-F configfile] [-L port:host:hostport] | ||
12 | [-R port:host:hostport] [-D port] hostname | 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 | ||
18 | untrusted hosts over an insecure network. X11 connections and arbitrary | ||
19 | TCP/IP ports can also be forwarded over the secure channel. | ||
20 | |||
21 | ssh connects and logs into the specified hostname. The user must prove | ||
22 | his/her identity to the remote machine using one of several methods | ||
23 | depending on the protocol version used: | ||
24 | |||
25 | SSH protocol version 1 | ||
26 | First, if the machine the user logs in from is listed in /etc/hosts.equiv | ||
27 | or /etc/shosts.equiv on the remote machine, and the user names are the | ||
28 | same on both sides, the user is immediately permitted to log in. Second, | ||
29 | if .rhosts or .shosts exists in the userM-bM-^@M-^Ys home directory on the remote | ||
30 | machine and contains a line containing the name of the client machine and | ||
31 | the name of the user on that machine, the user is permitted to log in. | ||
32 | This form of authentication alone is normally not allowed by the server | ||
33 | because it is not secure. | ||
34 | |||
35 | The second authentication method is the rhosts or hosts.equiv method com- | ||
36 | bined with RSA-based host authentication. It means that if the login | ||
37 | would be permitted by $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, or | ||
38 | /etc/shosts.equiv, and if additionally the server can verify the clientM-bM-^@M-^Ys | ||
39 | host key (see /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts in the | ||
40 | FILES section), only then login is permitted. This authentication method | ||
41 | closes security holes due to IP spoofing, DNS spoofing and routing spoof- | ||
42 | ing. [Note to the administrator: /etc/hosts.equiv, $HOME/.rhosts, and | ||
43 | the rlogin/rsh protocol in general, are inherently insecure and should be | ||
44 | disabled if security is desired.] | ||
45 | |||
46 | As a third authentication method, ssh supports RSA based authentication. | ||
47 | The scheme is based on public-key cryptography: there are cryptosystems | ||
48 | where encryption and decryption are done using separate keys, and it is | ||
49 | not possible to derive the decryption key from the encryption key. RSA | ||
50 | is one such system. The idea is that each user creates a public/private | ||
51 | key pair for authentication purposes. The server knows the public key, | ||
52 | and only the user knows the private key. The file | ||
53 | $HOME/.ssh/authorized_keys lists the public keys that are permitted for | ||
54 | logging in. When the user logs in, the ssh program tells the server | ||
55 | which key pair it would like to use for authentication. The server | ||
56 | checks if this key is permitted, and if so, sends the user (actually the | ||
57 | ssh program running on behalf of the user) a challenge, a random number, | ||
58 | encrypted by the userM-bM-^@M-^Ys public key. The challenge can only be decrypted | ||
59 | using the proper private key. The userM-bM-^@M-^Ys client then decrypts the chal- | ||
60 | lenge using the private key, proving that he/she knows the private key | ||
61 | but without disclosing it to the server. | ||
62 | |||
63 | ssh implements the RSA authentication protocol automatically. The user | ||
64 | creates his/her RSA key pair by running ssh-keygen(1). This stores the | ||
65 | private key in $HOME/.ssh/identity and the public key in | ||
66 | $HOME/.ssh/identity.pub in the userM-bM-^@M-^Ys home directory. The user should | ||
67 | then copy the identity.pub to $HOME/.ssh/authorized_keys in his/her home | ||
68 | directory on the remote machine (the authorized_keys file corresponds to | ||
69 | the conventional $HOME/.rhosts file, and has one key per line, though the | ||
70 | lines can be very long). After this, the user can log in without giving | ||
71 | the password. RSA authentication is much more secure than rhosts authen- | ||
72 | tication. | ||
73 | |||
74 | The most convenient way to use RSA authentication may be with an authen- | ||
75 | tication agent. See ssh-agent(1) for more information. | ||
76 | |||
77 | If other authentication methods fail, ssh prompts the user for a pass- | ||
78 | word. The password is sent to the remote host for checking; however, | ||
79 | since all communications are encrypted, the password cannot be seen by | ||
80 | someone listening on the network. | ||
81 | |||
82 | SSH protocol version 2 | ||
83 | When a user connects using protocol version 2 similar authentication | ||
84 | methods are available. Using the default values for | ||
85 | PreferredAuthentications, the client will try to authenticate first using | ||
86 | the hostbased method; if this method fails public key authentication is | ||
87 | attempted, and finally if this method fails keyboard-interactive and | ||
88 | password authentication are tried. | ||
89 | |||
90 | The public key method is similar to RSA authentication described in the | ||
91 | previous section and allows the RSA or DSA algorithm to be used: The | ||
92 | client uses his private key, $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa, to | ||
93 | sign the session identifier and sends the result to the server. The | ||
94 | server checks whether the matching public key is listed in | ||
95 | $HOME/.ssh/authorized_keys and grants access if both the key is found and | ||
96 | the signature is correct. The session identifier is derived from a | ||
97 | shared Diffie-Hellman value and is only known to the client and the | ||
98 | server. | ||
99 | |||
100 | If public key authentication fails or is not available a password can be | ||
101 | sent encrypted to the remote host for proving the userM-bM-^@M-^Ys identity. | ||
102 | |||
103 | Additionally, ssh supports hostbased or challenge response authentica- | ||
104 | tion. | ||
105 | |||
106 | Protocol 2 provides additional mechanisms for confidentiality (the traf- | ||
107 | fic is encrypted using 3DES, Blowfish, CAST128 or Arcfour) and integrity | ||
108 | (hmac-md5, hmac-sha1). Note that protocol 1 lacks a strong mechanism for | ||
109 | ensuring the integrity of the connection. | ||
110 | |||
111 | Login session and remote execution | ||
112 | When the userM-bM-^@M-^Ys identity has been accepted by the server, the server | ||
113 | either executes the given command, or logs into the machine and gives the | ||
114 | user a normal shell on the remote machine. All communication with the | ||
115 | remote command or shell will be automatically encrypted. | ||
116 | |||
117 | If a pseudo-terminal has been allocated (normal login session), the user | ||
118 | may use the escape characters noted below. | ||
119 | |||
120 | If no pseudo tty has been allocated, the session is transparent and can | ||
121 | be used to reliably transfer binary data. On most systems, setting the | ||
122 | escape character to M-bM-^@M-^\noneM-bM-^@M-^] will also make the session transparent even if | ||
123 | a tty is used. | ||
124 | |||
125 | The session terminates when the command or shell on the remote machine | ||
126 | exits and all X11 and TCP/IP connections have been closed. The exit sta- | ||
127 | tus of the remote program is returned as the exit status of ssh. | ||
128 | |||
129 | Escape Characters | ||
130 | When a pseudo terminal has been requested, ssh supports a number of func- | ||
131 | tions through the use of an escape character. | ||
132 | |||
133 | A single tilde character can be sent as ~~ or by following the tilde by a | ||
134 | character other than those described below. The escape character must | ||
135 | always follow a newline to be interpreted as special. The escape charac- | ||
136 | ter can be changed in configuration files using the EscapeChar configura- | ||
137 | tion directive or on the command line by the -e option. | ||
138 | |||
139 | The supported escapes (assuming the default M-bM-^@M-^X~M-bM-^@M-^Y) are: | ||
140 | |||
141 | ~. Disconnect | ||
142 | |||
143 | ~^Z Background ssh | ||
144 | |||
145 | ~# List forwarded connections | ||
146 | |||
147 | ~& Background ssh at logout when waiting for forwarded connection / | ||
148 | X11 sessions to terminate | ||
149 | |||
150 | ~? Display a list of escape characters | ||
151 | |||
152 | ~B Send a BREAK to the remote system (only useful for SSH protocol | ||
153 | version 2 and if the peer supports it) | ||
154 | |||
155 | ~C Open command line (only useful for adding port forwardings using | ||
156 | the -L and -R options) | ||
157 | |||
158 | ~R Request rekeying of the connection (only useful for SSH protocol | ||
159 | version 2 and if the peer supports it) | ||
160 | |||
161 | X11 and TCP forwarding | ||
162 | If the ForwardX11 variable is set to M-bM-^@M-^\yesM-bM-^@M-^] (or, see the description of | ||
163 | the -X and -x options described later) and the user is using X11 (the | ||
164 | DISPLAY environment variable is set), the connection to the X11 display | ||
165 | is automatically forwarded to the remote side in such a way that any X11 | ||
166 | programs started from the shell (or command) will go through the | ||
167 | encrypted channel, and the connection to the real X server will be made | ||
168 | from the local machine. The user should not manually set DISPLAY. For- | ||
169 | warding of X11 connections can be configured on the command line or in | ||
170 | configuration files. | ||
171 | |||
172 | The DISPLAY value set by ssh will point to the server machine, but with a | ||
173 | display number greater than zero. This is normal, and happens because | ||
174 | ssh creates a M-bM-^@M-^\proxyM-bM-^@M-^] X server on the server machine for forwarding the | ||
175 | connections over the encrypted channel. | ||
176 | |||
177 | ssh will also automatically set up Xauthority data on the server machine. | ||
178 | For this purpose, it will generate a random authorization cookie, store | ||
179 | it in Xauthority on the server, and verify that any forwarded connections | ||
180 | carry this cookie and replace it by the real cookie when the connection | ||
181 | is opened. The real authentication cookie is never sent to the server | ||
182 | machine (and no cookies are sent in the plain). | ||
183 | |||
184 | If the ForwardAgent variable is set to M-bM-^@M-^\yesM-bM-^@M-^] (or, see the description of | ||
185 | the -A and -a options described later) and the user is using an authenti- | ||
186 | cation agent, the connection to the agent is automatically forwarded to | ||
187 | the remote side. | ||
188 | |||
189 | Forwarding of arbitrary TCP/IP connections over the secure channel can be | ||
190 | specified either on the command line or in a configuration file. One | ||
191 | possible application of TCP/IP forwarding is a secure connection to an | ||
192 | electronic purse; another is going through firewalls. | ||
193 | |||
194 | Server authentication | ||
195 | ssh automatically maintains and checks a database containing identifica- | ||
196 | tions for all hosts it has ever been used with. Host keys are stored in | ||
197 | $HOME/.ssh/known_hosts in the userM-bM-^@M-^Ys home directory. Additionally, the | ||
198 | file /etc/ssh/ssh_known_hosts is automatically checked for known hosts. | ||
199 | Any new hosts are automatically added to the userM-bM-^@M-^Ys file. If a hostM-bM-^@M-^Ys | ||
200 | identification ever changes, ssh warns about this and disables password | ||
201 | authentication to prevent a trojan horse from getting the userM-bM-^@M-^Ys pass- | ||
202 | word. Another purpose of this mechanism is to prevent man-in-the-middle | ||
203 | attacks which could otherwise be used to circumvent the encryption. The | ||
204 | StrictHostKeyChecking option can be used to prevent logins to machines | ||
205 | whose host key is not known or has changed. | ||
206 | |||
207 | The options are as follows: | ||
208 | |||
209 | -a Disables forwarding of the authentication agent connection. | ||
210 | |||
211 | -A Enables forwarding of the authentication agent connection. This | ||
212 | can also be specified on a per-host basis in a configuration | ||
213 | file. | ||
214 | |||
215 | Agent forwarding should be enabled with caution. Users with the | ||
216 | ability to bypass file permissions on the remote host (for the | ||
217 | agentM-bM-^@M-^Ys Unix-domain socket) can access the local agent through | ||
218 | the forwarded connection. An attacker cannot obtain key material | ||
219 | from the agent, however they can perform operations on the keys | ||
220 | that enable them to authenticate using the identities loaded into | ||
221 | the agent. | ||
222 | |||
223 | -b bind_address | ||
224 | Specify the interface to transmit from on machines with multiple | ||
225 | interfaces or aliased addresses. | ||
226 | |||
227 | -c blowfish|3des|des | ||
228 | Selects the cipher to use for encrypting the session. 3des is | ||
229 | used by default. It is believed to be secure. 3des (triple-des) | ||
230 | is an encrypt-decrypt-encrypt triple with three different keys. | ||
231 | blowfish is a fast block cipher, it appears very secure and is | ||
232 | much faster than 3des. des is only supported in the ssh client | ||
233 | for interoperability with legacy protocol 1 implementations that | ||
234 | do not support the 3des cipher. Its use is strongly discouraged | ||
235 | due to cryptographic weaknesses. | ||
236 | |||
237 | -c cipher_spec | ||
238 | Additionally, for protocol version 2 a comma-separated list of | ||
239 | ciphers can be specified in order of preference. See Ciphers for | ||
240 | more information. | ||
241 | |||
242 | -e ch|^ch|none | ||
243 | Sets the escape character for sessions with a pty (default: M-bM-^@M-^X~M-bM-^@M-^Y). | ||
244 | The escape character is only recognized at the beginning of a | ||
245 | line. The escape character followed by a dot (M-bM-^@M-^X.M-bM-^@M-^Y) closes the | ||
246 | connection, followed by control-Z suspends the connection, and | ||
247 | followed by itself sends the escape character once. Setting the | ||
248 | character to M-bM-^@M-^\noneM-bM-^@M-^] disables any escapes and makes the session | ||
249 | fully transparent. | ||
250 | |||
251 | -f Requests ssh to go to background just before command execution. | ||
252 | This is useful if ssh is going to ask for passwords or | ||
253 | passphrases, but the user wants it in the background. This | ||
254 | implies -n. The recommended way to start X11 programs at a | ||
255 | remote site is with something like ssh -f host xterm. | ||
256 | |||
257 | -g Allows remote hosts to connect to local forwarded ports. | ||
258 | |||
259 | -i identity_file | ||
260 | Selects a file from which the identity (private key) for RSA or | ||
261 | DSA authentication is read. The default is $HOME/.ssh/identity | ||
262 | for protocol version 1, and $HOME/.ssh/id_rsa and | ||
263 | $HOME/.ssh/id_dsa for protocol version 2. Identity files may | ||
264 | also be specified on a per-host basis in the configuration file. | ||
265 | It is possible to have multiple -i options (and multiple identi- | ||
266 | ties specified in configuration files). | ||
267 | |||
268 | -I smartcard_device | ||
269 | Specifies which smartcard device to use. The argument is the | ||
270 | device ssh should use to communicate with a smartcard used for | ||
271 | storing the userM-bM-^@M-^Ys private RSA key. | ||
272 | |||
273 | -k Disables forwarding of Kerberos tickets. This may also be speci- | ||
274 | fied on a per-host basis in the configuration file. | ||
275 | |||
276 | -l login_name | ||
277 | Specifies the user to log in as on the remote machine. This also | ||
278 | may be specified on a per-host basis in the configuration file. | ||
279 | |||
280 | -m mac_spec | ||
281 | Additionally, for protocol version 2 a comma-separated list of | ||
282 | MAC (message authentication code) algorithms can be specified in | ||
283 | order of preference. See the MACs keyword for more information. | ||
284 | |||
285 | -n Redirects stdin from /dev/null (actually, prevents reading from | ||
286 | stdin). This must be used when ssh is run in the background. A | ||
287 | common trick is to use this to run X11 programs on a remote | ||
288 | machine. For example, ssh -n shadows.cs.hut.fi emacs & will | ||
289 | start an emacs on shadows.cs.hut.fi, and the X11 connection will | ||
290 | be automatically forwarded over an encrypted channel. The ssh | ||
291 | program will be put in the background. (This does not work if | ||
292 | ssh needs to ask for a password or passphrase; see also the -f | ||
293 | option.) | ||
294 | |||
295 | -N Do not execute a remote command. This is useful for just for- | ||
296 | warding ports (protocol version 2 only). | ||
297 | |||
298 | -o option | ||
299 | Can be used to give options in the format used in the configura- | ||
300 | tion file. This is useful for specifying options for which there | ||
301 | is no separate command-line flag. | ||
302 | |||
303 | -p port | ||
304 | Port to connect to on the remote host. This can be specified on | ||
305 | a per-host basis in the configuration file. | ||
306 | |||
307 | -q Quiet mode. Causes all warning and diagnostic messages to be | ||
308 | suppressed. | ||
309 | |||
310 | -s May be used to request invocation of a subsystem on the remote | ||
311 | system. Subsystems are a feature of the SSH2 protocol which | ||
312 | facilitate the use of SSH as a secure transport for other appli- | ||
313 | cations (eg. sftp). The subsystem is specified as the remote | ||
314 | command. | ||
315 | |||
316 | -t Force pseudo-tty allocation. This can be used to execute arbi- | ||
317 | trary screen-based programs on a remote machine, which can be | ||
318 | very useful, e.g., when implementing menu services. Multiple -t | ||
319 | options force tty allocation, even if ssh has no local tty. | ||
320 | |||
321 | -T Disable pseudo-tty allocation. | ||
322 | |||
323 | -v Verbose mode. Causes ssh to print debugging messages about its | ||
324 | progress. This is helpful in debugging connection, authentica- | ||
325 | tion, and configuration problems. Multiple -v options increase | ||
326 | the verbosity. The maximum is 3. | ||
327 | |||
328 | -V Display the version number and exit. | ||
329 | |||
330 | -x Disables X11 forwarding. | ||
331 | |||
332 | -X Enables X11 forwarding. This can also be specified on a per-host | ||
333 | basis in a configuration file. | ||
334 | |||
335 | X11 forwarding should be enabled with caution. Users with the | ||
336 | ability to bypass file permissions on the remote host (for the | ||
337 | userM-bM-^@M-^Ys X authorization database) can access the local X11 display | ||
338 | through the forwarded connection. An attacker may then be able | ||
339 | to perform activities such as keystroke monitoring. | ||
340 | |||
341 | -C Requests compression of all data (including stdin, stdout, | ||
342 | stderr, and data for forwarded X11 and TCP/IP connections). The | ||
343 | compression algorithm is the same used by gzip(1), and the | ||
344 | M-bM-^@M-^\levelM-bM-^@M-^] can be controlled by the CompressionLevel option for pro- | ||
345 | tocol version 1. Compression is desirable on modem lines and | ||
346 | other slow connections, but will only slow down things on fast | ||
347 | networks. The default value can be set on a host-by-host basis | ||
348 | in the configuration files; see the Compression option. | ||
349 | |||
350 | -F configfile | ||
351 | Specifies an alternative per-user configuration file. If a con- | ||
352 | figuration file is given on the command line, the system-wide | ||
353 | configuration file (/etc/ssh/ssh_config) will be ignored. The | ||
354 | default for the per-user configuration file is $HOME/.ssh/config. | ||
355 | |||
356 | -L port:host:hostport | ||
357 | Specifies that the given port on the local (client) host is to be | ||
358 | forwarded to the given host and port on the remote side. This | ||
359 | works by allocating a socket to listen to port on the local side, | ||
360 | and whenever a connection is made to this port, the connection is | ||
361 | forwarded over the secure channel, and a connection is made to | ||
362 | host port hostport from the remote machine. Port forwardings can | ||
363 | also be specified in the configuration file. Only root can for- | ||
364 | ward privileged ports. IPv6 addresses can be specified with an | ||
365 | alternative syntax: port/host/hostport | ||
366 | |||
367 | -R port:host:hostport | ||
368 | Specifies that the given port on the remote (server) host is to | ||
369 | be forwarded to the given host and port on the local side. This | ||
370 | works by allocating a socket to listen to port on the remote | ||
371 | side, and whenever a connection is made to this port, the connec- | ||
372 | tion is forwarded over the secure channel, and a connection is | ||
373 | made to host port hostport from the local machine. Port forward- | ||
374 | ings can also be specified in the configuration file. Privileged | ||
375 | ports can be forwarded only when logging in as root on the remote | ||
376 | machine. IPv6 addresses can be specified with an alternative | ||
377 | syntax: port/host/hostport | ||
378 | |||
379 | -D port | ||
380 | Specifies a local M-bM-^@M-^\dynamicM-bM-^@M-^] application-level port forwarding. | ||
381 | This works by allocating a socket to listen to port on the local | ||
382 | side, and whenever a connection is made to this port, the connec- | ||
383 | tion is forwarded over the secure channel, and the application | ||
384 | protocol is then used to determine where to connect to from the | ||
385 | remote machine. Currently the SOCKS4 and SOCKS5 protocols are | ||
386 | supported, and ssh will act as a SOCKS server. Only root can | ||
387 | forward privileged ports. Dynamic port forwardings can also be | ||
388 | specified in the configuration file. | ||
389 | |||
390 | -1 Forces ssh to try protocol version 1 only. | ||
391 | |||
392 | -2 Forces ssh to try protocol version 2 only. | ||
393 | |||
394 | -4 Forces ssh to use IPv4 addresses only. | ||
395 | |||
396 | -6 Forces ssh to use IPv6 addresses only. | ||
397 | |||
398 | CONFIGURATION FILES | ||
399 | ssh may additionally obtain configuration data from a per-user configura- | ||
400 | tion file and a system-wide configuration file. The file format and con- | ||
401 | figuration options are described in ssh_config(5). | ||
402 | |||
403 | ENVIRONMENT | ||
404 | ssh will normally set the following environment variables: | ||
405 | |||
406 | DISPLAY | ||
407 | The DISPLAY variable indicates the location of the X11 server. | ||
408 | It is automatically set by ssh to point to a value of the form | ||
409 | M-bM-^@M-^\hostname:nM-bM-^@M-^] where hostname indicates the host where the shell | ||
410 | runs, and n is an integer >= 1. ssh uses this special value to | ||
411 | forward X11 connections over the secure channel. The user should | ||
412 | normally not set DISPLAY explicitly, as that will render the X11 | ||
413 | connection insecure (and will require the user to manually copy | ||
414 | any required authorization cookies). | ||
415 | |||
416 | HOME Set to the path of the userM-bM-^@M-^Ys home directory. | ||
417 | |||
418 | LOGNAME | ||
419 | Synonym for USER; set for compatibility with systems that use | ||
420 | this variable. | ||
421 | |||
422 | MAIL Set to the path of the userM-bM-^@M-^Ys mailbox. | ||
423 | |||
424 | PATH Set to the default PATH, as specified when compiling ssh. | ||
425 | |||
426 | SSH_ASKPASS | ||
427 | If ssh needs a passphrase, it will read the passphrase from the | ||
428 | current terminal if it was run from a terminal. If ssh does not | ||
429 | have a terminal associated with it but DISPLAY and SSH_ASKPASS | ||
430 | are set, it will execute the program specified by SSH_ASKPASS and | ||
431 | open an X11 window to read the passphrase. This is particularly | ||
432 | useful when calling ssh from a .Xsession or related script. | ||
433 | (Note that on some machines it may be necessary to redirect the | ||
434 | input from /dev/null to make this work.) | ||
435 | |||
436 | SSH_AUTH_SOCK | ||
437 | Identifies the path of a unix-domain socket used to communicate | ||
438 | with the agent. | ||
439 | |||
440 | SSH_CONNECTION | ||
441 | Identifies the client and server ends of the connection. The | ||
442 | variable contains four space-separated values: client ip-address, | ||
443 | client port number, server ip-address and server port number. | ||
444 | |||
445 | SSH_ORIGINAL_COMMAND | ||
446 | The variable contains the original command line if a forced com- | ||
447 | mand is executed. It can be used to extract the original argu- | ||
448 | ments. | ||
449 | |||
450 | SSH_TTY | ||
451 | This is set to the name of the tty (path to the device) associ- | ||
452 | ated with the current shell or command. If the current session | ||
453 | has no tty, this variable is not set. | ||
454 | |||
455 | TZ The timezone variable is set to indicate the present timezone if | ||
456 | it was set when the daemon was started (i.e., the daemon passes | ||
457 | the value on to new connections). | ||
458 | |||
459 | USER Set to the name of the user logging in. | ||
460 | |||
461 | Additionally, ssh reads $HOME/.ssh/environment, and adds lines of the | ||
462 | format M-bM-^@M-^\VARNAME=valueM-bM-^@M-^] to the environment if the file exists and if users | ||
463 | are allowed to change their environment. See the PermitUserEnvironment | ||
464 | option in sshd_config(5). | ||
465 | |||
466 | FILES | ||
467 | $HOME/.ssh/known_hosts | ||
468 | Records host keys for all hosts the user has logged into that are | ||
469 | not in /etc/ssh/ssh_known_hosts. See sshd(8). | ||
470 | |||
471 | $HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa | ||
472 | Contains the authentication identity of the user. They are for | ||
473 | protocol 1 RSA, protocol 2 DSA, and protocol 2 RSA, respectively. | ||
474 | These files contain sensitive data and should be readable by the | ||
475 | user but not accessible by others (read/write/execute). Note | ||
476 | that ssh ignores a private key file if it is accessible by oth- | ||
477 | ers. It is possible to specify a passphrase when generating the | ||
478 | key; the passphrase will be used to encrypt the sensitive part of | ||
479 | this file using 3DES. | ||
480 | |||
481 | $HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub | ||
482 | Contains the public key for authentication (public part of the | ||
483 | identity file in human-readable form). The contents of the | ||
484 | $HOME/.ssh/identity.pub file should be added to | ||
485 | $HOME/.ssh/authorized_keys on all machines where the user wishes | ||
486 | to log in using protocol version 1 RSA authentication. The con- | ||
487 | tents of the $HOME/.ssh/id_dsa.pub and $HOME/.ssh/id_rsa.pub file | ||
488 | should be added to $HOME/.ssh/authorized_keys on all machines | ||
489 | where the user wishes to log in using protocol version 2 DSA/RSA | ||
490 | authentication. These files are not sensitive and can (but need | ||
491 | not) be readable by anyone. These files are never used automati- | ||
492 | cally and are not necessary; they are only provided for the con- | ||
493 | venience of the user. | ||
494 | |||
495 | $HOME/.ssh/config | ||
496 | This is the per-user configuration file. The file format and | ||
497 | configuration options are described in ssh_config(5). | ||
498 | |||
499 | $HOME/.ssh/authorized_keys | ||
500 | Lists the public keys (RSA/DSA) that can be used for logging in | ||
501 | as this user. The format of this file is described in the | ||
502 | sshd(8) manual page. In the simplest form the format is the same | ||
503 | as the .pub identity files. This file is not highly sensitive, | ||
504 | but the recommended permissions are read/write for the user, and | ||
505 | not accessible by others. | ||
506 | |||
507 | /etc/ssh/ssh_known_hosts | ||
508 | Systemwide list of known host keys. This file should be prepared | ||
509 | by the system administrator to contain the public host keys of | ||
510 | all machines in the organization. This file should be world- | ||
511 | readable. This file contains public keys, one per line, in the | ||
512 | following format (fields separated by spaces): system name, pub- | ||
513 | lic key and optional comment field. When different names are | ||
514 | used for the same machine, all such names should be listed, sepa- | ||
515 | rated by commas. The format is described on the sshd(8) manual | ||
516 | page. | ||
517 | |||
518 | The canonical system name (as returned by name servers) is used | ||
519 | by sshd(8) to verify the client host when logging in; other names | ||
520 | are needed because ssh does not convert the user-supplied name to | ||
521 | a canonical name before checking the key, because someone with | ||
522 | access to the name servers would then be able to fool host | ||
523 | authentication. | ||
524 | |||
525 | /etc/ssh/ssh_config | ||
526 | Systemwide configuration file. The file format and configuration | ||
527 | options are described in ssh_config(5). | ||
528 | |||
529 | /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, | ||
530 | /etc/ssh/ssh_host_rsa_key | ||
531 | These three files contain the private parts of the host keys and | ||
532 | are used for RhostsRSAAuthentication and HostbasedAuthentication. | ||
533 | If the protocol version 1 RhostsRSAAuthentication method is used, | ||
534 | ssh must be setuid root, since the host key is readable only by | ||
535 | root. For protocol version 2, ssh uses ssh-keysign(8) to access | ||
536 | the host keys for HostbasedAuthentication. This eliminates the | ||
537 | requirement that ssh be setuid root when that authentication | ||
538 | method is used. By default ssh is not setuid root. | ||
539 | |||
540 | $HOME/.rhosts | ||
541 | This file is used in .rhosts authentication to list the host/user | ||
542 | pairs that are permitted to log in. (Note that this file is also | ||
543 | used by rlogin and rsh, which makes using this file insecure.) | ||
544 | Each line of the file contains a host name (in the canonical form | ||
545 | returned by name servers), and then a user name on that host, | ||
546 | separated by a space. On some machines this file may need to be | ||
547 | world-readable if the userM-bM-^@M-^Ys home directory is on a NFS parti- | ||
548 | tion, because sshd(8) reads it as root. Additionally, this file | ||
549 | must be owned by the user, and must not have write permissions | ||
550 | for anyone else. The recommended permission for most machines is | ||
551 | read/write for the user, and not accessible by others. | ||
552 | |||
553 | Note that by default sshd(8) will be installed so that it | ||
554 | requires successful RSA host authentication before permitting | ||
555 | .rhosts authentication. If the server machine does not have the | ||
556 | clientM-bM-^@M-^Ys host key in /etc/ssh/ssh_known_hosts, it can be stored | ||
557 | in $HOME/.ssh/known_hosts. The easiest way to do this is to con- | ||
558 | nect back to the client from the server machine using ssh; this | ||
559 | will automatically add the host key to $HOME/.ssh/known_hosts. | ||
560 | |||
561 | $HOME/.shosts | ||
562 | This file is used exactly the same way as .rhosts. The purpose | ||
563 | for having this file is to be able to use rhosts authentication | ||
564 | with ssh without permitting login with rlogin or rsh(1). | ||
565 | |||
566 | /etc/hosts.equiv | ||
567 | This file is used during .rhosts authentication. It contains | ||
568 | canonical hosts names, one per line (the full format is described | ||
569 | on the sshd(8) manual page). If the client host is found in this | ||
570 | file, login is automatically permitted provided client and server | ||
571 | user names are the same. Additionally, successful RSA host | ||
572 | authentication is normally required. This file should only be | ||
573 | writable by root. | ||
574 | |||
575 | /etc/shosts.equiv | ||
576 | This file is processed exactly as /etc/hosts.equiv. This file | ||
577 | may be useful to permit logins using ssh but not using | ||
578 | rsh/rlogin. | ||
579 | |||
580 | /etc/ssh/sshrc | ||
581 | Commands in this file are executed by ssh when the user logs in | ||
582 | just before the userM-bM-^@M-^Ys shell (or command) is started. See the | ||
583 | sshd(8) manual page for more information. | ||
584 | |||
585 | $HOME/.ssh/rc | ||
586 | Commands in this file are executed by ssh when the user logs in | ||
587 | just before the userM-bM-^@M-^Ys shell (or command) is started. See the | ||
588 | sshd(8) manual page for more information. | ||
589 | |||
590 | $HOME/.ssh/environment | ||
591 | Contains additional definitions for environment variables, see | ||
592 | section ENVIRONMENT above. | ||
593 | |||
594 | DIAGNOSTICS | ||
595 | ssh exits with the exit status of the remote command or with 255 if an | ||
596 | error occurred. | ||
597 | |||
598 | SEE ALSO | ||
599 | rsh(1), scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), | ||
600 | telnet(1), ssh_config(5), ssh-keysign(8), sshd(8) | ||
601 | |||
602 | T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH | ||
603 | Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January | ||
604 | 2002, work in progress material. | ||
605 | |||
606 | AUTHORS | ||
607 | OpenSSH is a derivative of the original and free ssh 1.2.12 release by | ||
608 | Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo | ||
609 | de Raadt and Dug Song removed many bugs, re-added newer features and cre- | ||
610 | ated OpenSSH. Markus Friedl contributed the support for SSH protocol | ||
611 | versions 1.5 and 2.0. | ||
612 | |||
613 | BSD September 25, 1999 BSD | ||