HP OpenVMS Systems Documentation

HP TCP/IP Services for OpenVMS
Release Notes

In addition, the OpenVMS SSH server provides an optional Kerberos password check. In password authentication mode, the SSH server checks the password against Kerberos before checking it against SYSUAF. If the Kerberos password check passes then the SSH server considers the SSH password authentication successful and the user is allowed in. If not, the password authentication continues on with the SYSUAF check.

When the Kerberos password check succeeds, the SSH server provides to the user process on the server system a forwardable TGT so that the user need not issue a kinit command once logged in. Essentially, the SSH server does a kinit on behalf of the user.

This feature is not enabled by default. Use the TryKerberosPassword to enable this feature.

In order to use the gssapi-with-mic authentication method on an OpenVMS host with Kerberos for OpenVMS Version V2.1, the SSH server and client startup procedures define a logical name TCPIP$SSH_KRBRTL_HACK. The presence of this logical tells the SSH client and server to perform steps to circumvent a problem with images that use LIB$FIND_IMAGE_SYMBOL to access both KRB$RTL32.EXE and GSS$RTL32.EXE.

The SSH server and client startup procedures will define TCPIP$SSH_KRBRTL_HACK based on the version of Kerberos running on your system and not whether Kerberos is actually in use on your system or configured to be used by SSH.

If you are running Kerberos for OpenVMS Version V3.0 or higher, the SSH server and client startup procedures will not define this logical, because the steps needed to make GSS$RTL32 work properly with LIB$FIND_IMAGE_SYMBOL are not needed.

1.9.4 Using Kerberos KDC/DNS

To configure Kerberos KDC/DNS, include fully qualified host principals. For example, a host principal for the SSH server host with DNS name myhost.abcd.org in the Kerberos realm ABCD.ORG would be "host/myhost.abcd.org@ABCD.ORG".

For SSH purposes the DNS host name part of the host principal should be fully qualified. The SSH server's checking of the client user's password against Kerberos in password authentication also requires a fully qualified host principal for the SSH server host.

You must define a Kerberos host principal for an SSH client host that is also to serve as an SSH server for the Kerberos-based authentication methods and for the password authentication Kerberos password check.

In addition, to use the gssapi-with-mic authentication method, the first name in the list returned from a TCPIP SHOW HOST/LOCAL command entered on the SSH server for the SSH server must be its fully-qualified canonical name.

For example, say the SSH server host name is myhost.abcd.org. This example illustrates two possible local host database entries for SSH server myhost.abcd.org on myhost.abcd.org. The first example prevents the gssapi-with-mic authentication method from working:

Example 1

  MYHOST> tcpip show host/local myhost

      LOCAL database

  Host address    Host name

  10.0.0.1   myhost, myhost.abcd.org, MYHOST, MYHOST.ABCD.ORG

The following example shows how to define the host name so that the gssapi-with-mic authentication method works:

Example 2

  MYHOST> tcpip show host/local myhost

       LOCAL database

  Host address    Host name

  10.0.0.1   myhost.abcd.org, myhost, MYHOST,MYHOST.ABCD.ORG

If your configuration requires a local host database entry as shown in Example 1, then gssapi-with-mic will not work for you.

1.9.5 New Configuration Parameters

This version of SSH recognizes the following new configuration parameters.

• In the server configuration file (SSHD_CONFIG.):
  • TryKerberosPassword
  • GssapiSendError
• In the client configuration file (SSH_CONFIG.):
  • GssapiDelegateCredentials
• In both the client and server configuration files:
  • GssapiSendErrtok

For more information about these configuration parameters, see the HP TCP/IP Services for OpenVMS Guide to SSH.

1.10 TELNET Upgrade with Kerberos Support

The TELNET server and client are now supported with the upgraded Kerberos version that ships with OpenVMS V8.3.

1.11 TELNET Server Device Limit

The TELNET server is no longer limited to 9999 sessions or TN devices.

1.12 IPv6 Support for LPD and TELNETSYM

