nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-07-01 03:22:48 -05:00
Code Issues Projects Releases Wiki Activity

Consistently use a single notation to refer to SSH protocol versions, as

Browse Source 
discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol
version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com
implementations in this scheme). <http://www.snailbook.com/terms.html>

[originally from svn r5480]
This commit is contained in:
Jacob Nevins
2005-03-10 16:36:05 +00:00
parent dfccca7974
commit 5aa719d16e
30 changed files with 269 additions and 269 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
doc/config.but
View File

@ -1563,8 +1563,8 @@ 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 SSH1 and the server has a bug that makes
it unable to deal with SSH1 ignore messages (see
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.
\S{config-nodelay} \q{Disable Nagle's algorithm}
@ -1701,10 +1701,10 @@ other ways around the security problems than just disabling the
whole mechanism.
Version 2 of the SSH protocol also provides a similar mechanism,
which is easier to implement without security flaws. Newer SSH2
which is easier to implement without security flaws. Newer SSH-2
servers are more likely to support it than older ones.
This configuration data is not used in the SSHv1, rlogin or raw
This configuration data is not used in the SSH-1, rlogin or raw
protocols.
To add an environment variable to the list transmitted down the
@ -2126,11 +2126,11 @@ separate configuration of the preference orders. As a result you may
get two warnings similar to the one above, possibly with different
encryptions.
Single-DES is not recommended in the SSH 2 draft protocol
Single-DES is not recommended in the SSH-2 draft protocol
standards, but one or two server implementations do support it.
PuTTY can use single-DES to interoperate with
these servers if you enable the \q{Enable legacy use of single-DES in
SSH 2} option; by default this is disabled and PuTTY will stick to
SSH-2} option; by default this is disabled and PuTTY will stick to
recommended ciphers.
\H{config-ssh-kex} The Kex panel
@ -2283,7 +2283,7 @@ responses take.
\cfg{winhelp-topic}{ssh.auth.ki}
The SSH 2 equivalent of TIS authentication is called
The SSH-2 equivalent of TIS authentication is called
\q{keyboard-interactive}. It is a flexible authentication method
using an arbitrary sequence of requests and responses; so it is not
only useful for challenge/response mechanisms such as S/Key, but it
@ -2306,17 +2306,17 @@ See \k{pageant} for general information on Pageant, and
there is a security risk involved with enabling this option; see
\k{pageant-security} for details.
\S{config-ssh-changeuser} \q{Allow attempted changes of username in SSH2}
\S{config-ssh-changeuser} \q{Allow attempted changes of username in SSH-2}
\cfg{winhelp-topic}{ssh.auth.changeuser}
In the SSH 1 protocol, it is impossible to change username after
In the SSH-1 protocol, it is impossible to change username after
failing to authenticate. So if you mis-type your username at the
PuTTY \q{login as:} prompt, you will not be able to change it except
by restarting PuTTY.
The SSH 2 protocol \e{does} allow changes of username, in principle,
but does not make it mandatory for SSH 2 servers to accept them. In
The SSH-2 protocol \e{does} allow changes of username, in principle,
but does not make it mandatory for SSH-2 servers to accept them. In
particular, OpenSSH does not accept a change of username; once you
have sent one username, it will reject attempts to try to
authenticate as another user. (Depending on the version of OpenSSH,
@ -2391,7 +2391,7 @@ experimental feature, and may encounter several problems:
\cw{XDM-AUTHORIZATION-1}, so they will not know what to do with the
data PuTTY has provided.
\b This authentication mechanism will only work in SSH v2. In SSH
\b This authentication mechanism will only work in SSH-2. In SSH
v1, the SSH server does not tell the client the source address of
a forwarded connection in a machine-readable format, so it's
impossible to verify the \cw{XDM-AUTHORIZATION-1} data.
@ -2465,10 +2465,10 @@ If you delete a local or dynamic port forwarding in mid-session, PuTTY
will stop listening for connections on that port, so it can be re-used
by another program. If you delete a remote port forwarding, note that:
\b The SSHv1 protocol contains no mechanism for asking the server to
\b The SSH-1 protocol contains no mechanism for asking the server to
stop listening on a remote port.
\b The SSHv2 protocol does contain such a mechanism, but not all SSH
\b The SSH-2 protocol does contain such a mechanism, but not all SSH
servers support it. (In particular, OpenSSH does not support it in
any version earlier than 3.9.)
@ -2502,8 +2502,8 @@ port. (This also applies to dynamic SOCKS forwarding.)
\b The \q{Remote ports do the same} option does the same thing for
remote-to-local port forwardings (so that machines other than the
SSH server machine can connect to the forwarded port.) Note that
this feature is only available in the SSH 2 protocol, and not all
SSH 2 servers support it (OpenSSH 3.0 does not, for example).
this feature is only available in the SSH-2 protocol, and not all
SSH-2 servers support it (OpenSSH 3.0 does not, for example).
\S{config-ssh-portfwd-address-family} Selecting Internet protocol
version for forwarded ports
@ -2555,7 +2555,7 @@ states:
\b \q{Auto}: PuTTY will use the server's version number announcement
to try to guess whether or not the server has the bug.
\S{config-ssh-bug-ignore1} \q{Chokes on SSH1 ignore messages}
\S{config-ssh-bug-ignore1} \q{Chokes on SSH-1 ignore messages}
\cfg{winhelp-topic}{ssh.bugs.ignore1}
@ -2563,30 +2563,30 @@ An ignore message (SSH_MSG_IGNORE) is a message in the SSH protocol
which can be sent from the client to the server, or from the server
to the client, at any time. Either side is required to ignore the
message whenever it receives it. PuTTY uses ignore messages to hide
the password packet in SSH1, so that a listener cannot tell the
the password packet in SSH-1, so that a listener cannot tell the
length of the user's password; it also uses ignore messages for
connection keepalives (see \k{config-keepalive}).
If this bug is detected, PuTTY will stop using ignore messages. This
means that keepalives will stop working, and PuTTY will have to fall
back to a secondary defence against SSH1 password-length
back to a secondary defence against SSH-1 password-length
eavesdropping. See \k{config-ssh-bug-plainpw1}. If this bug is
enabled when talking to a correct server, the session will succeed,
but keepalives will not work and the session might be more
vulnerable to eavesdroppers than it could be.
This is an SSH1-specific bug. No known SSH2 server fails to deal
with SSH2 ignore messages.
This is an SSH-1-specific bug. No known SSH-2 server fails to deal
with SSH-2 ignore messages.
\S{config-ssh-bug-plainpw1} \q{Refuses all SSH1 password camouflage}
\S{config-ssh-bug-plainpw1} \q{Refuses all SSH-1 password camouflage}
\cfg{winhelp-topic}{ssh.bugs.plainpw1}
When talking to an SSH1 server which cannot deal with ignore
When talking to an SSH-1 server which cannot deal with ignore
messages (see \k{config-ssh-bug-ignore1}), PuTTY will attempt to
disguise the length of the user's password by sending additional
padding \e{within} the password packet. This is technically a
violation of the SSH1 specification, and so PuTTY will only do it
violation of the SSH-1 specification, and so PuTTY will only do it
when it cannot use standards-compliant ignore messages as
camouflage. In this sense, for a server to refuse to accept a padded
password packet is not really a bug, but it does make life
@ -2599,15 +2599,15 @@ of the password. If this bug is enabled when talking to a correct
server, the session will succeed, but will be more vulnerable to
eavesdroppers than it could be.
This is an SSH1-specific bug. SSH2 is secure against this type of
This is an SSH-1-specific bug. SSH-2 is secure against this type of
attack.
\S{config-ssh-bug-rsa1} \q{Chokes on SSH1 RSA authentication}
\S{config-ssh-bug-rsa1} \q{Chokes on SSH-1 RSA authentication}
\cfg{winhelp-topic}{ssh.bugs.rsa1}
Some SSH1 servers cannot deal with RSA authentication messages at
all. If Pageant is running and contains any SSH1 keys, PuTTY will
Some SSH-1 servers cannot deal with RSA authentication messages at
all. If Pageant is running and contains any SSH-1 keys, PuTTY will
normally automatically try RSA authentication before falling back to
passwords, so these servers will crash when they see the RSA attempt.
@ -2616,9 +2616,9 @@ authentication. If this bug is enabled when talking to a correct
server, the session will succeed, but of course RSA authentication
will be impossible.
This is an SSH1-specific bug.
This is an SSH-1-specific bug.
\S{config-ssh-bug-hmac2} \q{Miscomputes SSH2 HMAC keys}
\S{config-ssh-bug-hmac2} \q{Miscomputes SSH-2 HMAC keys}
\cfg{winhelp-topic}{ssh.bugs.hmac2}
@ -2633,9 +2633,9 @@ same way as the buggy server, so that communication will still be
possible. If this bug is enabled when talking to a correct server,
communication will fail.
This is an SSH2-specific bug.
This is an SSH-2-specific bug.
\S{config-ssh-bug-derivekey2} \q{Miscomputes SSH2 encryption keys}
\S{config-ssh-bug-derivekey2} \q{Miscomputes SSH-2 encryption keys}
\cfg{winhelp-topic}{ssh.bugs.derivekey2}
@ -2649,15 +2649,15 @@ the same way as the buggy server, so that communication will still
be possible. If this bug is enabled when talking to a correct
server, communication will fail.
This is an SSH2-specific bug.
This is an SSH-2-specific bug.
\S{config-ssh-bug-sig} \q{Requires padding on SSH2 RSA signatures}
\S{config-ssh-bug-sig} \q{Requires padding on SSH-2 RSA signatures}
\cfg{winhelp-topic}{ssh.bugs.rsapad2}
Versions below 3.3 of OpenSSH require SSH2 RSA signatures to be
Versions below 3.3 of OpenSSH require SSH-2 RSA signatures to be
padded with zero bytes to the same length as the RSA key modulus.
The SSH2 draft specification says that an unpadded signature MUST be
The SSH-2 draft specification says that an unpadded signature MUST be
accepted, so this is a bug. A typical symptom of this problem is
that PuTTY mysteriously fails RSA authentication once in every few
hundred attempts, and falls back to passwords.
@ -2668,13 +2668,13 @@ server, it is likely that no damage will be done, since correct
servers usually still accept padded signatures because they're used
to talking to OpenSSH.
This is an SSH2-specific bug.
This is an SSH-2-specific bug.
\S{config-ssh-bug-pksessid2} \q{Misuses the session ID in PK auth}
\cfg{winhelp-topic}{ssh.bugs.pksessid2}
Versions below 2.3 of OpenSSH require SSH2 public-key authentication
Versions below 2.3 of OpenSSH require SSH-2 public-key authentication
to be done slightly differently: the data to be signed by the client
contains the session ID formatted in a different way. If public-key
authentication mysteriously does not work but the Event Log (see
@ -2684,9 +2684,9 @@ helps.
If this bug is detected, PuTTY will sign data in the way OpenSSH
expects. If this bug is enabled when talking to a correct server,
SSH2 public-key authentication will fail.
SSH-2 public-key authentication will fail.
This is an SSH2-specific bug.
This is an SSH-2-specific bug.
\S{config-ssh-bug-rekey} \q{Handles key re-exchange badly}
@ -2706,7 +2706,7 @@ exchange. If this bug is enabled when talking to a correct server,
the session should still function, but may be less secure than you
would expect.
This is an SSH2-specific bug.
This is an SSH-2-specific bug.
\H{config-file} Storing configuration in a file

10
doc/errors.but
View File

@ -30,8 +30,8 @@ asking the machine's administrator.
If you see this message and you know that your installation of PuTTY
\e{has} connected to the same server before, it may have been
recently upgraded to SSH protocol version 2. SSH protocols 1 and 2
use separate host keys, so when you first use SSH 2 with a server
you have only used SSH 1 with before, you will see this message
use separate host keys, so when you first use SSH-2 with a server
you have only used SSH-1 with before, you will see this message
again. You should verify the correctness of the key as before.
See \k{gs-hostkey} for more information on host keys.
@ -100,7 +100,7 @@ PuTTY is not able to recover from running out of memory; it will
terminate immediately after giving this error.
However, this error can also occur when memory is not running out at
all, because PuTTY receives data in the wrong format. In SSH 2 and
all, because PuTTY receives data in the wrong format. In SSH-2 and
also in SFTP, the server sends the length of each message before the
message itself; so PuTTY will receive the length, try to allocate
space for the message, and then receive the rest of the message. If
@ -108,7 +108,7 @@ the length PuTTY receives is garbage, it will try to allocate a
ridiculous amount of memory, and will terminate with an \q{Out of
memory} error.
This can happen in SSH 2, if PuTTY and the server have not enabled
This can happen in SSH-2, if PuTTY and the server have not enabled
encryption in the same way (see \k{faq-outofmem} in the FAQ). Some
versions of OpenSSH have a known problem with this: see
\k{faq-openssh-bad-openssl}.
@ -213,7 +213,7 @@ to tell from this error message whether the problem is in the client,
in the server, or in between.
If you get this error, one thing you could try would be to fiddle
with the setting of \q{Miscomputes SSH2 encryption keys} on the Bugs
with the setting of \q{Miscomputes SSH-2 encryption keys} on the Bugs
panel (see \k{config-ssh-bug-derivekey2}).
Another known server problem which can cause this error is described

36
doc/faq.but
View File

@ -45,23 +45,23 @@ 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?
\S{faq-ssh2}{Question} Does PuTTY support SSH-2?
Yes. SSH v2 support has been available in PuTTY since version 0.50.
Yes. SSH-2 support has been available in PuTTY since version 0.50.
Public key authentication (both RSA and DSA) in SSH v2 is new in
Public key authentication (both RSA and DSA) in SSH-2 is new in
version 0.52.
\S{faq-ssh2-keyfmt}{Question} Does PuTTY support reading OpenSSH or
\cw{ssh.com} SSHv2 private key files?
\cw{ssh.com} SSH-2 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?
\S{faq-ssh1}{Question} Does PuTTY support SSH-1?
Yes. SSH 1 support has always been available in PuTTY.
Yes. SSH-1 support has always been available in PuTTY.
\S{faq-localecho}{Question} Does PuTTY support local echo?
@ -534,9 +534,9 @@ of quotes in the obvious way:
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
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
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
@ -550,7 +550,7 @@ 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
\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.
@ -608,7 +608,7 @@ the
\c http://www.microsoft.com/windows95/downloads/contents/
\c wuadmintools/s_wunetworkingtools/w95sockets2/
\S{faq-outofmem}{Question} After trying to establish an SSH 2
\S{faq-outofmem}{Question} After trying to establish an SSH-2
connection, PuTTY says \q{Out of memory} and dies.
If this happens just while the connection is starting up, this often
@ -838,17 +838,17 @@ default cipher differs from many other clients.)
\e{OpenSSH 3.1p1:} configurations known to be broken (and symptoms):
\b SSH 2 with AES cipher (PuTTY says "Assertion failed! Expression:
\b SSH-2 with AES cipher (PuTTY says "Assertion failed! Expression:
(len & 15) == 0" in sshaes.c, or "Out of memory", or crashes)
\b SSH 2 with 3DES (PuTTY says "Incorrect MAC received on packet")
\b SSH-2 with 3DES (PuTTY says "Incorrect MAC received on packet")
\b SSH 1 with Blowfish (PuTTY says "Incorrect CRC received on
\b SSH-1 with Blowfish (PuTTY says "Incorrect CRC received on
packet")
\b SSH 1 with 3DES
\b SSH-1 with 3DES
\e{OpenSSH 3.4p1:} as of 3.4p1, only the problem with SSH 1 and
\e{OpenSSH 3.4p1:} as of 3.4p1, only the problem with SSH-1 and
Blowfish remains. Rebuild your server, apply the patch linked to from
bug 138 above, or use another cipher (e.g., 3DES) instead.
@ -860,11 +860,11 @@ clear the underlying cause is the same.
key from ..."? Why can PuTTYgen load my key but not PuTTY?
It's likely that you've generated an SSH protocol 2 key with PuTTYgen,
but you're trying to use it in an SSH 1 connection. SSH1 and SSH2 keys
but you're trying to use it in an SSH-1 connection. SSH-1 and SSH-2 keys
have different formats, and (at least in 0.52) PuTTY's reporting of a
key in the wrong format isn't optimal.
To connect using SSH 2 to a server that supports both versions, you
To connect using SSH-2 to a server that supports both versions, you
need to change the configuration from the default (see \k{faq-ssh2}).
\S{faq-rh8-utf8}{Question} When I'm connected to a Red Hat Linux 8.0
@ -1177,7 +1177,7 @@ OpenSSH?
No, it isn't. PuTTY is almost completely composed of code written
from scratch for PuTTY. The only code we share with OpenSSH is the
detector for SSH1 CRC compensation attacks, written by CORE SDI S.A.
detector for SSH-1 CRC compensation attacks, written by CORE SDI S.A.
\S{faq-sillyputty}{Question} Where can I buy silly putty?

28
doc/man-pg.but
View File

@ -42,15 +42,15 @@ The options to control this are:
\dt \e{keyfile}
\dd Specify a private key file to be loaded. This private key file can
be in the (de facto standard) SSH1 key format, or in PuTTY's SSH2
key format, or in either of the SSH2 private key formats used by
be in the (de facto standard) SSH-1 key format, or in PuTTY's SSH-2
key format, or in either of the SSH-2 private key formats used by
OpenSSH and ssh.com's implementation.
\dt \cw{\-t} \e{keytype}
\dd Specify a type of key to generate. The acceptable values here are
\c{rsa} and \c{dsa} (to generate SSH2 keys), and \c{rsa1} (to
generate SSH1 keys).
\c{rsa} and \c{dsa} (to generate SSH-2 keys), and \c{rsa1} (to
generate SSH-1 keys).
\dt \cw{\-b} \e{bits}
@ -85,21 +85,21 @@ Acceptable options are:
\dt \cw{private}
\dd Save the private key in a format usable by PuTTY. This will either
be the standard SSH1 key format, or PuTTY's own SSH2 key format.
be the standard SSH-1 key format, or PuTTY's own SSH-2 key format.
\dt \cw{public}
\dd Save the public key only. For SSH1 keys, the standard public key
format will be used (\q{\cw{1024 37 5698745}...}). For SSH2 keys, the
\dd Save the public key only. For SSH-1 keys, the standard public key
format will be used (\q{\cw{1024 37 5698745}...}). For SSH-2 keys, the
public key will be output in the format specified in the IETF
drafts, which is a multi-line text file beginning with the line
\q{\cw{---- BEGIN SSH2 PUBLIC KEY ----}}.
\dt \cw{public-openssh}
\dd Save the public key only, in a format usable by OpenSSH. For SSH1
\dd Save the public key only, in a format usable by OpenSSH. For SSH-1
keys, this output format behaves identically to \c{public}. For
SSH2 keys, the public key will be output in the OpenSSH format,
SSH-2 keys, the public key will be output in the OpenSSH format,
which is a single line (\q{\cw{ssh-rsa AAAAB3NzaC1yc2}...}).
\dt \cw{fingerprint}
@ -109,13 +109,13 @@ algorithms are believed compatible with OpenSSH.
\dt \cw{private-openssh}
\dd Save an SSH2 private key in OpenSSH's format. This option is not
permitted for SSH1 keys.
\dd Save an SSH-2 private key in OpenSSH's format. This option is not
permitted for SSH-1 keys.
\dt \cw{private-sshcom}
\dd Save an SSH2 private key in ssh.com's format. This option is not
permitted for SSH1 keys.
\dd Save an SSH-2 private key in ssh.com's format. This option is not
permitted for SSH-1 keys.
If no output type is specified, the default is \c{private}.
@ -144,7 +144,7 @@ fingerprint. Otherwise, the \c{\-o} option is required.
\S{puttygen-manpage-examples} EXAMPLES
To generate an SSH2 RSA key pair and save it in PuTTY's own format
To generate an SSH-2 RSA key pair and save it in PuTTY's own format
(you will be prompted for the passphrase):
\c puttygen -t rsa -C "my home key" -o mykey.ppk

4
doc/man-putt.but
View File

@ -193,7 +193,7 @@ tunnel all their connections. Only works in SSH.
\dt \cw{\-A}, \cw{\-a}
\dd Enable (\cw{\-A}) or disable (\cw{\-a}) SSH agent forwarding.
Currently this only works with OpenSSH and SSH1.
Currently this only works with OpenSSH and SSH-1.
\dt \cw{\-X}, \cw{\-x}
@ -214,7 +214,7 @@ pseudo-terminal at the server end.
\dt \cw{\-i} \e{keyfile}
\dd Specify a private key file to use for authentication. For SSH2
\dd Specify a private key file to use for authentication. For SSH-2
keys, this key file must be in PuTTY's format, not OpenSSH's or
anyone else's.

8
doc/pageant.but
View File

@ -68,9 +68,9 @@ something like this:
For each key, the list box will tell you:
\b The type of the key. Currently, this can be \c{ssh1} (an RSA key
for use with the SSH v1 protocol), \c{ssh-rsa} (an RSA key for use
with the SSH v2 protocol), or \c{ssh-dss} (a DSA key for use with
the SSH v2 protocol).
for use with the SSH-1 protocol), \c{ssh-rsa} (an RSA key for use
with the SSH-2 protocol), or \c{ssh-dss} (a DSA key for use with
the SSH-2 protocol).
\b The size (in bits) of the key.
@ -152,7 +152,7 @@ like this:
Agent forwarding is a mechanism that allows applications on your SSH
server machine to talk to the agent on your client machine.
Note that at present, agent forwarding in SSH2 is only available
Note that at present, agent forwarding in SSH-2 is only available
when your SSH server is OpenSSH. The \cw{ssh.com} server uses a
different agent protocol, which PuTTY does not yet support.

16
doc/pscp.but
View File

@ -7,8 +7,8 @@
\i{PSCP}, the PuTTY Secure Copy client, is a tool for transferring files
securely between computers using an SSH connection.
If you have an SSH 2 server, you might prefer PSFTP (see \k{psftp})
for interactive use. PSFTP does not in general work with SSH 1
If you have an SSH-2 server, you might prefer PSFTP (see \k{psftp})
for interactive use. PSFTP does not in general work with SSH-1
servers, however.
\H{pscp-starting} Starting PSCP
@ -98,7 +98,7 @@ However, in the second case (using a wildcard for multiple remote
files) you may see a warning saying something like \q{warning:
remote host tried to write to a file called \cq{terminal.c} when we
requested a file called \cq{*.c}. If this is a wildcard, consider
upgrading to SSH 2 or using the \cq{-unsafe} option. Renaming of
upgrading to SSH-2 or using the \cq{-unsafe} option. Renaming of
this file has been disallowed}.
This is due to a fundamental insecurity in the old-style SCP
@ -112,13 +112,13 @@ the wildcard matching rules are decided by the server, the client
cannot reliably verify that the filenames sent back match the
pattern.
PSCP will attempt to use the newer SFTP protocol (part of SSH 2)
PSCP will attempt to use the newer SFTP protocol (part of SSH-2)
where possible, which does not suffer from this security flaw. If
you are talking to an SSH 2 server which supports SFTP, you will
you are talking to an SSH-2 server which supports SFTP, you will
never see this warning. (You can force use of the SFTP protocol,
if available, with \c{-sftp} - see \k{pscp-usage-options-backend}.)
If you really need to use a server-side wildcard with an SSH 1
If you really need to use a server-side wildcard with an SSH-1
server, you can use the \c{-unsafe} command line option with PSCP:
\c pscp -unsafe fred@example.com:source/*.c c:\source
@ -244,7 +244,7 @@ used, but also leads to interoperability issues such as with filename
quoting (for instance, where filenames contain spaces), and also the
security issue described in \k{pscp-usage-basics}.
The newer SFTP protocol, which is usually associated with SSH 2
The newer SFTP protocol, which is usually associated with SSH-2
servers, is specified in a more platform independent way, and leaves
issues such as wildcard syntax up to the client. (PuTTY's SFTP
wildcard syntax is described in \k{psftp-wildcards}.) This makes it
@ -258,7 +258,7 @@ The \c{-scp} option forces PSCP to use the SCP protocol or quit.
The \c{-sftp} option forces PSCP to use the SFTP protocol or quit.
When this option is specified, PSCP looks harder for an SFTP server,
which may allow use of SFTP with SSH 1 depending on server setup.
which may allow use of SFTP with SSH-1 depending on server setup.
\S{pscp-retval} Return value

4
doc/psftp.but
View File

@ -8,8 +8,8 @@ securely between computers using an SSH connection.
PSFTP differs from PSCP in the following ways:
\b PSCP should work on virtually every SSH server. PSFTP uses the
new SFTP protocol, which is a feature of SSH 2 only. (PSCP will also
use this protocol if it can, but there is an SSH 1 equivalent it can
new SFTP protocol, which is a feature of SSH-2 only. (PSCP will also
use this protocol if it can, but there is an SSH-1 equivalent it can
fall back to if it cannot.)
\b PSFTP allows you to run an interactive file transfer session,

44
doc/pubkey.but
View File

@ -114,17 +114,17 @@ Before generating a key pair using PuTTYgen, you need to select
which type of key you need. PuTTYgen currently supports three types
of key:
\b An RSA key for use with the SSH 1 protocol.
\b An RSA key for use with the SSH-1 protocol.
\b An RSA key for use with the SSH 2 protocol.
\b An RSA key for use with the SSH-2 protocol.
\b A DSA key for use with the SSH 2 protocol.
\b A DSA key for use with the SSH-2 protocol.
The SSH 1 protocol only supports RSA keys; if you will be connecting
using the SSH 1 protocol, you must select the first key type or your
The SSH-1 protocol only supports RSA keys; if you will be connecting
using the SSH-1 protocol, you must select the first key type or your
key will be completely useless.
The SSH 2 protocol supports more than one key type. The two types
The SSH-2 protocol supports more than one key type. The two types
supported by PuTTY are RSA and DSA.
The PuTTY developers \e{strongly} recommend you use RSA. DSA has an
@ -289,13 +289,13 @@ will need to tell PuTTY to use for authentication (see
\cfg{winhelp-topic}{puttygen.savepub}
The SSH 2 protocol drafts specify a standard format for storing
The SSH-2 protocol drafts specify a standard format for storing
public keys on disk. Some SSH servers (such as \cw{ssh.com}'s)
require a public key in this format in order to accept
authentication with the corresponding private key. (Others, such as
OpenSSH, use a different format; see \k{puttygen-pastekey}.)
To save your public key in the SSH 2 standard format, press the
To save your public key in the SSH-2 standard format, press the
\q{Save public key} button in PuTTYgen. PuTTYgen will put up a
dialog box asking you where to save the file. Select a directory,
type in a file name, and press \q{Save}.
@ -305,9 +305,9 @@ server machine. See \k{pubkey-gettingready} for general instructions
on configuring public-key authentication once you have generated a
key.
If you use this option with an SSH 1 key, the file PuTTYgen saves
If you use this option with an SSH-1 key, the file PuTTYgen saves
will contain exactly the same text that appears in the \q{Public key
for pasting} box. This is the only existing standard for SSH 1
for pasting} box. This is the only existing standard for SSH-1
public keys.
\S{puttygen-pastekey} \q{Public key for pasting into authorized_keys
@ -315,9 +315,9 @@ file}
\cfg{winhelp-topic}{puttygen.pastekey}
All SSH 1 servers require your public key to be given to it in a
All SSH-1 servers require your public key to be given to it in a
one-line format before it will accept authentication with your
private key. The OpenSSH server also requires this for SSH 2.
private key. The OpenSSH server also requires this for SSH-2.
The \q{Public key for pasting into authorized_keys file} gives the
public-key data in the correct one-line format. Typically you will
@ -352,23 +352,23 @@ for information about importing foreign key formats.
\cfg{winhelp-topic}{puttygen.conversions}
Most SSH1 clients use a standard format for storing private keys on
Most SSH-1 clients use a standard format for storing private keys on
disk. PuTTY uses this format as well; so if you have generated an
SSH1 private key using OpenSSH or \cw{ssh.com}'s client, you can use
SSH-1 private key using OpenSSH or \cw{ssh.com}'s client, you can use
it with PuTTY, and vice versa.
However, SSH2 private keys have no standard format. OpenSSH and
However, SSH-2 private keys have no standard format. OpenSSH and
\cw{ssh.com} have different formats, and PuTTY's is different again.
So a key generated with one client cannot immediately be used with
another.
Using the \q{Import} command from the \q{Conversions} menu, PuTTYgen
can load SSH2 private keys in OpenSSH's format and \cw{ssh.com}'s
can load SSH-2 private keys in OpenSSH's format and \cw{ssh.com}'s
format. Once you have loaded one of these key types, you can then
save it back out as a PuTTY-format key (\c{*.PPK}) so that you can use
it with the PuTTY suite. The passphrase will be unchanged by this
process (unless you deliberately change it). You may want to change
the key comment before you save the key, since OpenSSH's SSH2 key
the key comment before you save the key, since OpenSSH's SSH-2 key
format contains no space for a comment and \cw{ssh.com}'s default
comment format is long and verbose.
@ -379,8 +379,8 @@ saving it (see \k{puttygen-savepriv}) - you need to have typed your
passphrase in beforehand, and you will be warned if you are about to
save a key without a passphrase.
Note that since only SSH2 keys come in different formats, the export
options are not available if you have generated an SSH1 key.
Note that since only SSH-2 keys come in different formats, the export
options are not available if you have generated an SSH-1 key.
\H{pubkey-gettingready} Getting ready for public key authentication
@ -389,7 +389,7 @@ connection succeeds you will be prompted for your user name and
password to login. Once logged in, you must configure the server to
accept your public key for authentication:
\b If your server is using the SSH 1 protocol, you should change
\b If your server is using the SSH-1 protocol, you should change
into the \c{.ssh} directory and open the file \c{authorized_keys}
with your favourite editor. (You may have to create this file if
this is the first key you have put in it). Then switch to the
@ -399,11 +399,11 @@ and copy it to the clipboard (\c{Ctrl+C}). Then, switch back to the
PuTTY window and insert the data into the open file, making sure it
ends up all on one line. Save the file.
\b If your server is OpenSSH and is using the SSH 2 protocol, you
\b If your server is OpenSSH and is using the SSH-2 protocol, you
should follow the same instructions, except that in earlier versions
of OpenSSH 2 the file might be called \c{authorized_keys2}. (In
modern versions the same \c{authorized_keys} file is used for both
SSH 1 and SSH 2 keys.)
SSH-1 and SSH-2 keys.)
\b If your server is \cw{ssh.com}'s SSH 2 product, you need to save
a \e{public} key file from PuTTYgen (see \k{puttygen-savepub}), and

12
doc/using.but
View File

@ -431,8 +431,8 @@ your client PC can connect to the forwarded port.
\b The \q{Remote ports do the same} option does the same thing for
remote-to-local port forwardings (so that machines other than the
SSH server machine can connect to the forwarded port.) Note that
this feature is only available in the SSH 2 protocol, and not all
SSH 2 servers honour it (in OpenSSH, for example, it's usually
this feature is only available in the SSH-2 protocol, and not all
SSH-2 servers honour it (in OpenSSH, for example, it's usually
disabled by default).
You can also specify an \i{IP address} to listen on. Typically a
@ -443,8 +443,8 @@ available only to the local machine. So if you forward (for example)
should be able to run commands such as \c{finger fred@127.0.0.5}.
This can be useful if the program connecting to the forwarded port
doesn't allow you to change the port number it uses. This feature is
available for local-to-remote forwarded ports; SSH1 is unable to
support it for remote-to-local ports, while SSH2 can support it in
available for local-to-remote forwarded ports; SSH-1 is unable to
support it for remote-to-local ports, while SSH-2 can support it in
theory but servers will not necessarily cooperate.
(Note that if you're using Windows XP Service Pack 2, you may need
@ -752,8 +752,8 @@ the SSH panel of the PuTTY configuration box (see
\S2{using-cmdline-sshprot} \i\c{-1} and \i\c{-2}: specify an \i{SSH
protocol version}
The \c{-1} and \c{-2} options force PuTTY to use version \I{SSH1}1
or version \I{SSH2}2 of the SSH protocol. These options are only
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.
These options are equivalent to selecting your preferred SSH