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. 568