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