faq.but

大名鼎鼎的远程登录软件putty的Symbian版源码

\versionid $Id: faq.but,v 1.1.1.4.2.2 2004/12/29 11:32:19 pekangas Exp $

\A{faq} PuTTY FAQ

This FAQ is published on the PuTTY web site, and also provided as an
appendix in the manual.

\H{faq-intro} Introduction

\S{faq-what}{Question} What is PuTTY?

PuTTY is a client program for the SSH, Telnet and Rlogin network
protocols.

These protocols are all used to run a remote session on a computer,
over a network. PuTTY implements the client end of that session: the
end at which the session is displayed, rather than the end at which
it runs.

In really simple terms: you run PuTTY on a Windows machine, and tell
it to connect to (for example) a Unix machine. PuTTY opens a window.
Then, anything you type into that window is sent straight to the
Unix machine, and everything the Unix machine sends back is
displayed in the window. So you can work on the Unix machine as if
you were sitting at its console, while actually sitting somewhere
else.

\H{faq-support} Features supported in PuTTY

In general, if you want to know if PuTTY supports a particular
feature, you should look for it on the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/}{PuTTY web site}.
In particular:

\b try the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html}{changes
page}, and see if you can find the feature on there. If a feature is
listed there, it's been implemented. If it's listed as a change made
\e{since} the latest version, it should be available in the
development snapshots, in which case testing will be very welcome.

