]>
Commit | Line | Data |
---|---|---|
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. |