Annotation of src/usr.bin/ssh/README, Revision 1.3
1.3 ! markus 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:
1.1 deraadt 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
1.2 deraadt 8: secure communications over insecure channels. It is intended as a
1.1 deraadt 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.
![[BACK]](/icons/back.gif){kind=icon}
Return to README CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / src / usr.bin / ssh