\b try the
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/}{Wishlist
page}, and see if you can find the feature there. If it's on there,
and not in the \q{Recently fixed} section, it probably \e{hasn't} been
implemented.

\S{faq-ssh2}{Question} Does PuTTY support SSH v2?

Yes. SSH v2 support has been available in PuTTY since version 0.50.

Public key authentication (both RSA and DSA) in SSH v2 is new in
version 0.52.

\S{faq-ssh2-keyfmt}{Question} Does PuTTY support reading OpenSSH or
\cw{ssh.com} SSHv2 private key files?

PuTTY doesn't support this natively, but as of 0.53
PuTTYgen can convert both OpenSSH and \cw{ssh.com} private key
files into PuTTY's format.

\S{faq-ssh1}{Question} Does PuTTY support SSH v1?

Yes. SSH 1 support has always been available in PuTTY.

\S{faq-localecho}{Question} Does PuTTY support local echo?

Yes. Version 0.52 has proper support for local echo.

In version 0.51 and before, local echo could not be separated from
local line editing (where you type a line of text locally, and it is
not sent to the server until you press Return, so you have the
chance to edit it and correct mistakes \e{before} the server sees
it). New in version 0.52, local echo and local line editing are
separate options, and by default PuTTY will try to determine
automatically whether to enable them or not, based on which protocol
you have selected and also based on hints from the server. If you
have a problem with PuTTY's default choice, you can force each
option to be enabled or disabled as you choose. The controls are in
the Terminal panel, in the section marked \q{Line discipline
options}.

\S{faq-savedsettings}{Question} Does PuTTY support storing settings,
so I don't have to change them every time?

Yes, all of PuTTY's settings can be saved in named session profiles.
See \k{config-saving} in the documentation for how to do this.

\S{faq-disksettings}{Question} Does PuTTY support storing its
settings in a disk file?

Not at present, although \k{config-file} in the documentation gives
a method of achieving the same effect.

\S{faq-fullscreen}{Question} Does PuTTY support full-screen mode,
like a DOS box?

Yes; this is a new feature in version 0.52.

\S{faq-password-remember}{Question} Does PuTTY have the ability to
remember my password so I don't have to type it every time?

No, it doesn't.

Remembering your password is a bad plan for obvious security
reasons: anyone who gains access to your machine while you're away
from your desk can find out the remembered password, and use it,
abuse it or change it.

In addition, it's not even \e{possible} for PuTTY to automatically
send your password in a Telnet session, because Telnet doesn't give
the client software any indication of which part of the login
process is the password prompt. PuTTY would have to guess, by
looking for words like \q{password} in the session data; and if your
login program is written in something other than English, this won't
work.

In SSH, remembering your password would be possible in theory, but
there doesn't seem to be much point since SSH supports public key
authentication, which is more flexible and more secure. See
\k{pubkey} in the documentation for a full discussion of public key
authentication.

\S{faq-hostkeys}{Question} Is there an option to turn off the
annoying host key prompts?

No, there isn't. And there won't be. Even if you write it yourself
and send us the patch, we won't accept it.

Those annoying host key prompts are the \e{whole point} of SSH.
Without them, all the cryptographic technology SSH uses to secure
your session is doing nothing more than making an attacker's job
slightly harder; instead of sitting between you and the server with
a packet sniffer, the attacker must actually subvert a router and
start modifying the packets going back and forth. But that's not all
that much harder than just sniffing; and without host key checking,
it will go completely undetected by client or server.

Host key checking is your guarantee that the encryption you put on
your data at the client end is the \e{same} encryption taken off the
data at the server end; it's your guarantee that it hasn't been
removed and replaced somewhere on the way. Host key checking makes
the attacker's job \e{astronomically} hard, compared to packet
sniffing, and even compared to subverting a router. Instead of
applying a little intelligence and keeping an eye on Bugtraq, the
attacker must now perform a brute-force attack against at least one
military-strength cipher. That insignificant host key prompt really
does make \e{that} much difference.

If you're having a specific problem with host key checking - perhaps
you want an automated batch job to make use of PSCP or Plink, and
the interactive host key prompt is hanging the batch process - then
the right way to fix it is to add the correct host key to the
Registry in advance. That way, you retain the \e{important} feature
of host key checking: the right key will be accepted and the wrong
ones will not. Adding an option to turn host key checking off
completely is the wrong solution and we will not do it.

If you have host keys available in the common \c{known_hosts} format,
we have a script called 
\W{http://cvs.tartarus.org/putty/contrib/kh2reg.py}\c{kh2reg.py}
to convert them to a Windows .REG file, which can be installed ahead of
time by double-clicking or using \c{REGEDIT}.

\S{faq-server}{Question} Will you write an SSH server for the PuTTY
suite, to go with the client?

No. The only reason we might want to would be if we could easily
re-use existing code and significantly cut down the effort. We don't
believe this is the case; there just isn't enough common ground
between an SSH client and server to make it worthwhile.

If someone else wants to use bits of PuTTY in the process of writing
a Windows SSH server, they'd be perfectly welcome to of course, but
I really can't see it being a lot less effort for us to do that than
it would be for us to write a server from the ground up. We don't
have time, and we don't have motivation. The code is available if
anyone else wants to try it.

\S{faq-pscp-ascii}{Question} Can PSCP or PSFTP transfer files in
ASCII mode?

Unfortunately not.

Until recently, this was a limitation of the file transfer protocols:
the SCP and SFTP protocols had no notion of transferring a file in
anything other than binary mode. (This is still true of SCP.)

The current draft protocol spec of SFTP proposes a means of
implementing ASCII transfer. At some point PSCP/PSFTP may implement
this proposal.

\H{faq-ports} Ports to other operating systems

The eventual goal is for PuTTY to be a multi-platform program, able
to run on at least Windows, Mac OS and Unix.

Porting will become easier once PuTTY has a generalised porting
layer, drawing a clear line between platform-dependent and
platform-independent code. The general intention was for this
porting layer to evolve naturally as part of the process of doing
the first port; a Unix port has now been released and the plan
seems to be working so far.

\S{faq-ports-general}{Question} What ports of PuTTY exist?

Currently, release versions of PuTTY tools only run on full Win32
systems and Unix. \q{Win32} includes Windows 95, 98, and ME, and it
includes Windows NT, Windows 2000 and Windows XP.

In the development code, a partial port to the Mac OS (see
\k{faq-mac-port}) is under way.

Currently PuTTY does \e{not} run on Windows CE (see \k{faq-wince}),
and it does not quite run on the Win32s environment under Windows
3.1 (see \k{faq-win31}).

We do not have release-quality ports for any other systems at the
present time. If anyone told you we had an EPOC port, or an iPaq port,
or any other port of PuTTY, they were mistaken. We don't.

There are some third-party ports to various platforms, mentioned
on the Links page of our website.

\S{faq-unix}{Question} Is there a port to Unix?

As of 0.54, there are Unix ports of most of the traditional PuTTY
tools, and also one entirely new application.

If you look at the source release, you should find a \c{unix}
subdirectory containing \c{Makefile.gtk}, which should build you Unix
ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, and also
\c{pterm} - an \cw{xterm}-type program which supports the same
terminal emulation as PuTTY. We do not yet have a Unix port of
Pageant.

If you don't have Gtk, you should still be able to build the
command-line tools.

Note that Unix PuTTY has mostly only been tested on Linux so far;
portability problems such as BSD-style ptys or different header file
requirements are expected.

\S{faq-unix-why}{Question} What's the point of the Unix port? Unix
has OpenSSH.

All sorts of little things. \c{pterm} is directly useful to anyone
who prefers PuTTY's terminal emulation to \c{xterm}'s, which at
least some people do. Unix Plink has apparently found a niche among
people who find the complexity of OpenSSL makes OpenSSH hard to
install (and who don't mind Plink not having as many features). Some
users want to generate a large number of SSH keys on Unix and then
copy them all into PuTTY, and the Unix PuTTYgen should allow them to
automate that conversion process.

There were development advantages as well; porting PuTTY to Unix was
a valuable path-finding effort for other future ports, and also
allowed us to use the excellent Linux tool
\W{http://valgrind.kde.org/}{Valgrind} to help with debugging, which
has already improved PuTTY's stability on \e{all} platforms.

However, if you're a Unix user and you can see no reason to switch
from OpenSSH to PuTTY/Plink, then you're probably right. We don't
expect our Unix port to be the right thing for everybody.

\S{faq-wince}{Question} Will there be a port to Windows CE or PocketPC?

It's currently being worked on, but it's only in its early stages yet,
and certainly isn't yet useful.  PuTTY on portable devices would
clearly be a useful thing, so in the long term I hope it can be
brought up to release quality.

There's also a third-party port at
\W{http://pocketputty.duxy.net/}\c{http://pocketputty.duxy.net/}.

\S{faq-win31}{Question} Is there a port to Windows 3.1?

PuTTY is a 32-bit application from the ground up, so it won't run on
Windows 3.1 as a native 16-bit program; and it would be \e{very}
hard to port it to do so, because of Windows 3.1's vile memory
allocation mechanisms.

However, it is possible in theory to compile the existing PuTTY
source in such a way that it will run under Win32s (an extension to
Windows 3.1 to let you run 32-bit programs). In order to do this
you'll need the right kind of C compiler - modern versions of Visual