\C{intro} Introduction to PuTTY
-\# PuTTY is an SSH and Telnet client
+PuTTY is a free SSH, Telnet and Rlogin client for 32-bit Windows
+systems.
-\# Section on `what is Telnet? what is SSH?' for the people who
-\# don't have the first clue what they are. Explain what they're
-\# good for and why you might want to use one, and explain under
-\# what conditions you might _not_ want to use one.
+\H{you-what} What are SSH, Telnet and Rlogin?
-\# Section on `what's the difference between Telnet and SSH?' where
-\# we evangelise - POLITELY! - about SSH and security
+If you already know what SSH, Telnet and Rlogin are, you can safely
+skip on to the next section.
+
+SSH, Telnet and Rlogin are three ways of doing the same thing:
+logging in to a multi-user computer from another computer, over a
+network.
+
+Multi-user operating systems, such as Unix and VMS, usually present
+a command-line interface to the user, much like the \q{Command
+Prompt} or \q{MS-DOS Prompt} in Windows. The system prints a prompt,
+and you type commands which the system will obey.
+
+Using this type of interface, there is no need for you to be sitting
+at the same machine you are typing commands to. The commands, and
+responses, can be sent over a network, so you can sit at one
+computer and give commands to another one, or even to more than one.
+
+SSH, Telnet and Rlogin are \e{network protocols} that allow you to
+do this. On the computer you sit at, you run a \e{client}, which
+makes a network connection to the other computer (the \e{server}).
+The network connection carries your keystrokes and commands from the
+client to the server, and carries the server's responses back to
+you.
+
+These protocols can also be used for other types of keyboard-based
+interactive session. In particular, there are a lot of bulletin
+boards, talker systems and MUDs (Multi-User Dungeons) which support
+access using Telnet. There are even a few that support SSH.
+
+You might want to use SSH, Telnet or Rlogin if:
+
+\b you have an account on a Unix or VMS system which you want to be
+able to access from somewhere else
+
+\b your Internet Service Provider provides you with a login account
+on a web server. (This might also be known as a \e{shell account}.
+A \e{shell} is the program that runs on the server and interprets
+your commands for you.)
+
+\b you want to use a bulletin board system, talker or MUD which can
+be accessed using Telnet.
+
+You probably do \e{not} want to use SSH, Telnet or Rlogin if:
+
+\b you only use Windows machines. Windows machines have their own
+ways of networking between themselves, and unless you are doing
+something fairly unusual, you will not need to use any of these
+remote login protocols.
+
+\H{which-one} How do SSH, Telnet and Rlogin differ?
+
+This list summarises some of the differences between SSH, Telnet and
+Rlogin.
+
+\b SSH is a recently designed, high-security protocol. It uses
+strong cryptography to protect your connection against
+eavesdropping, hijacking and other attacks. Telnet and Rlogin are
+both older protocols offering minimal security.
+
+\b Telnet allows you to pass some settings on to the server, such as
+environment variables. (These control various aspects of the
+server's behaviour. You can usually set them by entering commands
+into the server once you're connected, but it's easier to have
+Telnet do it automatically.) SSH and Rlogin do not support this.
+However, most modern Telnet servers don't allow it either, because
+it has been a constant source of security problems.
+
+\b SSH and Rlogin both allow you to log in to the server without
+having to type a password. (Rlogin's method of doing this is
+insecure, and can allow an attacker to access your account on the
+server. SSH's method is much more secure, and typically requires the
+attacker to have gained access to your actual client machine.)
+
+\b SSH allows you to connect to the server and automatically send a
+command, so that the server will run that command and then
+disconnect. So you can use it in automated processing.
+
+The Internet is a hostile environment and security is everybody's
+responsibility. If you are connecting across the open Internet, then
+we recommend you use SSH. If the server you want to connect to
+doesn't support SSH, it might be worth trying to persuade the
+administrator to install it.
+
+If you are behind a good firewall, it is more likely to be safe to
+use Telnet or Rlogin, but we still recommend you use SSH.
+
+\# perhaps a section on terminal emulation?
projects / u / mdw / putty / commitdiff