Continuing our work to offer IPv6 support throughout the product, both LPD and TELNETSYM printing software now allow you to print via the IPv6 transport.

1.13 FTP Performance Enhancements for VMS Plus Mode

Streamlining was performed for the FTP service, specifically addressing the case where both server and client are OpenVMS systems.

1.14 Improved Interface Configuration in TCPIP$CONFIG

The menu-driven process of defining local interfaces and IP addresses has been significantly reworked to provide better support for failSAFE IP.

1.15 Added TSIG-based Authentication Support to the Load Broker

The Load Broker can now transact secure dynamic updates with a BIND server.

This chapter includes notes and changes made to the installation and configuration of TCP/IP Services, as well as startup and shutdown procedures. Use this chapter in conjunction with the HP TCP/IP Services for OpenVMS Installation and Configuration manual.

2.1 Installing Over V5.3 Early Adopter's Kits (EAKs)

If you have installed one or more of the following V5.3 EAKs, you must use the PCSI REMOVE command to remove the EAKs before you install TCP/IP Services V5.5:

• SSH for OpenVMS EAK
• failSAFE IP EAK

Upgrading from versions prior to V5.0 has not been qualified for this release.

2.3 Adding a System to an OpenVMS Cluster

The TCPIP$CONFIG.COM configuration procedure for TCP/IP Services Version 5.6 creates OpenVMS accounts using larger system parameter values than in previous versions. Only new accounts get these larger values. These values are useful on OpenVMS Alpha systems but essential on OpenVMS I64 systems.

To have your OpenVMS I64 system join an OpenVMS Cluster as a TCP/IP host, HP recommends adding the system to the cluster before you configure TCP/IP Services. The guidelines in Section 2.3.1 assume you have followed this recommendation.

If you configure TCP/IP Services before you add the system to a cluster, see Section 2.3.2.

2.3.1 Running a Newly Configured Host on the Cluster

The following recommendations assume you are configuring TCP/IP Services on the system after having added the system to the OpenVMS Cluster.

If TCP/IP Services has previously been installed on the cluster and you encounter problems running a TCP/IP component on the system, modify the cluster System Authorization File (SYSUAF) to raise the parameter values for the account used by the affected component. The minimum recommended values are listed in Table 2-1.

The IMAP, DHCP, and XDM components can exhibit account parameter problems if the value assigned to PGFLQUOTA or to any of the other listed parameters is too low. Use the OpenVMS AUTHORIZE utility to modify SYSUAF parameters. For more information, see HP OpenVMS System Management Utilities Reference Manual: A-L.

2.3.2 Configuring TCP/IP Services Before Adding the System to the Cluster

If you configure TCP/IP Services before you add the system to a cluster, when you add the system to the cluster the owning UIC for each of the TCP/IP service SYS$LOGIN directories (TCPIP$service-name, where service-name is the name of the service) may be incorrect. Use the OpenVMS AUTHORIZE utility to correct these UICs.

2.3.3 Disabling or Enabling SSH Server

When you use the TCPIP$CONFIG.COM configuration procedure to disable or enable the SSH server, the following prompt is displayed:

* Create a new default Server host key? [YES]:

Unless you have a specific reason for creating a new default server host key, you should enter "N" at this prompt. If you accept the default, clients with the old key will need to obtain the new key. For more information, see Section 3.10.6.

2.4 SSH Configuration Files Must Be Updated

Note that this section refers to upgrades from a version prior to V5.4 ECO.

The SSH client and server on this version of TCP/IP Services cannot use configuration files from previous versions of SSH.

If the SSH client and server detect systemwide configuration files from an older version of SSH, the client and server will fail to start. The client will display the following warning message, and the server will write the following warning message to the SSH_RUN.LOG file:

You may have an old style configuration file. Please follow the
instructions in the release notes to use the new configuration
files.

If the SSH client detects a user-specific configuration file from an older version of SSH, the SSH client will display the warning and will allow the user to proceed.

To preserve the modifications made to the SSH server configuration file and the SSH client configuration file, you must edit the templates provided with the new version of SSH, as follows:

