X-Git-Url: https://asedeno.scripts.mit.edu/gitweb/?a=blobdiff_plain;f=doc%2Fconfig.but;h=94626ab0be64f65f954cd904b9f8bab53e9a4fe4;hb=145ecf611238c4f1e39d89d3eee40319a2c54fe8;hp=e56c069a1416535587b1cac94c4a8c2ad3ef37a2;hpb=de24c12e467b228f218cd5b14c30fdfd655bc487;p=PuTTY.git diff --git a/doc/config.but b/doc/config.but index e56c069a..94626ab0 100644 --- a/doc/config.but +++ b/doc/config.but @@ -1667,7 +1667,7 @@ Keepalives are only supported in Telnet and SSH; the Rlogin and Raw protocols offer no way of implementing them. (For an alternative, see \k{config-tcp-keepalives}.) -Note that if you are using \i{SSH-1} and the server has a bug that makes +Note that if you are using SSH-1 and the server has a bug that makes it unable to deal with SSH-1 ignore messages (see \k{config-ssh-bug-ignore1}), enabling keepalives will have no effect. @@ -1747,7 +1747,7 @@ arbitrary port (say, \cw{localhost} port 10022) were forwarded to a second machine's SSH port (say, \cw{foovax} port 22), and then started a second PuTTY connecting to the forwarded port. -In normal usage, the second PuTTY will access the host key cache +In normal usage, the second PuTTY will access the \i{host key cache} under the host name and port it actually connected to (i.e. \cw{localhost} port 10022 in this example). Using the logical host name option, however, you can configure the second PuTTY to cache @@ -2267,30 +2267,28 @@ client end. Likewise, data sent by PuTTY to the server is compressed first and the server decompresses it at the other end. This can help make the most of a low-\i{bandwidth} connection. -\S{config-ssh-prot} \q{Preferred \i{SSH protocol version}} +\S{config-ssh-prot} \q{\i{SSH protocol version}} \cfg{winhelp-topic}{ssh.protocol} -This allows you to select whether you would prefer to use \i{SSH protocol -version 1} or \I{SSH-2}version 2, and whether to permit falling back -to the other version. +This allows you to select whether to use \i{SSH protocol version 2} +or the older \I{SSH-1}version 1. -With the settings \q{1} and \q{2}, PuTTY will attempt to use protocol 1 -if the server you connect to does not offer protocol 2, and vice versa. +You should normally leave this at the default of \q{2}. As well as +having fewer features, the older SSH-1 protocol is no longer +developed, has many known cryptographic weaknesses, and is generally +not considered to be secure. PuTTY's protocol 1 implementation is +provided mainly for compatibility, and is no longer being enhanced. -If you select \q{1 only} or \q{2 only} here, PuTTY will only connect -if the server you connect to offers the SSH protocol version you -have specified. +If a server offers both versions, prefer \q{2}. If you have some +server or piece of equipment that only talks SSH-1, select \q{1} +here, and do not treat the resulting connection as secure. -You should normally leave this at the default, \q{2 only}. The older -SSH-1 protocol is no longer developed, has many known cryptographic -weaknesses, and is generally not considered to be secure. If you -permit use of SSH-1 by selecting \q{2} instead of \q{2 only}, an -active attacker can force downgrade to SSH-1 even if the server -you're connecting to supports SSH-2. - -PuTTY's protocol 1 implementation is provided mainly for -compatibility, and is no longer being enhanced. +PuTTY will not automatically fall back to the other version of the +protocol if the server turns out not to match your selection here; +instead, it will put up an error message and abort the connection. +This prevents an active attacker downgrading an intended SSH-2 +connection to SSH-1. \S{config-ssh-sharing} Sharing an SSH connection between PuTTY tools @@ -2483,6 +2481,53 @@ when the SSH connection is idle, so they shouldn't cause the same problems. The SSH-1 protocol, incidentally, has even weaker integrity protection than SSH-2 without rekeys. +\H{config-ssh-hostkey} The Host Keys panel + +The Host Keys panel allows you to configure options related to SSH-2 +\i{host key management}. + +Host keys are used to prove the server's identity, and assure you that +the server is not being spoofed (either by a man-in-the-middle attack +or by completely replacing it on the network). See \k{gs-hostkey} for +a basic introduction to host keys. + +This entire panel is only relevant to SSH protocol version 2; none of +these settings affect SSH-1 at all. + +\S{config-ssh-hostkey-order} \ii{Host key type} selection + +\cfg{winhelp-topic}{ssh.hostkey.order} + +PuTTY supports a variety of SSH-2 host key types, and allows you to +choose which one you prefer to use to identify the server. +Configuration is similar to cipher selection (see +\k{config-ssh-encryption}). + +PuTTY currently supports the following host key types: + +\b \q{Ed25519}: \i{Edwards-curve} \i{DSA} using a twisted Edwards +curve with modulus \cw{2^255-19}. + +\b \q{ECDSA}: \i{elliptic curve} \i{DSA} using one of the +NIST-standardised elliptic curves. + +\b \q{DSA}: straightforward \i{DSA} using modular exponentiation. + +\b \q{RSA}: the ordinary \i{RSA} algorithm. + +If PuTTY already has one or more host keys stored for the server, +it will prefer to use one of those, even if the server has a key +type that is higher in the preference order. You can add such a +key to PuTTY's cache from within an existing session using the +\q{Special Commands} menu; see \k{using-specials}. + +Otherwise, PuTTY will choose a key type based purely on the +preference order you specify in the configuration. + +If the first key type PuTTY finds is below the \q{warn below here} +line, you will see a warning box when you make the connection, similar +to that for cipher selection (see \k{config-ssh-encryption}). + \S{config-ssh-kex-manual-hostkeys} \ii{Manually configuring host keys} \cfg{winhelp-topic}{ssh.kex.manualhostkeys} @@ -2531,8 +2576,8 @@ If this box contains at least one host key or fingerprint when PuTTY makes an SSH connection, then PuTTY's automated host key management is completely bypassed: the connection will be permitted if and only if the host key presented by the server is one of the keys listed in this -box, and the host key store in the Registry will be neither read -\e{nor written}. +box, and the \I{host key cache}host key store in the Registry will be +neither read \e{nor written}, unless you explicitly do so. If the box is empty (as it usually is), then PuTTY's automated host key management will work as normal.