This patch is applicable to TCPware SSH on all supported
versions of OpenVMS VAX and OpenVMS Alpha.

NOTE: The TCPware ECO DRIVERS_V562P052 or later is required
and must be installed in order to run SSH after installing
the SSH_V562P070 ECO.

A system reboot is requred after installing this ECO, to load
the new software features.

This kit has an ECO ranking of 2, with an overall ranking of 0.

*** Notes for Kerberos 5 Support ***

Support for Kerberos 5 is based on HP Kerberos V5 for OpenVMS.
Prior to installing and configuring the HP Kerberos product, the
following TCPware ECO must be installed:

- DRIVERS_V562P052 or later

Once the above ECO has been applied, Kerberos may be installed
and configured.

SSH may be configured and used at any time, either with or
without Kerberos; however, Kerberos is required to perform Kerberos
authentication in the SSH server. If Kerberos is installed at some
later time after SSH is started, restarting SSH will allow it to
use Kerberos.

Some chapters of the TCPware documentation having to do with SSH
have been updated. New PDF files of these are supplied in this
ECO, and are copied to the TCPWARE_COMMON:[TCPWARE] directory.
These are:

- For those clients that can support it (this includes the client
used by all Process Software SSH products), expired password handling
by the server has been modified to prompt for the new password,
then the session will continue rather than being logged out. For
those clients that don't support this, the old method of expired
password handling is still used.

There are some clients that may not support this method (an expired
password causes an abrupt disconnect from the server system), but
the server may not be able to identify them correctly. To handle
those, if the logical name

TCPWARE_SSH_USE_OLD_EXPIRED_PASSWORD_SCHEME

is defined system-wide, the server will revert to its previous
method of handling expired passwords. [DE 10260]

- Corrected an error that causes our SFTP2/SCP2 client to ACCVIO when
dealing with an SFTP server that speaks SFTP protocol version 2.
[DE 10234]

- Modified the SFTP server such that TCPWARE_SFTP_VMS_ALL_VERSIONS
will cause all file versions to be displayed no matter what the
remote (client) side is. Note that when a file is copied from the
VMS system to the client, the filename will contain the version
number. [DE 10238]

- Allowed version numbers to be used for the local source specified on
SCP2 command line, even when /VMS is not used. [DE 10242]

- Fixed a ACCVIO that can occur when exiting from a command file.
[DE 10251]

- Put the /ASCII=VMS option back in. [DE 10259]

- If the logical TCPWARE_SFTP_STAT_DESTINATION_FILE is defined to be
FALSE, NO or 0 (zero) then the SFTP client will not attempt to do a
STAT operation to check for the presence of the destination file
before opening the destination file for write. The assumption is
that the destination file does not exist.

If the logical TCPWARE_SFTP_STAT_DESTINATION_DIRECTORY is defined
to be FALSE, NO or 0 (zero) then the SFTP client will not attempt
to do a STAT operation on the destination directory before opening
the destination file for write. The assumption is that the
destination directory exists.

These two logicals should be defined to FALSE in order to have the
SFTP client work with Sterling Commerce's Connect:Enterprise
product. [DE 10276]

- If the logical TCPWARE_SFTP_DONT_TRUNCATE is defined to Yes, True
or 1 then the SFTP server will not perform truncate operations as
part of FSETSTAT and SETSTAT operations. Some systems end up with
unexpected file attributes when the truncate operation is performed
and this provides a method of disabling it. [DE 10305]

- If you previously customized your SSH2_DIR:SSHD2_CONFIG file (now
renamed to ".OLD"), you must edit the new SSH2_DIR:SSHD2_CONFIG
file and add your customizations to it. You MUST use the new
file created from the new TCPWARE:SSHD2_CONFIG.TEMPLATE file for
this.

- Note that if you are in a clustered environment with a shared
system disk, you must copy the TCPWARE:SSHD2_CONFIG.TEMPLATE from
the node where the ECO was initially installed to the SSH2_DIR:
directory on each of the other nodes in the cluster before making
the new SSHD2_CONFIG file and making any changes as noted above.