1. Extract the template files using the following commands:

   $ LIBRARY/EXTRACT=SSH2_CONFIG SYS$LIBRARY:TCPIP$TEMPLATES.TLB - _$ /OUT=TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]SSH2_CONFIG. $ LIBRARY/EXTRACT=SSHD2_CONFIG SYS$LIBRARY:TCPIP$TEMPLATES.TLB - _$ /OUT=TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG.

   
   These commands copy the new template files into the SSH2 configuration directory with a new version number.
2. Copy the modifications made in the old versions of the configuration files to the new versions.
3. Start SSH using the following command:

   $ @SYS$STARTUP:SSH_STARTUP.COM $ @SYS$STARTUP:SSH_CLIENT_STARTUP.COM

If SMTP or LPD shutdown generates errors indicating that the queue manager is not running, check your site-specific shutdown command procedure (VMS_SYSHUTDOWN.COM). If this procedure contains the command to stop the queue manager (STOP/QUEUE/MANAGER), make sure this command is after the command that runs the TCPIP$SHUTDOWN.COM command procedure.

This chapter provides information about problems and restrictions in the current version of TCP/IP Services, and also includes other information specific to a particular command or service, such as changes in command syntax or messages.

3.1 Netstat Utility -z Option No Longer Implemented

In this version of TCP/IP Services for OpenVMS, the -z option to the netstat utility is no longer implemented. It has not been determined whether future versions of TCP/IP Services will restore this functionality.

3.2 Manually Configuring an Interface as DHCP Leads to Startup Problems

Manually configuring an interface to be managed via DHCP may lead to an error, TCPIP-E-DEFINTE, when starting TCP/IP. This causes TCP/IP to not start properly. To work around this problem, shutdown TCP/IP, then on the interface that was manually configured as DHCP, issue the following command: $ tcpip set config inter ifname/PRIMARY Now restart TCP/IP.

3.3 SLIP Restrictions

The serial line IP protocol (SLIP) is not supported in this release.

3.4 Advanced Programming Environment Restrictions and Guidelines

The header files provided in TCPIP$EXAMPLES are provided as part of the advanced TCP/IP programming environment. The following list describes restrictions and guidelines for using them:

• Use of the functions and data structures described in TCPIP$EXAMPLES:RESOLV.H is limited to 32-bit pointers. The underlying implementation will only handle 32-bit pointers. Previously, 64-bit pointers were wrongly accepted, resulting in undefined behavior for the underlying implementation.
• The IP.H and IP6.H header files are incomplete in the OpenVMS environment. They contain include directives for header files that are not provided in this version of TCP/IP Services. Refer to the HP TCP/IP Services for OpenVMS Sockets API and System Services Programming for more information.

BIND Version 9 has the following restrictions:

• Certain DNS server implementations do not support AAAA (IPv6 address) records. When queried for an AAAA (IPv6) record type by the BIND resolver, these name servers will return an NXDOMAIN status, even if an A (IPv4) record exists for the same domain name. These name servers should be returning NOERROR as the status for such a query. This problem can result in delays during host name resolution.
  BIND Version 9.3.1, which is supported with this release of TCP/IP Services, and prior versions of BIND do not exhibit this problem.
• Serving secure zones
  When acting as an authoritative name server, BIND Version 9 includes KEY, SIG, and NXT records in responses as specified in RFC 2535 when the request has the DO flag set in the query.
• Secure resolution
  Basic support for validation of DNSSEC signatures in responses has been implemented but should be considered experimental.
  When acting as a caching name server, BIND Version 9 is capable of performing basic DNSSEC validation of positive as well as nonexistence responses. You can enable this functionality by including a trusted-keys clause containing the top-level zone key of the DNSSEC tree in the configuration file.
  Validation of wildcard responses is not currently supported. In particular, a " name does not exist " response will validate successfully even if the server does not contain the NXT records to prove the nonexistence of a matching wildcard.
  Proof of insecure status for insecure zones delegated from secure zones works when the zones are completely insecure. Privately secured zones delegated from secure zones will not work in all cases, such as when the privately secured zone is served by the same server as an ancestor (but not parent) zone.
  Handling of the CD bit in queries is now fully implemented. Validation is not attempted for recursive queries if CD is set.
