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