faq.but

来自「远程登陆工具软件源码 用于远程登陆unix」· BUT 代码 · 共 1,101 行 · 第 1/4 页

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
C at least have stopped being backwards compatible to Win32s. Also,
the last time we tried this it didn't work very well.

If you're interested in running PuTTY under Windows 3.1, help and
testing in this area would be very welcome!

\S{faq-mac-port}{Question} Will there be a port to the Mac?

There is a port to the Mac OS in progress. It's just about usable, but
has an awful lot of gaps and rough edges that will need cleaning up
before release (such as useful random numbers).

A separate port to Mac OS X is also underway.

\S{faq-epoc}{Question} Will there be a port to EPOC?

I hope so, but given that ports aren't really progressing very fast
even on systems the developers \e{do} already know how to program
for, it might be a long time before any of us get round to learning
a new system and doing the port for that.

However, some of the work has been done by other people, and a beta
port of PuTTY for the Nokia 9200 Communicator series is available
from \W{http://www.s2.org/putty/}\cw{http://www.s2.org/putty/}

\H{faq-embedding} Embedding PuTTY in other programs

\S{faq-dll}{Question} Is the SSH or Telnet code available as a DLL?

No, it isn't. It would take a reasonable amount of rewriting for
this to be possible, and since the PuTTY project itself doesn't
believe in DLLs (they make installation more error-prone) none of us
has taken the time to do it.

Most of the code cleanup work would be a good thing to happen in
general, so if anyone feels like helping, we wouldn't say no.

\S{faq-vb}{Question} Is the SSH or Telnet code available as a Visual
Basic component?

No, it isn't. None of the PuTTY team uses Visual Basic, and none of
us has any particular need to make SSH connections from a Visual
Basic application. In addition, all the preliminary work to turn it
into a DLL would be necessary first; and furthermore, we don't even
know how to write VB components.

If someone offers to do some of this work for us, we might consider
it, but unless that happens I can't see VB integration being
anywhere other than the very bottom of our priority list.

\S{faq-ipc}{Question} How can I use PuTTY to make an SSH connection
from within another program?

Probably your best bet is to use Plink, the command-line connection
tool. If you can start Plink as a second Windows process, and
arrange for your primary process to be able to send data to the
Plink process, and receive data from it, through pipes, then you
should be able to make SSH connections from your program.

This is what CVS for Windows does, for example.

\H{faq-details} Details of PuTTY's operation

\S{faq-term}{Question} What terminal type does PuTTY use?

For most purposes, PuTTY can be considered to be an \cw{xterm}
terminal.

PuTTY also supports some terminal control sequences not supported by
the real \cw{xterm}: notably the Linux console sequences that
reconfigure the colour palette, and the title bar control sequences
used by \cw{DECterm} (which are different from the \cw{xterm} ones;
PuTTY supports both).

By default, PuTTY announces its terminal type to the server as
\c{xterm}. If you have a problem with this, you can reconfigure it
to say something else; \c{vt220} might help if you have trouble.

\S{faq-settings}{Question} Where does PuTTY store its data?

On Windows, PuTTY stores most of its data (saved sessions, SSH host
keys) in the Registry. The precise location is

\c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY

and within that area, saved sessions are stored under \c{Sessions}
while host keys are stored under \c{SshHostKeys}.

PuTTY also requires a random number seed file, to improve the
unpredictability of randomly chosen data needed as part of the SSH
cryptography. This is stored by default in your Windows home
directory (\c{%HOMEDRIVE%\\%HOMEPATH%}), or in the actual Windows
directory (such as \c{C:\\WINDOWS}) if the home directory doesn't
exist, for example if you're using Win95. If you want to change the
location of the random number seed file, you can put your chosen
pathname in the Registry, at

\c HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile

On Unix, PuTTY stores all of this data in a directory \cw{~/.putty}.

\H{faq-howto} HOWTO questions

\S{faq-startmax}{Question} How can I make PuTTY start up maximised?

Create a Windows shortcut to start PuTTY from, and set it as \q{Run
Maximized}.

\S{faq-startsess}{Question} How can I create a Windows shortcut to
start a particular saved session directly?

To run a PuTTY session saved under the name \q{\cw{mysession}},
create a Windows shortcut that invokes PuTTY with a command line
like

\c \path\name\to\putty.exe -load mysession

(Note: prior to 0.53, the syntax was \c{@session}. This is now
deprecated and may be removed at some point.)

\S{faq-startssh}{Question} How can I start an SSH session straight
from the command line?

Use the command line \c{putty -ssh host.name}. Alternatively, create
a saved session that specifies the SSH protocol, and start the saved
session as shown in \k{faq-startsess}.

\S{faq-cutpaste}{Question} How do I copy and paste between PuTTY and
other Windows applications?

Copy and paste works similarly to the X Window System. You use the
left mouse button to select text in the PuTTY window. The act of
selection \e{automatically} copies the text to the clipboard: there
is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact,
pressing Ctrl-C will send a Ctrl-C character to the other end of
your connection (just like it does the rest of the time), which may
have unpleasant effects. The \e{only} thing you need to do, to copy
text to the clipboard, is to select it.

To paste the clipboard contents into a PuTTY window, by default you
click the right mouse button. If you have a three-button mouse and
are used to X applications, you can configure pasting to be done by
the middle button instead, but this is not the default because most
Windows users don't have a middle button at all.

You can also paste by pressing Shift-Ins.

\S{faq-options}{Question} How do I use all PuTTY's features (public
keys, proxying, cipher selection, etc.) in PSCP, PSFTP and Plink?

