PuTTy
PuTTY is a free and open-source terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet, rlogin, and raw socket connection. It can also connect to a serial port (since version 0.59). The name “PuTTY” has no definitive meaning.
PuTTY was originally written for Microsoft Windows, but it has been ported to various other operating systems. Official ports are available for some Unix-like platforms, with work-in-progress ports to Classic Mac OS and Mac OS X, and unofficial ports have been contributed to platforms such as Symbian and Windows Mobile.
PuTTY was written and is maintained primarily by Simon Tatham and is currently beta software.
What are SSH, Telnet and Rlogin?
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 `Command Prompt’ or `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 _network protocols_ that allow you to do this. On the computer you sit at, you run a _client_, which makes a network connection to the other computer (the _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:
– you have an account on a Unix or VMS system which you want to be able to access from somewhere else
– your Internet Service Provider provides you with a login account on a web server. (This might also be known as a _shell account_. A _shell_ is the program that runs on the server and interprets your commands for you.)
– you want to use a bulletin board system, talker or MUD which can be accessed using Telnet.
You probably do _not_ want to use SSH, Telnet or Rlogin if: – you only use Windows. Windows computers 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.
How do SSH, Telnet and Rlogin differ?
This list summarises some of the differences between SSH, Telnet and Rlogin.
– SSH (which stands for `secure shell’) 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.
– 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 breaking the security requires the attacker to have gained access to your actual client machine.)
– 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 your client and server are both behind the same (good) firewall, it is more likely to be safe to use Telnet or Rlogin, but we still recommend you use SSH.
Starting a session
When you start PuTTY, you will see a dialog box. This dialog box allows you to control everything PuTTY can do. See chapter 4 for details of all the things you can control.
You don’t usually need to change most of the configuration options. To start the simplest kind of session, all you need to do is to enter a few basic parameters.
In the `Host Name’ box, enter the Internet host name of the server you want to connect to. You should have been told this by the provider of your login account.
Now select a login protocol to use, from the `Connection type’ buttons. For a login session, you should select Telnet, Rlogin or SSH. See section 1.2 for a description of the differences between the three protocols, and advice on which one to use. The fourth protocol, _Raw_, is not used for interactive login sessions; you would usually use this for debugging other Internet services. The fifth option, _Serial_, is used for connecting to a local serial line, and works somewhat differently.
When you change the selected protocol, the number in the `Port’ box will change. This is normal: it happens because the various login services are usually provided on different network ports by the server machine. Most servers will use the standard port numbers, so you will not need to change the port setting. If your server provides login services on a non-standard port, your system administrator should have told you which one.
Once you have filled in the `Host Name’, `Protocol’, and possibly `Port’ settings, you are ready to connect. Press the `Open’ button at the bottom of the dialog box, and PuTTY will begin trying to connect you to the server.
Verifying the host key (SSH only)
If you are not using the SSH protocol, you can skip this section. If you are using SSH to connect to a server for the first time, you will probably see a message looking something like this:
The server’s host key is not cached in the registry. You have no guarantee that the server is the computer you think it is. The server’s rsa2 key fingerprint is: ssh-rsa 1024 7b:e5:6f:a7:f4:f9:81:62:5c:e3:1f:bf:8b:57:6c:5a If you trust this host, hit Yes to add the key to PuTTY’s cache and carry on connecting. If you want to carry on connecting just once, without adding the key to the cache, hit No. If you do not trust this host, hit Cancel to abandon the connection.
This is a feature of the SSH protocol. It is designed to protect you against a network attack known as _spoofing_: secretly redirecting your connection to a different computer, so that you send your password to the wrong machine. Using this technique, an attacker would be able to learn the password that guards your login account, and could then log in as if they were you and use the account for their own purposes.
To prevent this attack, each server has a unique identifying code, called a _host key_. These keys are created in a way that prevents one server from forging another server’s key. So if you connect to a server and it sends you a different host key from the one you were expecting, PuTTY can warn you that the server may have been switched and that a spoofing attack might be in progress.
PuTTY records the host key for each server you connect to, in the Windows Registry. Every time you connect to a server, it checks that the host key presented by the server is the same host key as it was the last time you connected. If it is not, you will see a warning, and you will have the chance to abandon your connection before you type any private information (such as a password) into it.
However, when you connect to a server you have not connected to before, PuTTY has no way of telling whether the host key is the right one or not. So it gives the warning shown above, and asks you whether you want to trust this host key or not.
Whether or not to trust the host key is your choice. If you are connecting within a company network, you might feel that all the network users are on the same side and spoofing attacks are unlikely, so you might choose to trust the key without checking it. If you are connecting across a hostile network (such as the Internet), you should check with your system administrator, perhaps by telephone or in person. (Some modern servers have more than one host key. If the system administrator sends you more than one fingerprint, you should make sure the one PuTTY shows you is on the list, but it doesn’t matter which one it is.)
Logging in
After you have connected, and perhaps verified the server’s host key, you will be asked to log in, probably using a username and a password. Your system administrator should have provided you with these. Enter the username and the password, and the server should grant you access and begin your session. If you have mistyped your password, most servers will give you several chances to get it right.
If you are using SSH, be careful not to type your username wrongly, because you will not have a chance to correct it after you press Return; many SSH servers do not permit you to make two login attempts using different usernames. If you type your username wrongly, you must close PuTTY and start again.
If your password is refused but you are sure you have typed it correctly, check that Caps Lock is not enabled. Many login servers, particularly Unix computers, treat upper case and lower case as different when checking your password; so if Caps Lock is on, your password will probably be refused.
After logging in
After you log in to the server, what happens next is up to the server! Most servers will print some sort of login message and then present a prompt, at which you can type commands which the server will carry out. Some servers will offer you on-line help; others might not. If you are in doubt about what to do next, consult your system administrator.
Logging out
When you have finished your session, you should log out by typing the server’s own logout command. This might vary between servers; if in doubt, try `logout’ or `exit’, or consult a manual or your system administrator. When the server processes your logout command, the PuTTY window should close itself automatically.
You _can_ close a PuTTY session using the Close button in the window border, but this might confuse the server – a bit like hanging up a telephone unexpectedly in the middle of a conversation. We recommend you do not do this unless the server has stopped responding to you and you cannot close the window any other way.
Features
PuTTY supports many variations on the secure remote terminal, and provides user control over the SSH encryption key and protocol version, alternate ciphers such as 3DES, Arcfour, Blowfish, and DES, and Public-key authentication. It also can emulate control sequences from xterm, VT102 or ECMA-48 terminal emulation, and allows local, remote, or dynamic port forwarding with SSH (including X11 forwarding). The network communication layer supports IPv6, and the SSH protocol supports the zlib@openssh.com delayed compression scheme. It can also be used with local serial port connections.
PuTTY comes bundled with command-line SCP and SFTP clients, called “pscp” and “psftp” respectively.
Reference
