diff options
Diffstat (limited to 'README.Ylonen')
-rw-r--r-- | README.Ylonen | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/README.Ylonen b/README.Ylonen new file mode 100644 index 000000000..ed3608441 --- /dev/null +++ b/README.Ylonen | |||
@@ -0,0 +1,563 @@ | |||
1 | Ssh (Secure Shell) is a program to log into another computer over a | ||
2 | network, to execute commands in a remote machine, and to move files | ||
3 | from one machine to another. It provides strong authentication and | ||
4 | secure communications over insecure channels. It is inteded as a | ||
5 | replacement for rlogin, rsh, rcp, and rdist. | ||
6 | |||
7 | See the file INSTALL for installation instructions. See COPYING for | ||
8 | license terms and other legal issues. See RFC for a description of | ||
9 | the protocol. There is a WWW page for ssh; see http://www.cs.hut.fi/ssh. | ||
10 | |||
11 | This file has been updated to match ssh-1.2.12. | ||
12 | |||
13 | |||
14 | FEATURES | ||
15 | |||
16 | o Strong authentication. Closes several security holes (e.g., IP, | ||
17 | routing, and DNS spoofing). New authentication methods: .rhosts | ||
18 | together with RSA based host authentication, and pure RSA | ||
19 | authentication. | ||
20 | |||
21 | o Improved privacy. All communications are automatically and | ||
22 | transparently encrypted. RSA is used for key exchange, and a | ||
23 | conventional cipher (normally IDEA, DES, or triple-DES) for | ||
24 | encrypting the session. Encryption is started before | ||
25 | authentication, and no passwords or other information is | ||
26 | transmitted in the clear. Encryption is also used to protect | ||
27 | against spoofed packets. | ||
28 | |||
29 | o Secure X11 sessions. The program automatically sets DISPLAY on | ||
30 | the server machine, and forwards any X11 connections over the | ||
31 | secure channel. Fake Xauthority information is automatically | ||
32 | generated and forwarded to the remote machine; the local client | ||
33 | automatically examines incoming X11 connections and replaces the | ||
34 | fake authorization data with the real data (never telling the | ||
35 | remote machine the real information). | ||
36 | |||
37 | o Arbitrary TCP/IP ports can be redirected through the encrypted channel | ||
38 | in both directions (e.g., for e-cash transactions). | ||
39 | |||
40 | o No retraining needed for normal users; everything happens | ||
41 | automatically, and old .rhosts files will work with strong | ||
42 | authentication if administration installs host key files. | ||
43 | |||
44 | o Never trusts the network. Minimal trust on the remote side of | ||
45 | the connection. Minimal trust on domain name servers. Pure RSA | ||
46 | authentication never trusts anything but the private key. | ||
47 | |||
48 | o Client RSA-authenticates the server machine in the beginning of | ||
49 | every connection to prevent trojan horses (by routing or DNS | ||
50 | spoofing) and man-in-the-middle attacks, and the server | ||
51 | RSA-authenticates the client machine before accepting .rhosts or | ||
52 | /etc/hosts.equiv authentication (to prevent DNS, routing, or | ||
53 | IP-spoofing). | ||
54 | |||
55 | o Host authentication key distribution can be centrally by the | ||
56 | administration, automatically when the first connection is made | ||
57 | to a machine (the key obtained on the first connection will be | ||
58 | recorded and used for authentication in the future), or manually | ||
59 | by each user for his/her own use. The central and per-user host | ||
60 | key repositories are both used and complement each other. Host | ||
61 | keys can be generated centrally or automatically when the software | ||
62 | is installed. Host authentication keys are typically 1024 bits. | ||
63 | |||
64 | o Any user can create any number of user authentication RSA keys for | ||
65 | his/her own use. Each user has a file which lists the RSA public | ||
66 | keys for which proof of possession of the corresponding private | ||
67 | key is accepted as authentication. User authentication keys are | ||
68 | typically 1024 bits. | ||
69 | |||
70 | o The server program has its own server RSA key which is | ||
71 | automatically regenerated every hour. This key is never saved in | ||
72 | any file. Exchanged session keys are encrypted using both the | ||
73 | server key and the server host key. The purpose of the separate | ||
74 | server key is to make it impossible to decipher a captured session by | ||
75 | breaking into the server machine at a later time; one hour from | ||
76 | the connection even the server machine cannot decipher the session | ||
77 | key. The key regeneration interval is configurable. The server | ||
78 | key is normally 768 bits. | ||
79 | |||
80 | o An authentication agent, running in the user's laptop or local | ||
81 | workstation, can be used to hold the user's RSA authentication | ||
82 | keys. Ssh automatically forwards the connection to the | ||
83 | authentication agent over any connections, and there is no need to | ||
84 | store the RSA authentication keys on any machine in the network | ||
85 | (except the user's own local machine). The authentication | ||
86 | protocols never reveal the keys; they can only be used to verify | ||
87 | that the user's agent has a certain key. Eventually the agent | ||
88 | could rely on a smart card to perform all authentication | ||
89 | computations. | ||
90 | |||
91 | o The software can be installed and used (with restricted | ||
92 | functionality) even without root privileges. | ||
93 | |||
94 | o The client is customizable in system-wide and per-user | ||
95 | configuration files. Most aspects of the client's operation can | ||
96 | be configured. Different options can be specified on a per-host basis. | ||
97 | |||
98 | o Automatically executes conventional rsh (after displaying a | ||
99 | warning) if the server machine is not running sshd. | ||
100 | |||
101 | o Optional compression of all data with gzip (including forwarded X11 | ||
102 | and TCP/IP port data), which may result in significant speedups on | ||
103 | slow connections. | ||
104 | |||
105 | o Complete replacement for rlogin, rsh, and rcp. | ||
106 | |||
107 | |||
108 | WHY TO USE SECURE SHELL | ||
109 | |||
110 | Currently, almost all communications in computer networks are done | ||
111 | without encryption. As a consequence, anyone who has access to any | ||
112 | machine connected to the network can listen in on any communication. | ||
113 | This is being done by hackers, curious administrators, employers, | ||
114 | criminals, industrial spies, and governments. Some networks leak off | ||
115 | enough electromagnetic radiation that data may be captured even from a | ||
116 | distance. | ||
117 | |||
118 | When you log in, your password goes in the network in plain | ||
119 | text. Thus, any listener can then use your account to do any evil he | ||
120 | likes. Many incidents have been encountered worldwide where crackers | ||
121 | have started programs on workstations without the owners knowledge | ||
122 | just to listen to the network and collect passwords. Programs for | ||
123 | doing this are available on the Internet, or can be built by a | ||
124 | competent programmer in a few hours. | ||
125 | |||
126 | Any information that you type or is printed on your screen can be | ||
127 | monitored, recorded, and analyzed. For example, an intruder who has | ||
128 | penetrated a host connected to a major network can start a program | ||
129 | that listens to all data flowing in the network, and whenever it | ||
130 | encounters a 16-digit string, it checks if it is a valid credit card | ||
131 | number (using the check digit), and saves the number plus any | ||
132 | surrounding text (to catch expiration date and holder) in a file. | ||
133 | When the intruder has collected a few thousand credit card numbers, he | ||
134 | makes smallish mail-order purchases from a few thousand stores around | ||
135 | the world, and disappears when the goods arrive but before anyone | ||
136 | suspects anything. | ||
137 | |||
138 | Businesses have trade secrets, patent applications in preparation, | ||
139 | pricing information, subcontractor information, client data, personnel | ||
140 | data, financial information, etc. Currently, anyone with access to | ||
141 | the network (any machine on the network) can listen to anything that | ||
142 | goes in the network, without any regard to normal access restrictions. | ||
143 | |||
144 | Many companies are not aware that information can so easily be | ||
145 | recovered from the network. They trust that their data is safe | ||
146 | since nobody is supposed to know that there is sensitive information | ||
147 | in the network, or because so much other data is transferred in the | ||
148 | network. This is not a safe policy. | ||
149 | |||
150 | Individual persons also have confidential information, such as | ||
151 | diaries, love letters, health care documents, information about their | ||
152 | personal interests and habits, professional data, job applications, | ||
153 | tax reports, political documents, unpublished manuscripts, etc. | ||
154 | |||
155 | One should also be aware that economical intelligence and industrial | ||
156 | espionage has recently become a major priority of the intelligence | ||
157 | agencies of major governments. President Clinton recently assigned | ||
158 | economical espionage as the primary task of the CIA, and the French | ||
159 | have repeatedly been publicly boasting about their achievements on | ||
160 | this field. | ||
161 | |||
162 | |||
163 | There is also another frightening aspect about the poor security of | ||
164 | communications. Computer storage and analysis capability has | ||
165 | increased so much that it is feasible for governments, major | ||
166 | companies, and criminal organizations to automatically analyze, | ||
167 | identify, classify, and file information about millions of people over | ||
168 | the years. Because most of the work can be automated, the cost of | ||
169 | collecting this information is getting very low. | ||
170 | |||
171 | Government agencies may be able to monitor major communication | ||
172 | systems, telephones, fax, computer networks, etc., and passively | ||
173 | collect huge amounts of information about all people with any | ||
174 | significant position in the society. Most of this information is not | ||
175 | sensitive, and many people would say there is no harm in someone | ||
176 | getting that information. However, the information starts to get | ||
177 | sensitive when someone has enough of it. You may not mind someone | ||
178 | knowing what you bought from the shop one random day, but you might | ||
179 | not like someone knowing every small thing you have bought in the last | ||
180 | ten years. | ||
181 | |||
182 | If the government some day starts to move into a more totalitarian | ||
183 | direction (one should remember that Nazi Germany was created by | ||
184 | democratic elections), there is considerable danger of an ultimate | ||
185 | totalitarian state. With enough information (the automatically | ||
186 | collected records of an individual can be manually analyzed when the | ||
187 | person becomes interesting), one can form a very detailed picture of | ||
188 | the individual's interests, opinions, beliefs, habits, friends, | ||
189 | lovers, weaknesses, etc. This information can be used to 1) locate | ||
190 | any persons who might oppose the new system 2) use deception to | ||
191 | disturb any organizations which might rise against the government 3) | ||
192 | eliminate difficult individuals without anyone understanding what | ||
193 | happened. Additionally, if the government can monitor communications | ||
194 | too effectively, it becomes too easy to locate and eliminate any | ||
195 | persons distributing information contrary to the official truth. | ||
196 | |||
197 | Fighting crime and terrorism are often used as grounds for domestic | ||
198 | surveillance and restricting encryption. These are good goals, but | ||
199 | there is considerable danger that the surveillance data starts to get | ||
200 | used for questionable purposes. I find that it is better to tolerate | ||
201 | a small amount of crime in the society than to let the society become | ||
202 | fully controlled. I am in favor of a fairly strong state, but the | ||
203 | state must never get so strong that people become unable to spread | ||
204 | contra-offical information and unable to overturn the government if it | ||
205 | is bad. The danger is that when you notice that the government is | ||
206 | too powerful, it is too late. Also, the real power may not be where | ||
207 | the official government is. | ||
208 | |||
209 | For these reasons (privacy, protecting trade secrets, and making it | ||
210 | more difficult to create a totalitarian state), I think that strong | ||
211 | cryptography should be integrated to the tools we use every day. | ||
212 | Using it causes no harm (except for those who wish to monitor | ||
213 | everything), but not using it can cause huge problems. If the society | ||
214 | changes in undesirable ways, then it will be to late to start | ||
215 | encrypting. | ||
216 | |||
217 | Encryption has had a "military" or "classified" flavor to it. There | ||
218 | are no longer any grounds for this. The military can and will use its | ||
219 | own encryption; that is no excuse to prevent the civilians from | ||
220 | protecting their privacy and secrets. Information on strong | ||
221 | encryption is available in every major bookstore, scientific library, | ||
222 | and patent office around the world, and strong encryption software is | ||
223 | available in every country on the Internet. | ||
224 | |||
225 | Some people would like to make it illegal to use encryption, or to | ||
226 | force people to use encryption that governments can break. This | ||
227 | approach offers no protection if the government turns bad. Also, the | ||
228 | "bad guys" will be using true strong encryption anyway. Good | ||
229 | encryption techniques are too widely known to make them disappear. | ||
230 | Thus, any "key escrow encryption" or other restrictions will only help | ||
231 | monitor ordinary people and petty criminals. It does not help against | ||
232 | powerful criminals, terrorists, or espionage, because they will know | ||
233 | how to use strong encryption anyway. (One source for internationally | ||
234 | available encryption software is http://www.cs.hut.fi/crypto.) | ||
235 | |||
236 | |||
237 | OVERVIEW OF SECURE SHELL | ||
238 | |||
239 | The software consists of a number of programs. | ||
240 | |||
241 | sshd Server program run on the server machine. This | ||
242 | listens for connections from client machines, and | ||
243 | whenever it receives a connection, it performs | ||
244 | authentication and starts serving the client. | ||
245 | |||
246 | ssh This is the client program used to log into another | ||
247 | machine or to execute commands on the other machine. | ||
248 | "slogin" is another name for this program. | ||
249 | |||
250 | scp Securely copies files from one machine to another. | ||
251 | |||
252 | ssh-keygen Used to create RSA keys (host keys and user | ||
253 | authentication keys). | ||
254 | |||
255 | ssh-agent Authentication agent. This can be used to hold RSA | ||
256 | keys for authentication. | ||
257 | |||
258 | ssh-add Used to register new keys with the agent. | ||
259 | |||
260 | make-ssh-known-hosts | ||
261 | Used to create the /etc/ssh_known_hosts file. | ||
262 | |||
263 | |||
264 | Ssh is the program users normally use. It is started as | ||
265 | |||
266 | ssh host | ||
267 | |||
268 | or | ||
269 | |||
270 | ssh host command | ||
271 | |||
272 | The first form opens a new shell on the remote machine (after | ||
273 | authentication). The latter form executes the command on the remote | ||
274 | machine. | ||
275 | |||
276 | When started, the ssh connects sshd on the server machine, verifies | ||
277 | that the server machine really is the machine it wanted to connect, | ||
278 | exchanges encryption keys (in a manner which prevents an outside | ||
279 | listener from getting the keys), performs authentication using .rhosts | ||
280 | and /etc/hosts.equiv, RSA authentication, or conventional password | ||
281 | based authentication. The server then (normally) allocates a | ||
282 | pseudo-terminal and starts an interactive shell or user program. | ||
283 | |||
284 | The TERM environment variable (describing the type of the user's | ||
285 | terminal) is passed from the client side to the remote side. Also, | ||
286 | terminal modes will be copied from the client side to the remote side | ||
287 | to preserve user preferences (e.g., the erase character). | ||
288 | |||
289 | If the DISPLAY variable is set on the client side, the server will | ||
290 | create a dummy X server and set DISPLAY accordingly. Any connections | ||
291 | to the dummy X server will be forwarded through the secure channel, | ||
292 | and will be made to the real X server from the client side. An | ||
293 | arbitrary number of X programs can be started during the session, and | ||
294 | starting them does not require anything special from the user. (Note | ||
295 | that the user must not manually set DISPLAY, because then it would | ||
296 | connect directly to the real display instead of going through the | ||
297 | encrypted channel). This behavior can be disabled in the | ||
298 | configuration file or by giving the -x option to the client. | ||
299 | |||
300 | Arbitrary IP ports can be forwarded over the secure channel. The | ||
301 | program then creates a port on one side, and whenever a connection is | ||
302 | opened to this port, it will be passed over the secure channel, and a | ||
303 | connection will be made from the other side to a specified host:port | ||
304 | pair. Arbitrary IP forwarding must always be explicitly requested, | ||
305 | and cannot be used to forward privileged ports (unless the user is | ||
306 | root). It is possible to specify automatic forwards in a per-user | ||
307 | configuration file, for example to make electronic cash systems work | ||
308 | securely. | ||
309 | |||
310 | If there is an authentication agent on the client side, connection to | ||
311 | it will be automatically forwarded to the server side. | ||
312 | |||
313 | For more infomation, see the manual pages ssh(1), sshd(8), scp(1), | ||
314 | ssh-keygen(1), ssh-agent(1), ssh-add(1), and make-ssh-known-hosts(1) | ||
315 | included in this distribution. | ||
316 | |||
317 | |||
318 | X11 CONNECTION FORWARDING | ||
319 | |||
320 | X11 forwarding serves two purposes: it is a convenience to the user | ||
321 | because there is no need to set the DISPLAY variable, and it provides | ||
322 | encrypted X11 connections. I cannot think of any other easy way to | ||
323 | make X11 connections encrypted; modifying the X server, clients or | ||
324 | libraries would require special work for each machine, vendor and | ||
325 | application. Widely used IP-level encryption does not seem likely for | ||
326 | several years. Thus what we have left is faking an X server on the | ||
327 | same machine where the clients are run, and forwarding the connections | ||
328 | to a real X server over the secure channel. | ||
329 | |||
330 | X11 forwarding works as follows. The client extracts Xauthority | ||
331 | information for the server. It then creates random authorization | ||
332 | data, and sends the random data to the server. The server allocates | ||
333 | an X11 display number, and stores the (fake) Xauthority data for this | ||
334 | display. Whenever an X11 connection is opened, the server forwards | ||
335 | the connection over the secure channel to the client, and the client | ||
336 | parses the first packet of the X11 protocol, substitutes real | ||
337 | authentication data for the fake data (if the fake data matched), and | ||
338 | forwards the connection to the real X server. | ||
339 | |||
340 | If the display does not have Xauthority data, the server will create a | ||
341 | unix domain socket in /tmp/.X11-unix, and use the unix domain socket | ||
342 | as the display. No authentication information is forwarded in this | ||
343 | case. X11 connections are again forwarded over the secure channel. | ||
344 | To the X server the connections appear to come from the client | ||
345 | machine, and the server must have connections allowed from the local | ||
346 | machine. Using authentication data is always recommended because not | ||
347 | using it makes the display insecure. If XDM is used, it automatically | ||
348 | generates the authentication data. | ||
349 | |||
350 | One should be careful not to use "xin" or "xstart" or other similar | ||
351 | scripts that explicitly set DISPLAY to start X sessions in a remote | ||
352 | machine, because the connection will then not go over the secure | ||
353 | channel. The recommended way to start a shell in a remote machine is | ||
354 | |||
355 | xterm -e ssh host & | ||
356 | |||
357 | and the recommended way to execute an X11 application in a remote | ||
358 | machine is | ||
359 | |||
360 | ssh -n host emacs & | ||
361 | |||
362 | If you need to type a password/passphrase for the remote machine, | ||
363 | |||
364 | ssh -f host emacs | ||
365 | |||
366 | may be useful. | ||
367 | |||
368 | |||
369 | |||
370 | RSA AUTHENTICATION | ||
371 | |||
372 | RSA authentication is based on public key cryptograpy. The idea is | ||
373 | that there are two encryption keys, one for encryption and another for | ||
374 | decryption. It is not possible (on human timescale) to derive the | ||
375 | decryption key from the encryption key. The encryption key is called | ||
376 | the public key, because it can be given to anyone and it is not | ||
377 | secret. The decryption key, on the other hand, is secret, and is | ||
378 | called the private key. | ||
379 | |||
380 | RSA authentication is based on the impossibility of deriving the | ||
381 | private key from the public key. The public key is stored on the | ||
382 | server machine in the user's $HOME/.ssh/authorized_keys file. The | ||
383 | private key is only kept on the user's local machine, laptop, or other | ||
384 | secure storage. Then the user tries to log in, the client tells the | ||
385 | server the public key that the user wishes to use for authentication. | ||
386 | The server then checks if this public key is admissible. If so, it | ||
387 | generates a 256 bit random number, encrypts it with the public key, | ||
388 | and sends the value to the client. The client then decrypts the | ||
389 | number with its private key, computes a 128 bit MD5 checksum from the | ||
390 | resulting data, and sends the checksum back to the server. (Only a | ||
391 | checksum is sent to prevent chosen-plaintext attacks against RSA.) | ||
392 | The server checks computes a checksum from the correct data, | ||
393 | and compares the checksums. Authentication is accepted if the | ||
394 | checksums match. (Theoretically this indicates that the client | ||
395 | only probably knows the correct key, but for all practical purposes | ||
396 | there is no doubt.) | ||
397 | |||
398 | The RSA private key can be protected with a passphrase. The | ||
399 | passphrase can be any string; it is hashed with MD5 to produce an | ||
400 | encryption key for IDEA, which is used to encrypt the private part of | ||
401 | the key file. With passphrase, authorization requires access to the key | ||
402 | file and the passphrase. Without passphrase, authorization only | ||
403 | depends on possession of the key file. | ||
404 | |||
405 | RSA authentication is the most secure form of authentication supported | ||
406 | by this software. It does not rely on the network, routers, domain | ||
407 | name servers, or the client machine. The only thing that matters is | ||
408 | access to the private key. | ||
409 | |||
410 | All this, of course, depends on the security of the RSA algorithm | ||
411 | itself. RSA has been widely known since about 1978, and no effective | ||
412 | methods for breaking it are known if it is used properly. Care has | ||
413 | been taken to avoid the well-known pitfalls. Breaking RSA is widely | ||
414 | believed to be equivalent to factoring, which is a very hard | ||
415 | mathematical problem that has received considerable public research. | ||
416 | So far, no effective methods are known for numbers bigger than about | ||
417 | 512 bits. However, as computer speeds and factoring methods are | ||
418 | increasing, 512 bits can no longer be considered secure. The | ||
419 | factoring work is exponential, and 768 or 1024 bits are widely | ||
420 | considered to be secure in the near future. | ||
421 | |||
422 | |||
423 | RHOSTS AUTHENTICATION | ||
424 | |||
425 | Conventional .rhosts and hosts.equiv based authentication mechanisms | ||
426 | are fundamentally insecure due to IP, DNS (domain name server) and | ||
427 | routing spoofing attacks. Additionally this authentication method | ||
428 | relies on the integrity of the client machine. These weaknesses is | ||
429 | tolerable, and been known and exploited for a long time. | ||
430 | |||
431 | Ssh provides an improved version of these types of authentication, | ||
432 | because they are very convenient for the user (and allow easy | ||
433 | transition from rsh and rlogin). It permits these types of | ||
434 | authentication, but additionally requires that the client host be | ||
435 | authenticated using RSA. | ||
436 | |||
437 | The server has a list of host keys stored in /etc/ssh_known_host, and | ||
438 | additionally each user has host keys in $HOME/.ssh/known_hosts. Ssh | ||
439 | uses the name servers to obtain the canonical name of the client host, | ||
440 | looks for its public key in its known host files, and requires the | ||
441 | client to prove that it knows the private host key. This prevents IP | ||
442 | and routing spoofing attacks (as long as the client machine private | ||
443 | host key has not been compromized), but is still vulnerable to DNS | ||
444 | attacks (to a limited extent), and relies on the integrity of the | ||
445 | client machine as to who is requesting to log in. This prevents | ||
446 | outsiders from attacking, but does not protect against very powerful | ||
447 | attackers. If maximal security is desired, only RSA authentication | ||
448 | should be used. | ||
449 | |||
450 | It is possible to enable conventional .rhosts and /etc/hosts.equiv | ||
451 | authentication (without host authentication) at compile time by giving | ||
452 | the option --with-rhosts to configure. However, this is not | ||
453 | recommended, and is not done by default. | ||
454 | |||
455 | These weaknesses are present in rsh and rlogin. No improvement in | ||
456 | security will be obtained unless rlogin and rsh are completely | ||
457 | disabled (commented out in /etc/inetd.conf). This is highly | ||
458 | recommended. | ||
459 | |||
460 | |||
461 | WEAKEST LINKS IN SECURITY | ||
462 | |||
463 | One should understand that while this software may provide | ||
464 | cryptographically secure communications, it may be easy to | ||
465 | monitor the communications at their endpoints. | ||
466 | |||
467 | Basically, anyone with root access on the local machine on which you | ||
468 | are running the software may be able to do anything. Anyone with root | ||
469 | access on the server machine may be able to monitor your | ||
470 | communications, and a very talented root user might even be able to | ||
471 | send his/her own requests to your authentication agent. | ||
472 | |||
473 | One should also be aware that computers send out electromagnetic | ||
474 | radition that can sometimes be picked up hundreds of meters away. | ||
475 | Your keyboard is particularly easy to listen to. The image on your | ||
476 | monitor might also be seen on another monitor in a van parked behind | ||
477 | your house. | ||
478 | |||
479 | Beware that unwanted visitors might come to your home or office and | ||
480 | use your machine while you are away. They might also make | ||
481 | modifications or install bugs in your hardware or software. | ||
482 | |||
483 | Beware that the most effective way for someone to decrypt your data | ||
484 | may be with a rubber hose. | ||
485 | |||
486 | |||
487 | LEGAL ISSUES | ||
488 | |||
489 | As far as I am concerned, anyone is permitted to use this software | ||
490 | freely. However, see the file COPYING for detailed copying, | ||
491 | licensing, and distribution information. | ||
492 | |||
493 | In some countries, particularly France, Russia, Iraq, and Pakistan, | ||
494 | it may be illegal to use any encryption at all without a special | ||
495 | permit, and the rumor has it that you cannot get a permit for any | ||
496 | strong encryption. | ||
497 | |||
498 | This software may be freely imported into the United States; however, | ||
499 | the United States Government may consider re-exporting it a criminal | ||
500 | offence. | ||
501 | |||
502 | Note that any information and cryptographic algorithms used in this | ||
503 | software are publicly available on the Internet and at any major | ||
504 | bookstore, scientific library, or patent office worldwide. | ||
505 | |||
506 | THERE IS NO WARRANTY FOR THIS PROGRAM. Please consult the file | ||
507 | COPYING for more information. | ||
508 | |||
509 | |||
510 | MAILING LISTS AND OTHER INFORMATION | ||
511 | |||
512 | There is a mailing list for ossh. It is ossh@sics.se. If you would | ||
513 | like to join, send a message to majordomo@sics.se with "subscribe | ||
514 | ssh" in body. | ||
515 | |||
516 | The WWW home page for ssh is http://www.cs.hut.fi/ssh. It contains an | ||
517 | archive of the mailing list, and detailed information about new | ||
518 | releases, mailing lists, and other relevant issues. | ||
519 | |||
520 | Bug reports should be sent to ossh-bugs@sics.se. | ||
521 | |||
522 | |||
523 | ABOUT THE AUTHOR | ||
524 | |||
525 | This software was written by Tatu Ylonen <ylo@cs.hut.fi>. I work as a | ||
526 | researcher at Helsinki University of Technology, Finland. For more | ||
527 | information, see http://www.cs.hut.fi/~ylo/. My PGP public key is | ||
528 | available via finger from ylo@cs.hut.fi and from the key servers. I | ||
529 | prefer PGP encrypted mail. | ||
530 | |||
531 | The author can be contacted via ordinary mail at | ||
532 | Tatu Ylonen | ||
533 | Helsinki University of Technology | ||
534 | Otakaari 1 | ||
535 | FIN-02150 ESPOO | ||
536 | Finland | ||
537 | |||
538 | Fax. +358-0-4513293 | ||
539 | |||
540 | |||
541 | ACKNOWLEDGEMENTS | ||
542 | |||
543 | I thank Tero Kivinen, Timo Rinne, Janne Snabb, and Heikki Suonsivu for | ||
544 | their help and comments in the design, implementation and porting of | ||
545 | this software. I also thank numerous contributors, including but not | ||
546 | limited to Walker Aumann, Jurgen Botz, Hans-Werner Braun, Stephane | ||
547 | Bortzmeyer, Adrian Colley, Michael Cooper, David Dombek, Jerome | ||
548 | Etienne, Bill Fithen, Mark Fullmer, Bert Gijsbers, Andreas Gustafsson, | ||
549 | Michael Henits, Steve Johnson, Thomas Koenig, Felix Leitner, Gunnar | ||
550 | Lindberg, Andrew Macpherson, Marc Martinec, Paul Mauvais, Donald | ||
551 | McKillican, Leon Mlakar, Robert Muchsel, Mark Treacy, Bryan | ||
552 | O'Sullivan, Mikael Suokas, Ollivier Robert, Jakob Schlyter, Tomasz | ||
553 | Surmacz, Alvar Vinacua, Petri Virkkula, Michael Warfield, and | ||
554 | Cristophe Wolfhugel. | ||
555 | |||
556 | Thanks also go to Philip Zimmermann, whose PGP software and the | ||
557 | associated legal battle provided inspiration, motivation, and many | ||
558 | useful techniques, and to Bruce Schneier whose book Applied | ||
559 | Cryptography has done a great service in widely distributing knowledge | ||
560 | about cryptographic methods. | ||
561 | |||
562 | |||
563 | Copyright (c) 1995 Tatu Ylonen, Espoo, Finland. | ||