]> asedeno.scripts.mit.edu Git - PuTTY.git/blobdiff - doc/using.but
Note the interaction of jump lists and -cleanup.
[PuTTY.git] / doc / using.but
index 343612b05a9465bb89be953f99e94bebf1361aa7..7d184b7c21c3cd32c3a1df42b93e7b118ab92e3a 100644 (file)
@@ -206,13 +206,13 @@ repeat key exchanges, see \k{config-ssh-kex-rekey}.
 \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
 \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.
+won't consider. Selecting a key here will allow PuTTY to use that key
+now and in future: PuTTY will do a fresh key-exchange with the selected
+key, and immediately add that key to its 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, depending on your
+preferences (see \k{config-ssh-hostkey-order}).
 
 Normally, PuTTY will carry on using a host key it already knows, even
 if the server offers key formats that PuTTY would otherwise prefer,
 
 Normally, PuTTY will carry on using a host key it already knows, even
 if the server offers key formats that PuTTY would otherwise prefer,
@@ -220,7 +220,8 @@ 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
 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.
+and rollover, but this allows you to \I{host keys, upgrading}manually
+upgrade.
 }
 
 \b \I{Break, SSH special command}Break
 }
 
 \b \I{Break, SSH special command}Break
@@ -606,7 +607,9 @@ use the \c{-load} option (described in \k{using-cmdline-load}).
 If invoked with the \c{-cleanup} option, rather than running as
 normal, PuTTY will remove its \I{removing registry entries}registry
 entries and \i{random seed file} from the local machine (after
 If invoked with the \c{-cleanup} option, rather than running as
 normal, PuTTY will remove its \I{removing registry entries}registry
 entries and \i{random seed file} from the local machine (after
-confirming with the user).
+confirming with the user). It will also attempt to remove information
+about recently launched sessions stored in the \q{jump list} on
+Windows 7 and up.
 
 Note that on \i{multi-user systems}, \c{-cleanup} only removes
 registry entries and files associated with the currently logged-in
 
 Note that on \i{multi-user systems}, \c{-cleanup} only removes
 registry entries and files associated with the currently logged-in
@@ -899,9 +902,8 @@ The \c{-1} and \c{-2} options force PuTTY to use version \I{SSH-1}1
 or version \I{SSH-2}2 of the SSH protocol. These options are only
 meaningful if you are using SSH.
 
 or version \I{SSH-2}2 of the SSH protocol. These options are only
 meaningful if you are using SSH.
 
-These options are equivalent to selecting your preferred SSH
-protocol version as \q{1 only} or \q{2 only} in the SSH panel of the
-PuTTY configuration box (see \k{config-ssh-prot}).
+These options are equivalent to selecting the SSH protocol version in
+the SSH panel of the PuTTY configuration box (see \k{config-ssh-prot}).
 
 \S2{using-cmdline-ipversion} \i\c{-4} and \i\c{-6}: specify an
 \i{Internet protocol version}
 
 \S2{using-cmdline-ipversion} \i\c{-4} and \i\c{-6}: specify an
 \i{Internet protocol version}
@@ -934,22 +936,22 @@ authentication} box in the Auth panel of the PuTTY configuration box
 \S2{using-cmdline-loghost} \i\c{-loghost}: specify a \i{logical host
 name}
 
 \S2{using-cmdline-loghost} \i\c{-loghost}: specify a \i{logical host
 name}
 
-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.
+This option overrides PuTTY's normal SSH \I{host key cache}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
 
 
 \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.
+This option overrides PuTTY's normal SSH \I{host key cache}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.
 
 You can specify this option more than once if you want to configure
 more than one key to be accepted.
@@ -1000,3 +1002,43 @@ different logging modes, all available from the GUI too:
 \b \c{-sshrawlog} selects \q{SSH packets and raw data} logging mode.
 
 For more information on logging configuration, see \k{config-logging}.
 \b \c{-sshrawlog} selects \q{SSH packets and raw data} logging mode.
 
 For more information on logging configuration, see \k{config-logging}.
+
+\S2{using-cmdline-proxycmd} \i\c{-proxycmd}: specify a local proxy
+command
+
+This option enables PuTTY's mode for running a \I{Local proxy}command
+on the local machine and using it as a proxy for the network
+connection. It expects a shell command string as an argument.
+
+See \k{config-proxy-type} for more information on this, and on other
+proxy settings. In particular, note that since the special sequences
+described there are understood in the argument string, literal
+backslashes must be doubled (if you want \c{\\} in your command, you
+must put \c{\\\\} on the command line).
+
+\S2{using-cmdline-restrict-acl} \i\c{-restrict-acl}: restrict the
+\i{Windows process ACL}
+
+This option (on Windows only) causes PuTTY (or another PuTTY tool) to
+try to lock down the operating system's access control on its own
+process. If this succeeds, it should present an extra obstacle to
+malware that has managed to run under the same user id as the PuTTY
+process, by preventing it from attaching to PuTTY using the same
+interfaces debuggers use and either reading sensitive information out
+of its memory or hijacking its network session.
+
+This option is not enabled by default, because this form of
+interaction between Windows programs has many legitimate uses,
+including accessibility software such as screen readers. Also, it
+cannot provide full security against this class of attack in any case,
+because PuTTY can only lock down its own ACL \e{after} it has started
+up, and malware could still get in if it attacks the process between
+startup and lockdown. So it trades away noticeable convenience, and
+delivers less real security than you might want. However, if you do
+want to make that tradeoff anyway, the option is available.
+
+A PuTTY process started with \c{-restrict-acl} will pass that on to
+any processes started with Duplicate Session, New Session etc.
+(However, if you're invoking PuTTY tools explicitly, for instance as a
+proxy command, you'll need to arrange to pass them the
+\c{-restrict-acl} option yourself, if that's what you want.)