Most major features (e.g., public keys, port forwarding) are available
through command line options. See the documentation.

Not all features are accessible from the command line yet, although
we'd like to fix this. In the meantime, you can use most of
PuTTY's features if you create a PuTTY saved session, and then use
the name of the saved session on the command line in place of a
hostname. This works for PSCP, PSFTP and Plink (but don't expect
port forwarding in the file transfer applications!).

\S{faq-pscp}{Question} How do I use PSCP.EXE? When I double-click it
gives me a command prompt window which then closes instantly.

PSCP is a command-line application, not a GUI application. If you
run it without arguments, it will simply print a help message and
terminate.

To use PSCP properly, run it from a Command Prompt window. See
\k{pscp} in the documentation for more details.

\S{faq-pscp-spaces}{Question} How do I use PSCP to copy a file whose
name has spaces in?

If PSCP is using the traditional SCP protocol, this is confusing. If
you're specifying a file at the local end, you just use one set of
quotes as you would normally do:

\c pscp "local filename with spaces" user@host:
\c pscp user@host:myfile "local filename with spaces"

But if the filename you're specifying is on the \e{remote} side, you
have to use backslashes and two sets of quotes:

\c pscp user@host:"\"remote filename with spaces\"" local_filename
\c pscp local_filename user@host:"\"remote filename with spaces\""

Worse still, in a remote-to-local copy you have to specify the local
file name explicitly, otherwise PSCP will complain that they don't
match (unless you specified the \c{-unsafe} option). The following
command will give an error message:

\c c:\>pscp user@host:"\"oo er\"" .
\c warning: remote host tried to write to a file called 'oo er'
\c          when we requested a file called '"oo er"'.

Instead, you need to specify the local file name in full:

\c c:\>pscp user@host:"\"oo er\"" "oo er"

If PSCP is using the newer SFTP protocol, none of this is a problem,
and all filenames with spaces in are specified using a single pair
of quotes in the obvious way:

\c pscp "local file" user@host:
\c pscp user@host:"remote file" .

\H{faq-trouble} Troubleshooting

\S{faq-incorrect-mac}{Question} Why do I see \q{Incorrect MAC
received on packet}?

One possible cause of this that used to be common is a bug in old
SSH 2 servers distributed by \cw{ssh.com}. (This is not the only
possible cause; see \k{errors-crc} in the documentation.)
Version 2.3.0 and below of their SSH 2 server
constructs Message Authentication Codes in the wrong way, and
expects the client to construct them in the same wrong way. PuTTY
constructs the MACs correctly by default, and hence these old
servers will fail to work with it.

If you are using PuTTY version 0.52 or better, this should work
automatically: PuTTY should detect the buggy servers from their
version number announcement, and automatically start to construct
its MACs in the same incorrect manner as they do, so it will be able
to work with them.

If you are using PuTTY version 0.51 or below, you can enable the
workaround by going to the SSH panel and ticking the box labelled
\q{Imitate SSH 2 MAC bug}. It's possible that you might have to do
this with 0.52 as well, if a buggy server exists that PuTTY doesn't
know about.

In this context MAC stands for Message Authentication Code. It's a
cryptographic term, and it has nothing at all to do with Ethernet
MAC (Media Access Control) addresses.

\S{faq-pscp-protocol}{Question} Why do I see \q{Fatal: Protocol
error: Expected control record} in PSCP?

This happens because PSCP was expecting to see data from the server
that was part of the PSCP protocol exchange, and instead it saw data
that it couldn't make any sense of at all.

This almost always happens because the startup scripts in your
account on the server machine are generating output. This is
impossible for PSCP, or any other SCP client, to work around. You
should never use startup files (\c{.bashrc}, \c{.cshrc} and so on)
which generate output in non-interactive sessions.

This is not actually a PuTTY problem. If PSCP fails in this way,
then all other SCP clients are likely to fail in exactly the same
way. The problem is at the server end.

\S{faq-colours}{Question} I clicked on a colour in the Colours
panel, and the colour didn't change in my terminal.

That isn't how you're supposed to use the Colours panel.

During the course of a session, PuTTY potentially uses \e{all} the
colours listed in the Colours panel. It's not a question of using
only one of them and you choosing which one; PuTTY will use them
\e{all}. The purpose of the Colours panel is to let you adjust the
appearance of all the colours. So to change the colour of the
cursor, for example, you would select \q{Cursor Colour}, press the
\q{Modify} button, and select a new colour from the dialog box that
appeared. Similarly, if you want your session to appear in green,