intro.but 3.8 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889
  1. \C{intro} Introduction to PuTTY
  2. PuTTY is a free SSH, Telnet, Rlogin, and SUPDUP client for Windows
  3. systems.
  4. \H{you-what} What are SSH, Telnet, Rlogin, and SUPDUP?
  5. If you already know what SSH, Telnet, Rlogin, and SUPDUP are, you can
  6. safely skip on to the next section.
  7. SSH, Telnet, Rlogin, and SUPDUP are four ways of doing the same thing:
  8. logging in to a multi-user computer from another computer, over a
  9. network.
  10. Multi-user operating systems, typically of the Unix family (such as
  11. Linux, MacOS, and the BSD family), usually present a \i{command-line
  12. interface} to the user, much like the \q{\i{Command Prompt}} or
  13. \q{\i{MS-DOS Prompt}} in Windows. The system prints a prompt, and you
  14. type commands which the system will obey.
  15. Using this type of interface, there is no need for you to be sitting
  16. at the same machine you are typing commands to. The commands, and
  17. responses, can be sent over a network, so you can sit at one
  18. computer and give commands to another one, or even to more than one.
  19. SSH, Telnet, Rlogin, and SUPDUP are \i\e{network protocols} that allow
  20. you to do this. On the computer you sit at, you run a \i\e{client},
  21. which makes a network connection to the other computer (the
  22. \i\e{server}). The network connection carries your keystrokes and
  23. commands from the client to the server, and carries the server's
  24. responses back to you.
  25. These protocols can also be used for other types of keyboard-based
  26. interactive session. In particular, there are a lot of bulletin
  27. boards, \i{talker systems} and \i{MUDs} (Multi-User Dungeons) which support
  28. access using Telnet. There are even a few that support SSH.
  29. You might want to use SSH, Telnet, Rlogin, or SUPDUP if:
  30. \b you have an account on a Unix system (or some other multi-user OS
  31. such as VMS or ITS) which you want to be able to access from somewhere
  32. else
  33. \b your Internet Service Provider provides you with a login account
  34. on a \i{web server}. (This might also be known as a \i\e{shell account}.
  35. A \e{shell} is the program that runs on the server and interprets
  36. your commands for you.)
  37. \b you want to use a \i{bulletin board system}, talker or MUD which can
  38. be accessed using Telnet.
  39. You probably do \e{not} want to use SSH, Telnet, Rlogin, or SUPDUP if:
  40. \b you only use Windows. Windows computers have their own
  41. ways of networking between themselves, and unless you are doing
  42. something fairly unusual, you will not need to use any of these
  43. remote login protocols.
  44. \H{which-one} How do SSH, Telnet, Rlogin, and SUPDUP differ?
  45. This list summarises some of the \i{differences between SSH, Telnet,
  46. Rlogin, and SUPDUP}.
  47. \b SSH (which stands for \q{\i{secure shell}}) is a recently designed,
  48. high-security protocol. It uses strong cryptography to protect your
  49. connection against eavesdropping, hijacking and other attacks. Telnet,
  50. Rlogin, and SUPDUP are all older protocols offering minimal security.
  51. \b SSH and Rlogin both allow you to \I{passwordless login}log in to the
  52. server without having to type a password. (Rlogin's method of doing this is
  53. insecure, and can allow an attacker to access your account on the
  54. server. SSH's method is much more secure, and typically breaking the
  55. security requires the attacker to have gained access to your actual
  56. client machine.)
  57. \b SSH allows you to connect to the server and automatically send a
  58. command, so that the server will run that command and then
  59. disconnect. So you can use it in automated processing.
  60. The Internet is a hostile environment and security is everybody's
  61. responsibility. If you are connecting across the open Internet, then
  62. we recommend you use SSH. If the server you want to connect to
  63. doesn't support SSH, it might be worth trying to persuade the
  64. administrator to install it.
  65. If your client and server are both behind the same (good) firewall,
  66. it is more likely to be safe to use Telnet, Rlogin, or SUPDUP, but we
  67. still recommend you use SSH.