]>
Commit | Line | Data |
---|---|---|
1c1af145 | 1 | \define{versionidgs} \versionid $Id$ |
2 | ||
3 | \C{gs} Getting started with PuTTY | |
4 | ||
5 | This chapter gives a quick guide to the simplest types of | |
6 | interactive login session using PuTTY. | |
7 | ||
8 | \H{gs-insecure} \ii{Starting a session} | |
9 | ||
10 | When you start PuTTY, you will see a \i{dialog box}. This dialog box | |
11 | allows you to control everything PuTTY can do. See \k{config} for | |
12 | details of all the things you can control. | |
13 | ||
14 | You don't usually need to change most of the configuration options. | |
15 | To start the simplest kind of session, all you need to do is to | |
16 | enter a few basic parameters. | |
17 | ||
18 | In the \q{Host Name} box, enter the Internet \i{host name} of the server | |
19 | you want to connect to. You should have been told this by the | |
20 | provider of your login account. | |
21 | ||
22 | Now select a login \i{protocol} to use, from the \q{Connection type} | |
23 | buttons. For a login session, you should select \i{Telnet}, | |
24 | \i{Rlogin} or \i{SSH}. See \k{which-one} for a description of the | |
25 | differences between the three protocols, and advice on which one to | |
26 | use. The fourth protocol, \I{raw protocol}\e{Raw}, is not used for | |
27 | interactive login sessions; you would usually use this for debugging | |
28 | other Internet services (see \k{using-rawprot}). The fifth option, | |
29 | \e{Serial}, is used for connecting to a local serial line, and works | |
30 | somewhat differently: see \k{using-serial} for more information on | |
31 | this. | |
32 | ||
33 | When you change the selected protocol, the number in the \q{Port} | |
34 | box will change. This is normal: it happens because the various | |
35 | login services are usually provided on different network ports by | |
36 | the server machine. Most servers will use the standard port numbers, | |
37 | so you will not need to change the port setting. If your server | |
38 | provides login services on a non-standard port, your system | |
39 | administrator should have told you which one. (For example, many | |
40 | \i{MUDs} run Telnet service on a port other than 23.) | |
41 | ||
42 | Once you have filled in the \q{Host Name}, \q{Protocol}, and | |
43 | possibly \q{Port} settings, you are ready to connect. Press the | |
44 | \q{Open} button at the bottom of the dialog box, and PuTTY will | |
45 | begin trying to connect you to the server. | |
46 | ||
47 | \H{gs-hostkey} \ii{Verifying the host key} (SSH only) | |
48 | ||
49 | If you are not using the \i{SSH} protocol, you can skip this | |
50 | section. | |
51 | ||
52 | If you are using SSH to connect to a server for the first time, you | |
53 | will probably see a message looking something like this: | |
54 | ||
55 | \c The server's host key is not cached in the registry. You | |
56 | \c have no guarantee that the server is the computer you | |
57 | \c think it is. | |
58 | \c The server's rsa2 key fingerprint is: | |
59 | \c ssh-rsa 1024 7b:e5:6f:a7:f4:f9:81:62:5c:e3:1f:bf:8b:57:6c:5a | |
60 | \c If you trust this host, hit Yes to add the key to | |
61 | \c PuTTY's cache and carry on connecting. | |
62 | \c If you want to carry on connecting just once, without | |
63 | \c adding the key to the cache, hit No. | |
64 | \c If you do not trust this host, hit Cancel to abandon the | |
65 | \c connection. | |
66 | ||
67 | This is a feature of the SSH protocol. It is designed to protect you | |
68 | against a network attack known as \i\e{spoofing}: secretly | |
69 | redirecting your connection to a different computer, so that you | |
70 | send your password to the wrong machine. Using this technique, an | |
71 | attacker would be able to learn the password that guards your login | |
72 | account, and could then log in as if they were you and use the | |
73 | account for their own purposes. | |
74 | ||
75 | To prevent this attack, each server has a unique identifying code, | |
76 | called a \e{host key}. These keys are created in a way that prevents | |
77 | one server from forging another server's key. So if you connect to a | |
78 | server and it sends you a different host key from the one you were | |
79 | expecting, PuTTY can warn you that the server may have been switched | |
80 | and that a spoofing attack might be in progress. | |
81 | ||
82 | PuTTY records the host key for each server you connect to, in the | |
83 | Windows \i{Registry}. Every time you connect to a server, it checks | |
84 | that the host key presented by the server is the same host key as it | |
85 | was the last time you connected. If it is not, you will see a | |
86 | warning, and you will have the chance to abandon your connection | |
87 | before you type any private information (such as a password) into | |
88 | it. | |
89 | ||
90 | However, when you connect to a server you have not connected to | |
91 | before, PuTTY has no way of telling whether the host key is the | |
92 | right one or not. So it gives the warning shown above, and asks you | |
93 | whether you want to \I{trusting host keys}trust this host key or | |
94 | not. | |
95 | ||
96 | Whether or not to trust the host key is your choice. If you are | |
97 | connecting within a company network, you might feel that all the | |
98 | network users are on the same side and spoofing attacks are | |
99 | unlikely, so you might choose to trust the key without checking it. | |
100 | If you are connecting across a hostile network (such as the | |
101 | Internet), you should check with your system administrator, perhaps | |
102 | by telephone or in person. (Some modern servers have more than one | |
103 | host key. If the system administrator sends you more than one | |
104 | \I{host key fingerprint}fingerprint, you should make sure the one | |
105 | PuTTY shows you is on the list, but it doesn't matter which one it is.) | |
106 | ||
107 | \# FIXME: this is all very fine but of course in practice the world | |
108 | doesn't work that way. Ask the team if they have any good ideas for | |
109 | changes to this section! | |
110 | ||
111 | \H{gs-login} \ii{Logging in} | |
112 | ||
113 | After you have connected, and perhaps verified the server's host | |
114 | key, you will be asked to log in, probably using a \i{username} and | |
115 | a \i{password}. Your system administrator should have provided you | |
116 | with these. Enter the username and the password, and the server | |
117 | should grant you access and begin your session. If you have | |
118 | \I{mistyping a password}mistyped your password, most servers will | |
119 | give you several chances to get it right. | |
120 | ||
121 | If you are using SSH, be careful not to type your username wrongly, | |
122 | because you will not have a chance to correct it after you press | |
123 | Return; many SSH servers do not permit you to make two login attempts | |
124 | using \i{different usernames}. If you type your username wrongly, you | |
125 | must close PuTTY and start again. | |
126 | ||
127 | If your password is refused but you are sure you have typed it | |
128 | correctly, check that Caps Lock is not enabled. Many login servers, | |
129 | particularly Unix computers, treat upper case and lower case as | |
130 | different when checking your password; so if Caps Lock is on, your | |
131 | password will probably be refused. | |
132 | ||
133 | \H{gs-session} After logging in | |
134 | ||
135 | After you log in to the server, what happens next is up to the | |
136 | server! Most servers will print some sort of login message and then | |
137 | present a \i{prompt}, at which you can type | |
138 | \I{commands on the server}commands which the | |
139 | server will carry out. Some servers will offer you on-line help; | |
140 | others might not. If you are in doubt about what to do next, consult | |
141 | your system administrator. | |
142 | ||
143 | \H{gs-logout} \ii{Logging out} | |
144 | ||
145 | When you have finished your session, you should log out by typing | |
146 | the server's own logout command. This might vary between servers; if | |
147 | in doubt, try \c{logout} or \c{exit}, or consult a manual or your | |
148 | system administrator. When the server processes your logout command, | |
149 | the PuTTY window should close itself automatically. | |
150 | ||
151 | You \e{can} close a PuTTY session using the \i{Close button} in the | |
152 | window border, but this might confuse the server - a bit like | |
153 | hanging up a telephone unexpectedly in the middle of a conversation. | |
154 | We recommend you do not do this unless the server has stopped | |
155 | responding to you and you cannot close the window any other way. |