-\define{versionidusing} \versionid $Id$
-
\C{using} Using PuTTY
This chapter provides a general introduction to some more advanced
scroll a line at a time using \i{Ctrl-PgUp} and \i{Ctrl-PgDn}. These
are still available if you configure the scrollbar to be invisible.
-By default the last 200 lines scrolled off the top are
+By default the last 2000 lines scrolled off the top are
preserved for you to look at. You can increase (or decrease) this
value using the configuration box; see \k{config-scrollback}.
are reporting a bug, it's often useful to paste the contents of the
Event Log into your bug report.
+(The Event Log is not the same as the facility to create a log file
+of your session; that's described in \k{using-logging}.)
+
\S2{using-specials} \ii{Special commands}
Depending on the protocol used for the current session, there may be
repeat key exchanges, see \k{config-ssh-kex-rekey}.
}
+\b \I{host key cache}Cache new host key type
+
+\lcont{
+Only available in SSH-2. This submenu appears only if the server has
+host keys of a type that PuTTY doesn't already have cached, and so
+won't use. Selecting a key here will allow PuTTY to use that key now
+and in future: PuTTY will do key here will cause a fresh key-exchange
+with the selected key, and immediately add that key to PuTTY's
+permanent cache (relying on the host key used at the start of the
+connection to cross-certify the new key). That key will be used for
+the rest of the current session; it may not actually be used for
+future sessions.
+
+Normally, PuTTY will carry on using a host key it already knows, even
+if the server offers key formats that PuTTY would otherwise prefer,
+to avoid host key prompts. As a result, if you've been using a server
+for some years, you may still be using an older key than a new user
+would use, due to server upgrades in the meantime. The SSH protocol
+unfortunately does not have organised facilities for host key migration
+and rollover, but this allows you to manually upgrade.
+}
+
\b \I{Break, SSH special command}Break
\lcont{
example, or \i{line-drawing characters}) are not being displayed
correctly in your PuTTY session, it may be that PuTTY is interpreting
the characters sent by the server according to the wrong \e{character
-set}. There are a lot of different character sets available, so it's
-entirely possible for this to happen.
+set}. There are a lot of different character sets available, and no
+good way for PuTTY to know which to use, so it's entirely possible
+for this to happen.
If you click \q{Change Settings} and look at the \q{Translation}
panel, you should see a large number of character sets which you can
\H{using-x-forwarding} Using \i{X11 forwarding} in SSH
The SSH protocol has the ability to securely forward X Window System
-applications over your encrypted SSH connection, so that you can run
-an application on the SSH server machine and have it put its windows
-up on your local machine without sending any X network traffic in
-the clear.
+\i{graphical applications} over your encrypted SSH connection, so that
+you can run an application on the SSH server machine and have it put
+its windows up on your local machine without sending any X network
+traffic in the clear.
In order to use this feature, you will need an X display server for
your Windows machine, such as Cygwin/X, X-Win32, or Exceed. This will probably
If this works, you should then be able to run X applications in the
remote session and have them display their windows on your PC.
-Note that if your PC X server requires \I{X11 authentication}authentication
-to connect, then PuTTY cannot currently support it. If this is a problem for
-you, you should mail the PuTTY authors \#{FIXME} and give details
-(see \k{feedback}).
-
For more options relating to X11 forwarding, see \k{config-ssh-x11}.
\H{using-port-forwarding} Using \i{port forwarding} in SSH
-The SSH protocol has the ability to forward arbitrary \i{network
-connection}s over your encrypted SSH connection, to avoid the network
-traffic being sent in clear. For example, you could use this to
-connect from your home computer to a \i{POP-3} server on a remote
-machine without your POP-3 password being visible to network
-sniffers.
+The SSH protocol has the ability to forward arbitrary \I{network
+connection}network (TCP) connections over your encrypted SSH
+connection, to avoid the network traffic being sent in clear. For
+example, you could use this to connect from your home computer to a
+\i{POP-3} server on a remote machine without your POP-3 password being
+visible to network sniffers.
In order to use port forwarding to \I{local port forwarding}connect
from your local machine to a port on a remote server, you need to:
file in \c{*.\i{PPK}} format which PuTTY will use to authenticate with the
server. This option is only meaningful if you are using SSH.
+If you are using Pageant, you can also specify a \e{public} key file
+(in RFC 4716 or OpenSSH format) to identify a specific key file to use.
+(This won't work if you're not running Pageant, of course.)
+
For general information on \i{public-key authentication}, see
\k{pubkey}.
\S2{using-cmdline-loghost} \i\c{-loghost}: specify a \i{logical host
name}
-This option overrides PuTTY's normal SSH host key caching policy by
+This option overrides PuTTY's normal SSH \i{host key caching policy} by
telling it the name of the host you expect your connection to end up
at (in cases where this differs from the location PuTTY thinks it's
connecting to). It can be a plain host name, or a host name followed
by a colon and a port number. See \k{config-loghost} for more detail
on this.
+\S2{using-cmdline-hostkey} \i\c{-hostkey}: \I{manually configuring
+host keys}manually specify an expected host key
+
+This option overrides PuTTY's normal SSH \i{host key caching policy} by
+telling it exactly what host key to expect, which can be useful if the
+normal automatic host key store in the Registry is unavailable. The
+argument to this option should be either a host key fingerprint, or an
+SSH-2 public key blob. See \k{config-ssh-kex-manual-hostkeys} for more
+information.
+
+You can specify this option more than once if you want to configure
+more than one key to be accepted.
+
\S2{using-cmdline-pgpfp} \i\c{-pgpfp}: display \i{PGP key fingerprint}s
This option causes the PuTTY tools not to run as normal, but instead
For example, \cq{-sercfg 19200,8,n,1,N} denotes a baud rate of
19200, 8 data bits, no parity, 1 stop bit and no flow control.
+
+\S2{using-cmdline-sshlog} \i\c{-sessionlog}, \i\c{-sshlog},
+\i\c{-sshrawlog}: specify session logging
+
+These options cause the PuTTY network tools to write out a \i{log
+file}. Each of them expects a file name as an argument, e.g.
+\cq{-sshlog putty.log} causes an SSH packet log to be written to a
+file called \cq{putty.log}. The three different options select
+different logging modes, all available from the GUI too:
+
+\b \c{-sessionlog} selects \q{All session output} logging mode.
+
+\b \c{-sshlog} selects \q{SSH packets} logging mode.
+
+\b \c{-sshrawlog} selects \q{SSH packets and raw data} logging mode.
+
+For more information on logging configuration, see \k{config-logging}.
projects / PuTTY.git / blobdiff