| Up to higher level directory | |||
| Name | Date | Size | |
|---|---|---|---|
| ChangeLog | 06-Nov-2007 | 98.1K | |
| COPYING.Ylonen | 06-Nov-2007 | 3.3K | |
| CREDITS | 06-Nov-2007 | 4.5K | |
| INSTALL | 06-Nov-2007 | 6.9K | |
| LICENCE | 06-Nov-2007 | 10K | |
| nchan.ms | 06-Nov-2007 | 3.8K | |
| nchan2.ms | 06-Nov-2007 | 2K | |
| OVERVIEW | 06-Nov-2007 | 6.5K | |
| README | 06-Nov-2007 | 3.1K | |
| README.Ylonen | 06-Nov-2007 | 26.1K | |
| WARNING.RNG | 06-Nov-2007 | 3.5K | |
README
1 [ A Japanese translation of this document is available at 2 [ http://www.unixuser.org/%7Eharuyama/security/openssh/index.html 3 [ Thanks to HARUYAMA Seigo <haruyama (a] nt.phys.s.u-tokyo.ac.jp> 4 5 ******* IMPORTANT 6 * On systmes which lack a /dev/random driver, version of this port 7 * prior to 1.2.2 were not correctly seeding OpenSSL's random number 8 * pool. This resulted in lower quality RSA keys being generated. If 9 * you generated host or user keys with v1.2.2 or previous versions, 10 * please generate new ones using a more recent version. 11 12 This is the port of OpenBSD's excellent OpenSSH[0] to Linux and other 13 Unices. 14 15 OpenSSH is based on the last free version of Tatu Ylonen's SSH with 16 all patent-encumbered algorithms removed (to external libraries), all 17 known security bugs fixed, new features reintroduced and many other 18 clean-ups. More information about SSH itself can be found in the file 19 README.Ylonen. OpenSSH has been created by Aaron Campbell, Bob Beck, 20 Markus Friedl, Niels Provos, Theo de Raadt, and Dug Song. It has a 21 homepage at http://www.openssh.com/ 22 23 This port consists of the re-introduction of autoconf support, PAM 24 support (for Linux and Solaris), EGD[1] support and replacements for 25 OpenBSD library functions that are (regrettably) absent from other 26 unices. This port has been best tested on Linux, Solaris, HPUX, NetBSD 27 and Irix. Support for AIX, SCO, NeXT and other Unices is underway. 28 This version actively tracks changes in the OpenBSD CVS repository. 29 30 The PAM support is now more functional than the popular packages of 31 commercial ssh-1.2.x. It checks "account" and "session" modules for 32 all logins, not just when using password authentication. 33 34 OpenSSH depends on Zlib[2], OpenSSL[3] and optionally PAM[4]. 35 36 There is now several mailing lists for this port of OpenSSH. Please 37 refer to http://www.openssh.com/list.html for details on how to join. 38 39 Please send bug reports and patches to the mailing list 40 openssh-unix-dev (a] mindrot.org. The list is open to posting by 41 unsubscribed users. 42 43 If you are a citizen of the USA or another country which restricts 44 export of cryptographic products, then please refrain from sending 45 crypto-related code or patches to the list. We cannot accept them. 46 Other code contribution are accepted, but please follow the OpenBSD 47 style guidelines[5]. 48 49 Please refer to the INSTALL document for information on how to install 50 OpenSSH on your system. There are a number of differences between this 51 port of OpenSSH and F-Secure SSH 1.x, please refer to the OpenSSH FAQ[6] 52 for details and general tips. 53 54 Damien Miller <djm (a] mindrot.org> 55 56 Miscellania - 57 58 This version of SSH is based upon code retrieved from the OpenBSD CVS 59 repository which in turn was based on the last free 60 version of SSH released by Tatu Ylonen. 61 62 References - 63 64 [0] http://www.openssh.com/faq.html 65 [1] http://www.lothar.com/tech/crypto/ 66 [2] ftp://ftp.freesoftware.com/pub/infozip/zlib/ 67 [3] http://www.openssl.org/ 68 [4] http://www.kernel.org/pub/linux/libs/pam/ (PAM is standard on Solaris) 69 [5] http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9&apropos=0&manpath=OpenBSD+Current 70 [6] http://www.openssh.com/faq.html 71
README.Ylonen
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 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 (a] sics.se. If you would 517 like to join, send a message to majordomo (a] 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 (a] sics.se. 525 526 527 ABOUT THE AUTHOR 528 529 This software was written by Tatu Ylonen <ylo (a] 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 (a] 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. 568
Terms of Use |
Privacy |
Trademarks |
Copyright Policy |
Site Guidelines |
Help
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Use.
Copyright © 1995-2008 Sun Microsystems, Inc.