gs.but 8.1 KB

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