• Secure dynamic update
  Dynamic updating of secure zones has been partially implemented. Affected NXT and SIG records are updated by the server when an update occurs. Use the update-policy statement in the zone definition for advanced access control.
• Secure zone transfers
  BIND Version 9 does not implement the zone transfer security mechanisms of RFC 2535 because they are considered inferior to the use of TSIG or SIG(0) to ensure the integrity of zone transfers.
• SSL$LIBCRYPTO_SHR32.EXE requirement
  In this version of TCP/IP Services, the BIND Server and related utilities have been updated to use the OpenSSL shareable image SSL$LIBCRYPTO_SHR32.EXE. There is now a requirement that this shareable image from OpenSSL V1.2 or higher be installed on the system before starting the BIND Server. It must also be installed before using the following BIND utilities:

  BIND_CHECKCONF BIND_CHECKZONE DIG DNSSEC_KEYGEN DNSSEC_SIGNZONE HOST NSUPDATE RNDC_CONFGEN

The following sections describe restrictions in the use of IPv6.

3.6.1 Mobile IPv6 Restrictions

Mobile IPv6 is not supported in this release.

3.6.2 IPv6 Requires the BIND Resolver

If you are using IPv6, you must enable the BIND resolver. To enable the BIND resolver, use the TCPIP$CONFIG.COM command procedure. From the Core environment menu, select BIND Resolver.

You must specify the BIND server to enable the BIND resolver. If you do not have access to a BIND server, specify the node address 127.0.0.1 as your BIND server.

3.7 NFS Restrictions on Alpha Platforms

The following sections describe problems and restrictions with NFS on Alpha platforms.

3.7.1 NFS Server Problems and Restrictions

The following restrictions apply to the NFS server on OpenVMS Alpha systems:

• When performing a mount operation or starting the NFS server with OPCOM enabled, the TCP/IP Services MOUNT server can erroneously display the following message:

  %TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file /dev/dir

  
  This message appears even when the MOUNT or NFS startup has successfully completed. In the case of a mount operation, if it has actually succeeded, the following message will also be displayed:

  %TCPIP-S-NFS_MNTSUC, mounted file system /dev/dir

• If the NFS server and the NFS client are in different domains and unqualified host names are used in requests, the lock server (LOCKD) fails to honor the request and leaves the file unlocked.
  When the server attempts to look up a host using its unqualified host name (for example, johnws ) instead of the fully qualified host name (for example, johnws.abc com ), and the host is not in the same domain as the server, the request fails.
  To solve this type of problem, you can do one of the following:
  • When you configure the NFS client, specify the fully qualified host name, including the domain name. This ensures that translation will succeed.
  • Add an entry to the NFS server's hosts database for the client's unqualified host name. Only that NFS server will be able to translate this host name. This solution will not work if the client obtains its address dynamically from DHCP.

• To get proper timestamps, when the system time is changed for daylight savings time (DST), dismount all DNFS devices. (The TCP/IP management command SHOW MOUNT should show zero mounted devices.) Then remount the devices.
• The NFS client does not properly handle file names with the semicolon character on ODS-5 disk volumes. (For example, a^;b.dat;5 is a valid file name.) Such file names are truncated at the semicolon.
• The NFS client included with TCP/IP Services uses the NFS Version 2 protocol only.
• With the NFS Version 2 protocol, the value of the file size is limited to 32 bits.
• The ISO Latin-1 character set is supported. The UCS-2 characters are not supported.
• File names, including file extensions, can be no more than 236 characters long.
• Files containing characters not accepted by ODS-5 on the active OpenVMS version or whose name and extension exceeds 236 characters are truncated to zero length. This makes them invisible to OpenVMS and is consistent with prior OpenVMS NFS client behavior.