Customer Situation

Many customers have been using SSH in place of transferring unsecured files via FTP. The files may be transferred between two OpenVMS systems or between OpenVMS and other operating platforms. In this scenario, the customer is using an OpenVMS system and UNIX. Both systems had to act as a client and server. In addition, the customer’s sessions were not interactive, but rather a batch process was scheduled to run on pre-fixed intervals sometimes originating on OpenVMS and other times from a UNIX machine. To run the batch process, a user ID and password was used for access to the remote system. Both the user ID and password were stored in a file in clear text on both machines. This practice is typically against many organizations’ security policies because there is a high risk of potential theft of the user ID and password. The customer implemented Process Software’s SSH solution to provide them with secure file transfers and protect their password from potential theft. Here is how it was done.

Process Software offers a complete SSH solution for customers that want to protect files, e-mail and other data over an unsecured network. SSH clients and servers (protocol version 1 and 2) are included as a feature of MultiNet and TCPware, and is a standalone product in SSH for OpenVMS.

Process Software addressed this customer’s requirements as described in the previous section. First, the user ID/password being used for client SSH authentication cannot be stored in an encrypted format on the OpenVMS system. To protect the authentication process, Process Software recommended the customer run MultiNet, TCPware or SSH for OpenVMS in an SSH "batch mode". This means that the customer would run a normal VMS batch job containing the SCP commands in SSH batch mode to copy the files. The SSH batch mode does not prompt a user for any input (such as a password).

Second, since there is no mechanism for providing a password to an SSH process as needed with user ID/password authentication, Process Software recommends customers use public key and/or hostbased authentication. Public key authentication is more secure than hostbased authentication because keys are maintained on a user by user basis versus the hostbased authentication method which maintains system-wide files that multiple users can access and potentially modify. On the UNIX and OpenVMS platforms, the private keys used in hostbased authentication are secured by file protections. However, if somebody is privileged enough (they have BYPASS or READALL privilege, for example) they can steal a key. That is a security issue (issuing of privileges) that needs to be dealt with as part of the larger security policy of the organization.

Private keys may also be protected via a passphrase. However, in the scenario described above, the customer had to use an authentication agent to load the private keys (so the passphrases can be provided interactively) before executing the file transfers. This operation is implemented during boot time. Once an SSH session is established, all traffic in that session is encrypted.