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