HP OpenVMS Systems Documentation
HP TCP/IP Services for OpenVMS
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.
The check of the user password against Kerberos is transparent to the SSH client software and is performed entirely on the SSH server. The SSH client software is unaware of how the password is processed by the SSH server. This approach has the advantage of allowing use of Kerberos features from a client host that doesn't have Kerberos configured. The only awareness of Kerberos required on the SSH client side is the knowledge of the user that they may enter their Kerberos password (which may very well be different from the password to their account on the server host) in response to the SSH client's password cue.
Because there is no knowledge on the part of the SSH client software that the SSH server is passing the user password to Kerberos for validation, there is no way for the SSH client user to specify the Kerberos principal name to be used by the SSH server for the Kerberos password check. Therefore the SSH server must compose the Kerberos principal name for the password check using a common sense heuristic. The SSH server uses the target username being logged into on the SSH server system for the username part of the principal and the local Kerberos realm as the principal's realm name. For example, if the SSH server's Kerberos realm was SYSA.XYZ.COM and the user account to be logged into was "smith" then the Kerberos principal used for the Kerberos password check would be smith@SYSA.XYZ.COM.
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:
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:
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
will not work for you.
1.9.5 New Configuration Parameters
This version of SSH recognizes the following new configuration parameters.
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
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
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
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:
If you install the current TCP/IP Services version after removing the failSAFE IP EAK, you must run TCPIP$CONFIG.COM to reestablish your target and home interfaces.
Upgrading from versions prior to V5.0 has not been qualified for this
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:
$ 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.
$ @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.
You do not have to stop the queue manager explicitly. The queue manager is automatically stopped and started when you restart the system.
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
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
$ 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:
BIND Version 9 has the following restrictions:
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
3.7.1 NFS Server Problems and Restrictions
The following restrictions apply to the NFS server on OpenVMS Alpha systems:
%TCPIP-E-NFS_BFSCAL, operation MOUNT_POINT failed on file /dev/dir
%TCPIP-S-NFS_MNTSUC, mounted file system /dev/dir